'Discalaimer'
This page is an adjunct to the page Things holding Tcl back.
People holding religous view about TCL , or those that would concider them selves idealists should refain from reading this document.
These comments reflect the views of Philip Quaife and are unlikely to coincide with the average low level programmer that is found on the internet today.
Defficiencies in TCL.
- List of Args or Arg list. A function can only return a list of args whereas most functions expect an argument list. This necessitates the use of eval which is not efficient and can also leads to quoting problems.
- Speed. With the limited data types, it becomes difficult to effectively code routines that manipulate structures. This can be demonstrated with the various graph data structure libraries. Copious use of upvar and [array get/set] can be found. Also the lack of selection primitives is a speed penalty that has not been eliminated by byte coding.
- Designed as an Embedded Language. TCL was not designed with a view to being a complete language. It wasalways pushed as an adjunct to a 'Mother' language and thus has this baggage to this day.
- Complex API. TCL currently has over 300 API functions. This is more than the average programmer can cope with. As an 'Embedded' language, it is unlikely to be the one chosen due to the apparent complexity required to integrate. Compare with the Lua examples. Another inefficiency is that all TCL commands are implmented with TCL API functions plus a wrapper function. C Functions cannot efficiently access the 'TCL' function directly and must be coded via the lower level C API functions. This both introduces redundancy as well as reducing the usefulness of redefining core procedures. As an example, if lappend is redefined, no C functions will use this new definition as they directly call the API function TCL_ListObjAppendElement function. This is fine unless you need them to use the new definition of lappend.
- Byte Coding. Byte Coding is 1970's technology, it did not perferm then and it will not do so now. BC is also an anachronism to a true scripting language. Someone needs to think outside the square and design an efficient optimiser for scripting langauges that does not penalise the use of scripting concepts.
Eg set var choose AFunction ; $var $*myoptions
- Bad Marketing. Historically, TCL has had poor press that has not been effectively rebuked by the TCT or JO. The attitudes shown parallel those between Apple Inc and Microsoft. History shows that marketing wins over technology.
- Lack of a Niche. TCL has no niche, it is too bloated as an embedded language, it is too slow for real world applications (get over it).
- Design by committee. Up to TCL 7.6, the main design was one individual and the result reflected his Vision. From 8.0 onwards there has been no 'Vision'. Development has been Reactionary rather than Revolutionary.
- Unfulfilled Potential. TCL's advanced features such as event driven IO, traces, command Aliases, the 'unknown' handler, namespaces and more, are never quite enough to be usefull in an application. Recent additions such as the VFS likewise, duplicate functionality provided by the host OS but fail to add enough omph to justify the effort in learning to use them. There is also a concrete lack of examples in the manuals that show the power of these features. As an aside example, in TK traces are used to attach variables to widgets values. You cannot attach a variable to other properties such as colour so why bother using traces when the rest of the code must access the widget directly. You can attach a list to a 'listbox' widget but not its current selection. Half the code deals with manipulating the list, the other half must manipulate the widget directly. Aliases and traces can be used to implement OO and other paradigms, but never quite implement 'all' of them (such as true polymorphism). For example a command alias cannot handle infix or prefix arguments.
- Unnecessary limitations and inconsistancies. These are too many to list. the most notable are in the treating of array variables and they way commands process arguments. For example, while the $var notation is an extension to save typing [set var], it does imply that arrays should be able to be treated as first class variables. Alas they cannot. Some commands have special top level names while others of the same class are sub commands of some less related command name. IE. info xxx (what a mess of eclectic functions)
Summary
TCL has some advanced and novel (but now not unique) features that merit having a place in history. However to get the language to 'perform' requires a skilled programmer that also knows the internals of the interpreter. From experience, the first 80% of an application can be coded very quickly, however the remaining 20% can be so much effort that it is better to use another language in the first place.
In Closing
I use TCL for programming every day, and when possible I use TCL for my clients in commercial jobs.
I however take no interest in the current TCL development process. I believe that TCL has gone as far as it can go without pulling it apart and putting back together.
I see noone on the TCT with the vision to achieve this.
Personally I think TCL was a language ahead of it's time with a syntax that cannot be improved apon that will never catch on as it requires a level of understanding about programming techniques that are simply not present in new programmers.