Re: Why you should not use Tcl

John Ousterhout (ouster@tcl.eng.sun.com)
26 Sep 1994 18:13:27 GMT

There have been so many follow-ups to Stallman's message that I'm not sure
there's any need for me to respond, but I would like to say a few things
anyway:

First, I'd like to encourage everyone to keep their responses cordial and
technical, rather than personal, regardless of how strong your opinions
are. Comp.lang.tcl has managed to avoid flame-wars pretty well so far;
let's keep it that way by focusing on the technical issues rather than
worrying about motives.

I think that Stallman's objections to Tcl may stem largely from one
aspect of Tcl's design that he either doesn't understand or doesn't
agree with. This is the proposition that you should use *two* languages
for a large software system: one, such as C or C++, for manipulating the
complex internal data structures where performance is key, and another,
such as Tcl, for writing small-ish scripts that tie together the C pieces
and are used for extensions. For the Tcl scripts, ease of learning,
ease of programming and ease of glue-ing are more important than
performance or facilities for complex data structures and algorithms.
I think these two programming environments are so different that it
will be hard for a single language to work well in both. For example,
you don't see many people using C (or even Lisp) as a command language,
even though both of these languages work well for lower-level programming.

Thus I designed Tcl to make it really easy to drop down into C or C++
when you come across tasks that make more sense in a lower-level
language. This way Tcl doesn't have to solve all of the world's
problems. Stallman appears to prefer an approach where a single
language is used for everything, but I don't know of a successful
instance of this approach. Even Emacs uses substantial amounts of
C internally, no?

I didn't design Tcl for building huge programs with 10's or 100's of
thousands of lines of Tcl, and I've been pretty surprised that people
have used it for huge programs. What's even more surprising to me is
that in some cases the resulting applications appear to be manageable.
This certainly isn't what I intended the language for, but the
results haven't been as bad as I would have guessed.

I don't claim that Tcl is without flaws. Some of the flaws, like the
lack of a compiler and the lack of module support, will get fixed
over time. Others, like the substitution-oriented parser, are inherent
in the language. Is it possible to design a language that keeps Tcl's
advantages, such as simplicity, easy glue, and easy embedding, but
eliminates some of its disadvantages? Almost certainly (there are
several decisions that I would re-think if I were starting over). Is
the two-language approach really the right one? I still think so, but
reasonable people can disagree.

Language designers love to argue about why this language or that language
*must* be better or worse a priori, but none of these arguments really
matter a lot. Ultimately all language issues get settled when users vote
with their feet. If Tcl makes people more productive then they will use
it; when some other language comes along that is better (or if it is
here already), then people will switch to that language. This is The
Law, and it is good. The Law says to me that Scheme (or any other Lisp
dialect) is probably not the "right" language: too many people have
voted with their feet over the last 30 years. I encourage all Tcl
dis-believers to produce the "right" language(s), make them publically
available, and let them be judged according to The Law.