MetaCard Corporation

Part 8: Best use of the tools and conclusion

Tcl/Tk shines in longer term projects, especially when it's embedding capability can be used. Projects that require specialized commands and widgets would be easiest to produce in Tcl/Tk as will those that require manipulating complex data structures.

The fact that Tcl/Tk is free also makes it an attractive package for universities and other budget conscious operations. The extensive range of extensions and specialized tools, especially those that allow connection to relational database systems, may make producing some applications quicker than is possible in dtksh or MetaCard where the database connectivity layer may need to be written in C from scratch.

The best application of dtksh is for one-time projects, especially if the developer already knows the ksh language and the Xt toolkit. It also is a viable option when a Motif widget that meets the current needs of the developer is already available either free of charge or from one of the vendors of add-on widgets. It should also be free with most UNIX operating system upgrades, which will be an advantage for budget conscious organizations and for users that only occasionally use the tool.

On the other hand, dtksh is by far the most difficult tool to learn and use. It is also the least efficient both in terms of performance and lines of code that must be written to solve a given problem. The weak text widget and lack of support for for vector and bitmap graphic objects also means that in most cases it will take longer to develop an application in dtksh than with the other tools. Due to the design of ksh (no true functions or local variables, and great dependency on global variables), large dtksh applications will be much more difficult to maintain than large applications written with either of the other tools. Finally, the bleak prospect for portability means that dtksh is not the tool to use to develop applications that need to run on non-UNIX operating systems.

MetaCard's IDT puts the other two tools at a severe disadvantage for all but the most trivial layout tasks. For most small applications, the ability to use an IDT far outweighs any of the other features the other tools provide. MetaCard is also the easist tool for non-programmers to use to aid programmers in the design of an application, since they don't have to learn the scripting language to begin prototyping. The persistence of MetaCard applications and the built-in database also make it easier and faster to develop applications that require maintaining information across invocations of the application.

In addition to its overwhelming performance advantage over the other two, the MetaTalk scripting language is also the easiest to learn and to use, since it is syntactically much simpler than the other two languages. It is also relatively free of the dependence on global variables for basic operations that plague the other two languages. The GUI script debugger is also always available to handle those rare cases a scripts behavior can't be understood by simply reading it.

MetaTalk also supports a much wider range of built-in commands and functions, such as those required for multimedia applications, than the other two tools. Since MetaCard doesn't require construction of the interface in the scripting languages, the scripts for MetaCard applications are typically much shorter than for the other two tools, and so are easier to maintain.

Conclusion

Tcl/Tk, dtksh and MetaCard all offer a vast improvement in GUI development productivity over toolkits based on C or C++. They should be considered as a first choice for most application development. Shorter scripts, which take less time to write and less effort to maintain than code written in a third generation language is only one of the benefits.

Perhaps even more important are the improvements in the quality of applications developed with these tools. First of all, fewer statements necessarily means fewer bugs. In addition, the pointer and memory leak bugs that are so common in applications developed with C and C++ environments are eliminated by design with these tools. Finally, the fact that applications can be developed faster and modified more easily makes it more likely that an application will be tuned to suit the needs of end users.

As these tools are improved to make application development even easier, it seems likely that they will gradually replace C and C++ based development environments for almost all graphical application development.

On to Acknowledgements and references

Back to Application deployment and support

Up to Table of Contents