''''Discalaimer''''

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.''''

   1. 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.

   1. 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.

   1. Designed as an Embedded Language.

TCL was not designed with a view to being a complete language. It was
always pushed as an adjunct to a 'Mother' language and thus has this baggage to this day.

   1. 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.

   1. 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.

   1. Bad Marketing.

Historically, TCL has had poor press that has not been effectively rebuked by the TCL TCT or JO. The attitudes shown parallel those between Apple Inc and Microsoft. History shows that marketing wins over technology.

   1.  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).

   1. 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.

   1. Unfulfilled Potential.

TCL's advanced features such as event driven IO, traces, command Aliases, the 'unknown' handler, namespaces.
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 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.


''''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.