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 :)
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.
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.
See [L1 ] 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 be
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.
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 elaborate
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.
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.
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 developers
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.
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".
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.
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"
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.
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.
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:
DKF: Whose time? Whose resources? Which objectives? These questions are very relevant!
PWQ I was not aware that any one person owned time. The resources required to run the program, The objectives that were put forward for implementing the change
RS has gone through half a dozen languages and found Tcl best suited for powerful abstraction and KISS programming - better maybe not in terms of run-time or memory consumption, but certainly in reduced coding time and better maintainability (my changes achieve their objectives ;-). The above criteria 1. and 2. would of course let tricky Assembler code win...
PWQ Has also gone though lots of languages. I fixated on C for a long time but now have difficulty in lowering to that level. However my view is that 'C' is the most efficient language and at the end of the day will always get the job done. I cannot say the same about TCL.
Vince - you're right, 'C' is an efficient language that will get the job done at the end of the day, but for many uses a language like Tcl will get the job done by the beginning of the day, because you don't spend all day coding, compiling, linking, debugging, which is quite helpful!
PWQ My experience on comments on the TCL news group that most people develop with an edit/run approach to design and debugging. In fact most of the TCL specific IDE's don't have a link with running interpreters. It would be interesting in a poll to see how many developers actually use [send et al] to change a running program rather than restarting it.
DKF: Some of the UNIX ones have plentiful send support (though some Unix admins haven't quite grasped why it is a good idea to secure an Xserver. >:^( But let's stay away from private grief here...) but it has been lacking on Windows because the send command was not implemented there (since it used an extremely X-specific communication mechanism.) TIP#150[L4 ] should fix that and give Windows users access to the sort of seamless access that has been around on Unix for over 10 years...
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.