> The first is that Tcl is just not good enough, for anything. That
> is, for any given task, there is a better extension/scripting
> language to use. Tcl is slow and clumsy with offensive syntax. It
> lacks byte-compilation, internal binary representations, dynamic
> loading of object code, ability to extend Tcl in Tcl, a standard
> object system -- a whole host of well-understood things. Yes, it
> does have a few bright spots, such as Tk and a string-processing
> ability with good functionality. But they aren't enough. For any
> given task, python or elisp or perl or awk or ELK scheme is a good
> implementation of a better language. [Python in particular has
> impressed me lately.]
One can argue about some of these things. What *is* clear is that at
least some of us find Tcl syntax OK. I wouldn't want to write
anything big in it, but for scripts of a hundred lines or so it's
fine.
What really makes it win is that it seems a more mature product: I've
looked at STk, for example, and I couldn't get it to work. In
technical terms, of course, that's not such a good reason for choosing
a language, but when Tcl/Tk works for me and is adequate for what I
want to do, and STk (although it looks nicer in some ways) crashes,
then I'm going to pick Tcl/TK (especially given the availability of
good documentation).
The efficiency points are to an extent not relevant, since the idea is
that only the interface should be in Tcl, and Tcl seems fast enough
for that. I'm a bit concerned that John seems to want to extend Tcl
to inter-program communications and stuff---the more you want to use
Tcl for, the more likely it is that you're going to want it to be
fast at some point. The talk of a byte compiler is all very well, but
the language seems not suited to byte-compilation.
I can see hope, however. Rush looks a lot like Tcl, so it should be
accepted easily by the Tcl community, and according to the
documentation I've seen, corrects most of the obvious errors in Tcl.
In addition, it appears to impose type-checking a bit earlier, so it
should be easier to debug scripts.
I hope John's team adopts rush or something similar, rather than
sticking with Tcl: I realise this is yet another change in syntax, but
rather now than later.
I like the "hypertools" idea, with lots of small utilities cooperating
to achieve tasks, and I like the idea of using a scripting language
(which might be interpreted), but lets not shoot ourselves in the foot
by choosing one that's unnecessarily difficult to compile when it
becomes necessary to make it fast.