 | |
 | |
 | ||||||
contents
| 7 - Conclusion Tcl started its life as an extension language for C. But in many ways it has become a victim of its own success - for a growing number of scripters C has become an afterthought and inconvenience. Even those who (reluctantly) code in C know lots about Tcl, and very little about compilers, linkers, make, autoconf, etc. The key benefit of Critcl is that it reduces barriers to adding C code to application, barriers caused by needing to know too much about Tcl extension structures, build environments, compiler tool chains, etc. And in doing so, it addresses the (often heard but equally often fallacious) concern that "scripting programs are too slow". Rather than build in a compiled language, Critcl allows an application to be developed in Tcl/Tk - with all the associated productivity and flexibility benefits. In the event that a performance bottleneck is identified, Critcl allows that bottleneck to be recast in C. But more importantly, it allows this decision to be deferred - there's no sense in scratching before it itches. And by allowing the developer to continue working with Tcl, it increases the chances that performance will addressed at the architectural level. But Critcl also takes the Tcl concept of "glueware" to new levels. One can start with a Tcl/Tk interpreter (either a traditional tclsh/wish, ActiveTcl or TclKit) and develop with Tcl being at the center and everything else being small pieces of C code. Critcl becomes the means to "run that last mile", to get performance and to connect to other C code. And it potentially saves a significant amount of time, since there is no need to know about build environments, tool chains, etc. So, Critcl has come from being an experiment in defining C procedures for performance, to being a new way of building Tcl extensions, and potentially Tcl itself. And, perhaps, it could become a stepping stone to a leaner, meaner and more modular Tcl/Tk core. Then the circle will have closed -Tcl will no longer be a victim of its own success in removing the need for compiled applications. Acknowledgement Thanks are due to Mark Roseman for his patient reading of the draft of this paper, his insightful comments and his uncanny ability to spot even the smallest typo. Thanks also to Larry Virden for generously giving his time. | see also | ||||
| | | | | | |
| | |