''''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.''' 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. Another inefficiency is that all Tcl commands are implemented with Tcl API functions plus a wrapper function. C Functions cannot efficiently access the ''Tcl'' functions 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. 1. ''Byte Coding.'' Byte Coding is 1970's technology; it did not perform 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 optimizer for scripting languages that does not penalize the use of scripting concepts. ''e.g. set var [[choose AFunction]] ; $var $*myoptions'' 1. ''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. 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 and more, are never quite enough to be useful in an application. Recent additions such as the [VFS] likewise duplicate functionality provided by the host OS but fail to add enough ''oomph'' 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 Tr, traces are used to attach variables to widget's 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. 1. ''Unnecessary limitations and inconsistencies.'' These are too many to list. The most notable are in the treating of array variables and the 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. ''i.e. 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 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 [http://purl.org/tcl/tip/144] 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[http://purl.org/tcl/tip/111], 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[http://purl.org/tcl/tip/112] 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... ;^) ---- [TV] Finally someone saying the words.. No, seriously, always good to have people with opinions, maybe especially currently in computerland. I like tcl and tk enough, and it seems that the writer at least uses it a lot, so I take it this page is sort of constructive criticism. Maybe it is hard to write a good language, maybe, as I feel it, at least some serious 'issues' in the programming world come from a not completely well adjusted view of how things (primarily computers) run, and how the things which were the reasons have evolved. Linux being an interesting example of getting back to essentials, while windows developing into styles, late copies of long ago research and closedness (at least as inclination). See heer heer to openess (open-ness?) and intellectual and other discussion. 1. ''List of Args or Arg list.'' I found the remark 'everything is evaluated exactly once' enlightned enough 1. ''Speed.'' every try to full-search through 30000 database entries in tcl or sq or another programming language (except maybe grep in C), at least the speed definition is at stake here (see link below). 1. ''Designed as an Embedded Language.'' Why? It had origins in chip design when I'm remembering correctly, what's un-independent about running it? 1. ''Complex API.'' Maybe reorganising is possible, but did you ever look at the C, C++ (gmpf), Java (oho), or any other api? 1. ''Byte Coding.'' Didn't test that enough, donno 1. ''Bad Marketing.'' as in that tclers don't get enough exposure? 1. ''Lack of a Niche.'' it's fine enough as it is with me 1. ''Design by committee.'' Interesting point, I'd be inclined to think that about various extensions, possibly in the OO range, but that might be taken as offense and isn't realy intended to. 1. ''Unfulfilled Potential.'' 1. ''Unnecessary limitations and inconsistencies.'' It's sort of the way it has always been like in lisp: quote and eval at the right point, when you precook that, some of the generality is sacrificed. Not directly related maybe to this page, but certainly to the discussion, I though I'd sum up and deal with the [Three major computing quantizers 1: Sockets] , because it is hard if not delusive to discuss language issues without qualifiers and quantifiers which actually mean something, have objective unambiguous value, and are essential to the machinery at hand. ---- [Category Suggestions]