Let me be specific.
: From: rms@gnu.ai.mit.edu (Richard Stallman)
: [Tcl] lacks arrays
Incorrect. Tcl has arrays, eg, set a($i) foo
Some people have noted that what might have been meant was that
arrays aren't first-class objects, and can't be returned,
assigned, and so on. But since the names of arrays *can* be
returned, assigned, and so on, this is hardly a show-stopping
problem. For example, very similar problems didn't stop C.
: [Tcl] lacks structures from which you can make linked lists
Incorrect. Linked lists can obviously be made from associative
arrays. Depending on other factors, the important semantics of lists
can easily be had in Tcl using either strings or arrays.
: [Tcl] fakes having numbers, which works, but has to be slow
Largely irrelevant. Tcl may be slow compared to other interpreters,
but it doesn't "have" to be, nor can its slowness be pinned on its
lack of "real" numbers. For example, I have an interpreter in which
numbers are always represented as character strings, and on every
arithmetic operation, they are converted to and from string
representation. Yet this interpreter is three times faster than the
elisp interpreter (which I believe has "real" numbers), on my local
machine, using the code
(defun fib (n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2)))))
vs
define'fib with'n arg'1 if < val'n'2 val'n + fib - val'n'1 fib - val'n'2
Of course, the objection may be made that the code isn't really
arithmetic intensive, and that the speed is largely dominated by
stack frame push/pop. Which is true, but then, that is my point:
programming in extension languages very rarely runs into an
arithmetic speed problem.
: Tcl is ok for writing small programs, but when you push it beyond
: that, it becomes insufficient
Very subjective. Tcl has procedures with lexically scoped
variables. The [incr tcl] package adds objects and private storage.
TclX adds myriads of primitives, and keyed lookup of named fields in
smallish datasets. To me, the only reason Tcl might become
"insufficient" at large sizes is for programmers to avoid exploiting
these features, or for programmers to avoid designing their use of
the global namespace. Elisp or scheme programmers would have
similar problems if they decided not to use the package facility for
some reason, and allocated names randomly.
: Tcl has a peculiar syntax that appeals to hackers because of its
: simplicity. But Tcl syntax seems strange to most users
It would be nice to have some documentation of this allegation.
Certainly, I don't see anything drastic wrong with typical tcl
usages, such as
text .text -height 40
or even
.text insert insert [exec sh -c $filterprog [selection get]]
(which runs the current X selection through a program and inserts
the resulting text at the insertion cursor in the .text widget.)
But perhaps arithmetic notation is again the problem here.
Yes, things like
set r [expr $a*$x*$x + $b*$x + $c]
can be confusing. But it is absolutely *trivial* to provide
special purpose syntaxes in Tcl, eg:
sete r a*x*x + b*x + c
is prototyped in a handful of Tcl
proc e {args} {regsub -all {[A-Za-z]+} $args {$&} args
regsub -all {([0-9\.])\$} $args {\1} args
regsub -all {\$([a-z]+\()} $args {\1} args
uplevel [list expr $args]}
proc sete {name args} {set $name [e $args]}
and could easily be added to the core interpreter.
Of course, the argument can be made that this is hacker-level usage,
and that most folks wouldn't be comfortable with this sort of thing.
True enough. But if somebody would document that the above problem
is worth addressing (that is, that using a general-purpose string
substitution syntax obscuring the arithmetic expression syntax), Tcl
could respond trivially and efficiently, because its syntax is
minimally intrusive.
So again, at best subjective, and not well documented.
: If Tcl does become the "standard scripting language", users will curse
: it for years--the way people curse Fortran, MSDOS, Unix shell syntax,
: and other de facto standards they feel stuck with.
This is vacuous, because it is true no matter what replaces "Tcl" in
the above sentence. The perennial Rubin flames are a case in point.
Tcl, on the other hand, because of its lexical conservatism, can
accomodate more differing tastes, and incorporate novel notational
solutions more easily than many alternatives. And thus I would
argue, would be *less* cursed than many alternatives.
: For these reasons, the GNU project is not going to use Tcl in GNU
: software. Instead we want to provide two languages, similar in
: semantics but with different syntaxes. One will be Lisp-like, and one
: will have a more traditional algebraic syntax.
Oh, joy. Oh, rapture. Yet Another Couple of Scripting Languages.
But two points may be worth making here. First, it isn't clear that
segregation is the right way to go. That is, the above is
essentially the argument that Tcl tried to provide both "lisp-like"
regularity and "traditional algebra" (in "expr"s), and it is better
to supply these things separately (but presumably equally) than in
an integrated fashion. I am not convinced. The first thing that's
going to happen is that an application scripted with the lisp-like
language is going to want to import scripts written for an
application scripted with the traditional algebraic language.
Second, "lisp-like" and "algebraic" (or perhaps "prefix" and
"infix") doesn't cover all the ground that Tcl attempts to cover.
In particular, it would be easy, in the rush to provide "useful data
types such as structures and arrays" in both prefix and infix forms,
to forget to provide a simple, clean, "unquoted" syntax to be used
to enter commands interactively. Sure, sure, GUI, WIMP, and other
gestural interfaces make a type-able syntax a bit less important
than it used to be. But not *un*important.
In conclusion, let me ask a question. Analogs of *all* of the
criticisms that have been brought to bear against Tcl here can also be
brought to bear against C and Unix. C lacks first-class arrays. C
lacks a true two-dimensional or better namespace. Unix system calls are
minimal and regular, but only hackers like them, and all the
higher-level conventions to do with sockets and pseudoterminals and so
on are incomprehensible to the casual user. And even hackers are
abandoning Unix to pursue alternatives, because it's getting so old.
So. Given this, why did the GNU project decide to saddle the software
using community with a Unix-like OS and the GNU C compiler, which many
people even now curse as a de-facto standard that they are stuck with,
and yet has decided to saddle up a quite different beast, and *avoid*
the defacto standard of Tcl? The most likely reason might be that Tcl is
a less entrenched evil than Unix/C, and can be nipped in the bud. If
that's the rationale, Tcl strikes me as neither evil enough nor bud
enough to be a good candidate for nipping. There are other jihads more
fruitful to pursue than one against Tcl.
--
Wayne Throop throopw%sheol.uucp@dg-rtp.dg.com
throop@aur.alcatel.com