Let me see if I can untangle a couple of things. First, whatever I
think of rms' presentation, I more or less agree with at least one
of his conclusions: that there is a better language out there than
tcl for its purposes. I would even go so far as approve of a more
scheme-ish language. (I *like* Scheme for reasons that anyone who
likes it might; I *use* tcl, because it's the best tool I have for
the jobs I use it for.)
But that very much misses the point. It's not (necessarily) his
conclusions I disagree with, it's his method. Now, rms may
believe that if it doesn't have first class arrays, it doesn't
have arrays. And if he wants to present that view in his own
little playground, I don't have to play there. But his message
was posted far and wide, with a request for it to be spread
farther and wider. For *years* there are going to be ill-informed
individuals who will, because rms is a "name", will quote "tcl
doesn't have arrays" and there will be many people who won't give
tcl the time of day because "rms said tcl doesn't have arrays".
I'm all for spreading the word, good or bad, provided that those
who get the word aren't mislead. But distributing misleading
information like that is simply wrong.
With that out of the way, I'd like to talk a bit about the subject
itself.
Tcl's main problems from my point of view are:
1) Tcl is inadequately semantically transparent. Too often, I
have to actually interpret a statement to figure out just
how to interpret this character or that. This comes from
having "\{[ all as bracketing operators in approximately
the same syntactic locale. There will always be such
problems as the complexity of semantic units increases
(e.g., think of a complex C expression involving operators
of half a dozen precedence levels) but a language can be
designed to minimize this.
2) Tcl lacks adequate data structuring. You *can* do linked
lists in tcl; I did for a parser generator I wrote in tcl.
It's somewhat painful. Similarly for most other things.
You can also have things like structures, again with a bit
of work.
3) Tcl lacks adequate namespace organization. You can solve
this problem in the same way that you do with C. It's
mostly a matter of discipline. But it would be better if
the language helped.
4) Current *implementations* of tcl seem slower than awk for
similar tasks. That is a subjective evaluation, not
verified by timings; but even if tcl is only approximately
as slow as awk, that's pretty bad!
(NB: there are counterarguments to all of these: if it isn't
semantically transparent, rewrite it; use [incr tcl] or other
derived languages; rewrite the bottlenecks in C. That those exist
is why tcl is useful to me. But the less such are needed, the
better.)
There's another aspect of rms' comments that deserves criticism.
That is that he's comparing apples and oranges. Not tcl and some
other language, but tcl and vaporware. Yes, an exhortation to a
better language is appropriate. But that's a different issue than
the choice among existing languages.
The question is not whether one should use tcl or not. It is: I
have a task, what language will get it done for me? No vaporware
will do. So, the comparison, *now*, shouldn't be between tcl and
vapor, but between tcl and, perl, Python, or any other existing
and supported language.
Rms conflated two different issues in his message: "is there,
potentially, a better way than tcl" and "should you use tcl"?
They're distinct. I *do not* appreciate having the terms of the
discussion rest on fallacious comparisons, and as you note, rms is
bright enough to know better.
So, is there a better way? Of course. Should you use it? Depends
on the circumstances. If it's today's need, you use what is
available today. If your need is for next year, you might profit
from waiting to see if Gnu comes out with a better alternative.