>>>Bill Janssen said:
> [ I unfortunately just posted this to gnu.misc.discuss, so thought
> I'd share it with you, too. /tilde/janssen/doc/why-I-dislike-Tcl.txt ]
>
> I think that what rms sees in Tcl is what many people with taste see
> (and, apparently, many people without taste don't see); a conjunction
> of two things, which taken together make Tcl despicable.
>
> 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 --
Bill, *flame on*, you are ignorant!
Tk is probably the best window system toolkit available for X.
You yourself spent considerable time porting it to Python.
Too bad Tk version 4.0 is due out soon - more porting work for you!
I think it boils down to the "offensive syntax" for you. You just
can't handle it. As you say, this is a matter of taste. However,
you have let this cloud your vision and you choose to ignore the
large and growing collection of useful things you can do with Tcl.
Slow, lacks byte-compilation, internal binary representations:
This is the weakest aspect - but it is not precluded by the language
design. It hasn't been done because:
The whole idea of Tcl is to have big chunks of C code that
provide some high level functionality, and then an altogether, much
more free-form medim in which to compose that functionality.
You just don't get it. The Tcl/C interface is very clean. Mohan
spent *1 day* learning Tcl and integrating it into his application,
including adding a custom event loop so he could deal with his existing
real time jpeg decoding board and graphic display. He has lots of
C code and just a bit of Tcl and Tk so he could easily craft a UI
for his tool. What combination of awk and sed would provide this?
How clean is the Phyton event loop - can I write my own?
Lacks dynamic loading of object code. WRONG - /import/tcl/bin/superwish has
the load command and is set up to dynamically load a number of
extensions. There are several implementations of this, and the only
thing holding it up from the mainline Tcl code is the lack of agreement
among vendors about how this works in various systems.
Lacks ability to extend Tcl in Tcl. WRONG - as well as obvious things like
procedures, there are constructs that let you write new control structures,
plus variable tracing and other facilities that give you incredible control
over the interpreter. Can you implement a read-only variable in Python?
I can in Tcl. Can you trigger actions when a variable is set in Python?
Is it easy to tie the value of a Tcl variable and a Python variable
together such that when you change one in one domain it is reflected
in another domain? I can in Tcl.
A standard object system. A package called [incr tcl] is becoming
the defacto object standard for Tcl.
> 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.]
The value is not in the language per se, it is what is available via
the language and the software engineering of the package.
> But this is hardly a crime -- a lot of good hackers start out with a
> bad extension language. I'd hate to count the number I've seen.
Ousterhout was motiviated by several bad command languages that he had
written for various (real) tools, such as the Magic design automation
tools.
> The second thing is that John Ousterhout is (was) a professor of
> computer science at a renowned university, and therefore *should have
> known better*. He has a well-deserved reputation in systems research
> and implementation. He should have known more about the design and
> implementation of extension languages, but his design of Tcl reflects
> either ignorance or bad judgement in making trade-offs. By now, he
> *must* know better -- and yet he continues to push Tcl. This is
> disappointing at best, and judgmental types might find it
> reprehensible. In the final analysis, pushing this kind of inferior
> technology retards the advancement of civilisation -- infinitesimally
> perhaps, but absolutely.
Granted, most everyone at Berkeley asked "why not lisp", and he can be
faulted for not paying attention. However, it appears that he may have
been right, which is the hardest thing for you to swallow. The market
is C programmers that have used UNIX shells. The market is not Lisp
machine hackers. The leap from C and UNIX shells to Tcl is not a hard one.
The plethora of extension packages (C libraries with a Tcl interface) is
testimony to the success of Tcl, even in comparison to something like
Python, as wonder a "language" as it is.
> For some of us, these two items taken together make it difficult to
> to use, or even contemplate, Tcl, without repugnance.
Too bad for you...
-- ---------------------------------- Brent Welch Xerox PARC