Re: Why you should not use Tcl

Jeff Dalton (
Tue, 4 Oct 1994 20:17:14 GMT

In article <36eshf$> (Wayne Throop) writes:
>: From: (Darin Johnson)
>: And this got me to thinking that perhaps there are a lot of Tcl users
>: claiming that it's simpler to use than Lisp for the same sorts of
>: reasons. They've heard that Lisp is hard, and they figured out Tcl,
>: so Tcl must be simpler and more elegant.
>An interesting perspective, but I think there are legitimate reasons
>for a claim that tcl is simpler than lisp, and more approachable as
>a scripting language.
>In approaching each language for the first time, just consider
>explaining how the basic forms of the language are interpreted. In
>lisp, you tend to have a discussion about functions, macros, and special
>forms, and why it is that you sometimes need to quote things, and
>sometimes you don't because the context does it for you, and why some
>things are funcallable and others aren't. And to write macros of any
>complexity, you need quote and backquote and on and on and on.

I don't think it *has* to be that complicated, much less "and on and
on and on". For instance, in recent Lisps, functions are funcallable
and other things aren't. Quotation is often presented in a way that
makes it confusing, but it needn't be. (I find it easier to deal with
Lisp quotation than with quotation, escaping, etc in shells, for
instance.) You can write fairly complex macros w/o using backquote
(consider extend-syntax, e.g.). And so on.

(It's clear that the Lisp/Scheme community has often failed to present
Lisp-family languages clearly and has often allowed a fair amount of
historical clutter to accumulate. But I believe it's possible to
do much better. In describing what goes wrong I'd make similar lists
to yours. Indeed, I've presented Lisp in just that way: functions,
macros, special forms; what things "evaluate their arguments"; etc --
and seen how confusing it can be.)

I'm not going to compare Lisp to Tcl, since I don't know enough
about Tcl.

>This same contrast applies to lots of other topics, like variable
>namespaces, symbol namespaces, data types, and many more. Try
>explaining EQ/EQL/EQUAL, and why fixnums and bignums behave as they do,
>as compared to a similar explanation for tcl. And that's before we even
>get into historical bizarities like why both CAR/CDR and FIRST/REST. In
>each case, tcl kills 80% of the birds with 20% of the stones. This
>makes the learning curve for tcl noticeably less steep than that for lisp.

Again I don't think Lisp has to be that bad. Lisp doesn't have to
be Common Lisp, or even Scheme. A Lisp-like language could have a
very different syntax (Dylan, Pop11) and simplify things immensely
compared to the sort of Lisps you seem to have in mind (both car/cdr
and first/rest suggests Common Lisp).

>Note I am not saying in any way shape or form that tcl is "better" than
>lisp, or that lisp is *fundamentally* a hard language to learn. I'm
>saying that there are legitimate reasons for categorizing tcl as
>"simpler" than lisp, and legitimate reasons for supposing that the kind
>of simplicity tcl displays is useful in many scripting language domains.

That's the kind of line I like to see, and I am entirely ready
to agree with it.

Moreover, I find explanations of why something is seen as simpler,
more readable, etc, very useful. Such views are not just brute,
subjective facts. There are reasons and, indeed, good reasons and bad
ones. Unfortunately, it's difficult to offer such explanations
without people treating them as arguments that somethine *is* simpler,
more readable, etc. There's a tendency to treat things as purely
subjective or objective and hence to treat reasons as arguments and
explanations of why something is seen in a certain way as "religious
arguments" (treating the subjective as objective).

[excellent discussion of lexical minimalism deleted]

Thanks for writing so sane an article in what seems to be a flame fest.

-- jd