Rapid Prototyping with Tcl/Tk
Creating software is a complex process that embeds the programmer in rules and constraints. Customer needs fight against bugs in the program, and usability fights against production costs.
The current procedure to solve all these problems is object-oriented design and analysis, accomplished by methodically trying to split a problem into suitably small subdomains and providing a predefined path from analysis through design to implementation and testing.
Such a procedure may help for large programs and may be necessary if many programmers are involved. Most of the really good programs (such as those available for Linux, and even Linux itself) are written by only a few people, and more importantly, most of them don't start out knowing in which direction their software will evolve. Therefore, another paradigm is needed—one that is better suited to the needs of humans.
Here is a statement about rapid prototyping (RP) I found on the home page of Cycad Corporation at http://www.cycad.com/:
Rapid prototyping is acquainted with keywords like “Get to market faster, Beat the competition, Maximize profitability, Increase quality...” Not only does rapid prototyping provide all the benefits of getting to market faster, but for the first time it is possible to create Proof-of-Concepts to show customers before implementation and create proto-production units before committing to manufacturing. Both of these validation steps can save extensive amounts of resources and time.
While all of the above is certainly true, RP is particularly suited to the creation of software tailored to the customer's needs. One of the most important aspects in determining these needs is to find out what the customer really wants. Because the program takes its final shape while it is under development, not in advance as would happen with standard structured design, the programmer can respond to new information about customer needs. With RP this process is straightforward and allowed, while normally it indicates an analysis or design error in other methodologies.
Equally important is an easy way to test new ideas. The final product will be better if you have some sort of playground to find out before implementation whether or not your bright new concept is really as bright as you think. This is even more important in our fast changing world where we have to react quickly to new or changing demands.
Using rapid prototyping for software development does not necessarily depend on a language specifically designed for it. It is possible to use compiled languages like C/C++, but best results can be obtained with an easy to learn/easy to use interpreted language. To get the most benefit, turnaround times have to be short and modifications to existing code should be possible without much effort.
One area where rapid prototyping really shines is user-interface design (provided you have the right tools). You can create a dynamic visual model with minimal effort and provide users with a physical representation of key parts before system implementation. You can accommodate new or unexpected user requirements earlier, and modifications are much easier.
Another aspect is quality assurance and control. The same tools used to build the prototype can be adapted to build up a test harness that is useful up to the final implementation of the system. This results in fewer changes after delivery and therefore productivity improves.
One of the current trends in computer languages is the use of portable languages like Java, Perl or Tcl. While these are generally slower than a compiled counterpart they offer a lot of advantages for the developer (portability, simplicity, short turnaround times, etc.). If such a language can integrate compiled code (e.g., by using shared libraries), a developer can first concentrate on creating a working solution and later optimize the code at the critical spots.
Tcl/Tk is especially well-suited to rapid prototyping, as it has solutions to all of the requirements discussed above:
It's simple to use and to learn.
No compilation or development overhead is required—just write and run your code.
Graphical user interfaces can be built with very little effort.
It can be used for testing (through the use of its introspection facilities).
I do not wish to begin a language war here—the above statements are my own opinions. To make the best use of any language you need to know the language very well (Tcl is no exception) and you need the corresponding tools (syntax sensitive editor, debugger, performance analyzer, testing and documentation tools). Finally, you need a lot of good libraries and extensions which give you the power to create big applications with only a few lines of code.
- Android Candy: Google Keep
- Readers' Choice Awards 2014
- A Little GUI for Your CLI
- Handling the workloads of the Future
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- diff -u: What's New in Kernel Development
- Synchronize Your Life with ownCloud
- Days Between Dates?
- December 2014 Issue of Linux Journal: Readers' Choice
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane