Disclaimer edit
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.PWQ 11 Sep 2003, Thanks for the comments, I was trying to be constructive as well just venting. Maybe at the end of the day I am the idealist :)Deficiencies in Tcl edit
- 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 conditional primitives (by design) 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 was always 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 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.
- 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
- 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 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.
- 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 edit
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 edit
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 its 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's response to these items edit
List of Args or Arg list
See [1] for one proposal for how to fix this. This is a topic of current discussion within the TCT. [AMG see {*} for the Tcl 8.5 implementation.]PWQ A fix to overcome a design flaw?, what about a redesign so that the patch is not necessary?DKF: I think you are not quite grasping why things are the way they are.PWQ I am aware of TCL's evolution, what I am hinting at, is that this evolution has no got us to a place that I believe we don't want to beSpeed
8.5 will have a new datatype, the dictionary[2], 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.PWQ It is merely a statement of fact, That has an impact on those of us (i.e. me) that tries to use TCL as an Application language.DKF: Please say more on this...PWQ Glad to, but it is long and involved, I will post a new thread at some stage to elaborateComplex 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 implemented 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?PWQ Then why then use a scripting language at all, what's the point?DKF: Pardon? You use a scripting language because it is an arse to do it all in C, even with the help of a very good library.PWQ And there's the kicker, 'all' in C. Looks like we should have just gone straight to Objective C then and not bothered with TCL.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.PWQ It's still a VM on top of a CPU, it can never perform, my point if I have one, is that the internals should not need a byte code compiler to perform well, is it possible to achieve this by a redesign of the internals?.DKF: I'm not normally impolite, but it is my considered professional opinion that you don't know what you are talking about here. :^)PWQ Since your are an academic, I won't take it as an insult. Feel free to be as impolite as you like, maybe we will communicate better. I know what I am saying, do you?, if we take byte coding to its N'th degree we get 'ahead of time compilation'. If we head for compile/debug cycle why script.Bad Marketing
So we should go out there and slag off Richard Stallman et al? Isn't that rather counterproductive?PWQ It is never counterproductive to slag off Richard Stallman PWQ And its also never counterproductive to slag off the glibc developersLack 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[3] though.PWQ My experience is that every TCL developer has a different vision and this is why TCL is what it is today.DKF: You're of the belief that we should all drink the kool-aid and get a conceptual monoculture? Phooey! There's lots of people doing cool stuff which I would never have thought of doing, and Tcl is supporting them just as well as it is supporting me.PWQ Now it's my turn to ask, what's your point?. I hear the same argument with (Forth, Smalltalk, python, et al). When we look at in detail, all the "cool" applications are written in "C".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 inconsistencies
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 compatibility. But then we'd expect there to be many scripts from 10 years ago which can still run on the latest version of Tcl...PWQ Imagine the chaos if you redefine if and while, but you can and sometimes it is useful. Why limit the programmer if they know what they are doing.DKF: You had a point there?PWQ You were the one that brought up the argument of "chaos"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).So 'hear, hear' to openness and intellectual and other discussion.
- List of Args or Arg list. I found the remark 'everything is evaluated exactly once' enlightened enough
- 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).
- Designed as an Embedded Language. Why? It had origins in chip design when I'm remembering correctly, what's un-independent about running it?
- Complex API. Maybe reorganizing is possible, but did you ever look at the C, C++ (gmpf), Java (oho), or any other api?
- Byte Coding. Didn't test that enough, donno
- Bad Marketing. as in that tclers don't get enough exposure?
- Lack of a Niche. it's fine enough as it is with me
- 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 really intended to.
- Unfulfilled Potential.
- 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.
PWQ 11 Sep 2003. The problem with any discussion, is that there must be a common frame of reference. On TCL itself, there must be a common ground for what defines a good vs bad feature.It is clear from the comments to my views , that I have a different view on what is good/bad about TCL. To clarify:
- Better means more efficient, in both time and resources.
- Bad means inefficient.
- Good means Changes achieve their objectives.
ulis, 2003-09-12: Let me say with you:" 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 its 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. "No word to displace.DKF: But if people won't say what sort of Grand Synthesis they have in mind, its hard to make it happen. Alternatively, offer (say) £100k/year for someone on the TCT to work full-time on updating the core instead of having a day-job and watch them fulfill their idea of how the language should be.FB: Speaking of Grand Synthesis, that's what I'm trying to do with Cloverfield. My current proposal (Cloverfield - Tridekalogue) is a first shot at what Tcl could become, i.e. my vision of [Tcl9], expressed in a similar way to the current Dodekalogue (an interesting exercise in style). But my goal is to refine this proposal by gathering people around a common vision. That is, unless the community is too balkanized about what [Tcl9] should be, in this case [Tcl9] has no chance to happen anytime soon.Also, I don't think the problem is that there is "no one on the TCT with the vision to achieve this" (because you - DKF - seem to have your own vision, too, and I share many of your points), but rather that Tcl has no visible leader. This means that change must come from the outside or be a personal initiative. The TCT was never meant to be a design committee (and shouldn't become one, as design committees are A Bad Thing) but a team of volunteer maintainers. And while the TIP process is suitable for incremental changes (the transition to Tcl8.5 is quite an accomplishment), it is IMHO unsuitable for major changes such as those needed by [Tcl9]. Among the oft cited requests, a TIP to change the way comments behave has no chance to be ever accepted, let alone written.DKF: In any case, whatever my views on other things, I find it hard to deal with stuff wholly in the abstract (even with my own projects, such as TclOO) so it would help me enormously if there was some actual code I could run. I find it far easier to work out what's good and what's bad about a particular set of design-tradeoffs when I can try them out for real. I think lots of other people are the same. But a consequence of this is that when proposing a big change, it's a good idea to write some of it first. (This serves to filter out the totally impossible things which people propose from time to time. ☺)
FW: Tcl actually has a rather well-defined niche, and it's neither strictly for creating full-fledged applications nor as an embedded language for user scripting, though it's been used quite elegantly for both of those tasks in many cases. See Ousterhout's Dichotomy.
