'Disclaimer'
This page is an adjunct to the page Things holding Tcl back.
People holding religious view about Tcl, or those that would consider themselves idealists should refrain 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.
Deficiencies in TCL.
For example a command alias cannot handle infix or prefix arguments.
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 no one 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 upon that will never catch on as it requires a level of understanding about programming techniques that are simply not present in new programmers.
DKF responding to these items...
List of Args or Arg list. See [L1 ] for one proposal for how to fix this. This is a topic of current discussion within the TCT.
Speed. 8.5 will have a new datatype, the dictionary[L2 ], which should help with much of the specific points here. The language is also open to other new datatypes if people propose them. As always, please bring any specific issues to the attention of the TCT and the core maintainers.
Designed as an Embedded Language. So what would you have it be, eh? Long experience tells us that trying to do everything ends up with doing many things extremely badly.
Complex API. Tcl has a lot of functionality and much existing code. This naturally leads to a substantial API and there is definitely some baggage in there. OTOH, radical trimming of the API would alienate many existing uses. You can't have it both ways. By contrast, Lua stays small by providing virtually nothing at all. Any old idiot can do that. Another inefficiency is that all TCL commands are implmented with TCL API functions plus a wrapper function... To me, this indicates that you've got your thinking ass-backwards; the high level stuff is implemented in terms of the low-level stuff, so why should everyone have to deal with the additional cost of the high-level when they know exactly what they are doing?
Byte Coding. I'd be fascinated to see JIT compiler for Tcl, but the language's semantics have many (very useful) features that do not make writing such a beast an easy task. Plus Tcl's bytecodes are not just some random set of generic codes which someone thought ought to be enough to implement anything, but are instead tuned to dealing with those parts of the language that actually deliver real benefits to many people through being boosted.
Bad Marketing. So we should go out there and slag off Richard Stallman et al? Isn't that rather counterproductive?
Lack of a Niche. I don't know about you, but I have a vision for Tcl. I have a day job though, so time to work on bringing that vision forward is not in vast supply. You can see some of it in TIP#112[L3 ] though.
Unfulfilled Potential. Often, the principle has been to make common things easy. Doing all the rare stuff adds a lot of extra development and maintenance effort, so if hardly anyone is going to use it why bother? Any time you feel that there is something that absolutely should be there but isn't, you're welcome to submit a TIP and implementation to alter the situation. There is also a concrete lack of examples in the manuals that show the power of these features. We'd love to have more examples, and would welcome submissions from anyone.
Unnecessary limitations and inconsistancies. On the specific points you list, whole arrays are not values because values are values; imagine the chaos if you could reassign the value 0 to the value 1! This is a deep consistency matter, but you seem to feel that the only valid interpretation of consistency is your own. I agree that info is a bag of things that don't fit anywhere else. That's what it does. And there's a few cases where consistency of command naming schemes has been sacrificed in favour of keeping backward compatability. But then we'd expect there to be many scripts from 10 years ago which can still run on the latest version of Tcl...
In closing. It seems you prefer the cathedral model of development to the bazaar. (And watch out, JO is on the TCT... ;^)