While we hope the lessons we have discussed above help other developers as they build innovative applications in Tk, in many ways the more important message involves higher level principles of application design and development. In this section, we discuss some of the higher-level lessons that we learned, evaluate how well Tcl and Tk serve as development tools, and discuss some improvements.
Innovative applications do not have specifications. Developing the neighborhood browser was exciting because neither we nor our users knew what the application would become. It has been a long and continuing process for computer scientists to learn what is meaningful and useful to the neuroscientists and for neuroscientists to understand the range of options that can be provided. Most of our progress has been made in baby steps, rather than great leaps, because great leaps require too much understanding. It is easy for a computer scientist to say "oh, we'll build you a 3D visualization of the brain," but it takes time to understand why a 3D visualization is not as useful as the right combination of 2D images. Developing innovative applications and interfaces is an inherently iterative process, and the requirements and specifications evolve as development proceeds.
Turn-around is creativity. Baby steps denote incremental rather than revolutionary progress. To invent an novel interface and application, therefore, requires many baby steps, and as a result the potential for creativity is directly related to the speed with which you can implement the next idea. It is hard to be creative when each prototype revision takes weeks or even months. With the neighborhood viewer, minor revisions could be implemented the same day or overnight and major revisions often could be implemented in only a few days. At the extreme, we would be even more creative if we could prototype revisions as quickly as we brainstorm ideas.
Your flexibility is constrained by the flexibility of your tools. If turn-around is creativity, then rapid development tools provide that creativity. It was essential to our development process to be able to change the interface and the application on short notice to obtain feedback from our users. We used Tcl and Tk because the combination of a scripting language, an interpreter that is active at run-time, and a clean interface to both stand-along programs and compiled C and C++ code gave us the flexibility to quickly modify the interface (while an application is running) and to quickly integrate other applications and code into the application. Our rapid incorporation of wavelet-compressed images is one example of the flexibility of Tcl and Tk. At the same time, Tcl and Tk let us down in certain areas. Until we started to use TclProp, there was no flexible mechanism for connecting many views together. The difficulty in modifying change propagation stunted our ability to expand beyond simple view synchronization to more exciting and innovative interfaces including multi-screen and multi-user interfaces with flexible coupling. Even TclProp was not sufficient by itself, leading us to develop a distributed TclProp. Similarly, Tk provides few hooks to make it possible to monitor changes to widget attributes (only a few attributes have variable connections). We are examining better ways to address this limitation for a future release of TclProp.
Nobody writes advanced programs in a low-level language. As human beings, our thinking is related to our vocabulary. Just as nobody writes a compiler by thinking exclusively about zero and one bits, we could not write the neighborhood viewer until we extended our language to include concepts such as constraints from TclProp, remote procedure calls from Tcl-DP, image handling functions from our wavelet library, and, of course, interface widgets from Tk. Extensions to Tcl are not "extras," they are the core of what makes Tcl worth using. Dynamic loading of extensions and libraries is a good step in the right direction. Still, there is great demand for further support for authors and users of extensions and libraries including: naming and version support, support for user customization, and well-indexed libraries to help people find the code they need.
Don't widen the bottom of the bottle. The bottlenecks in the neighborhood viewer are the image processing, disk, and network access. The wavelet code is all in C (quick experiments showed that Tcl was not fast enough for the computation), but all of the application assembly is in Tcl. Unless it is used for intensive computation, Tcl code is rarely going to be the bottleneck for I/O and computation-intensive applications.
Tcl/Tk is an excellent tool for developing innovative applications -- let's keep it that way. We have had great success with Tcl and Tk, and are encouraged by the continuing development of new extensions and libraries that expand our vocabularies and thereby widen our horizons. Experiments with the early alpha version of SpecTcl show promise for another exciting tool that will help speed up our turn-around and increase our creativity. A key concern for the coming years is portability -- the ability to distribute a Tk application without sending a new wish, and the ability to easily find and load needed extensions with version control.
Finally, there is one message that is important enough to merit its own section.