Why you should not use Tcl
                        Richard Stallman, GNU Project

As interest builds in extensible application programs and tools, and
some programmers are tempted to use Tcl, we should not forget the
lessons learned from the first widely used extensible text
editor--Emacs.

The principal lesson of Emacs is that a language for extensions should
not be a mere "extension language".  It should be a real programming
language, designed for writing and maintaining substantial programs.
Because people will want to do that!

Extensions are often large, complex programs in their own right, and
the people who write them deserve the same facilities that other
programmers rely on.

The first Emacs used a string-processing language, TECO, which was
inadequate.  We made it serve, but it kept getting in our way.  It
made maintenance harder, and it made extensions harder to write.
Later Emacs implementations have used more powerful languages because
implementors learned from the problems of the first one.

Another lesson from Emacs is that the way to make sure an extension
facility is really flexible is to use it to write a large portion of
the ordinary released system.  If you try to do that with Tcl, you
will encounter its limitations.

Tcl was not designed to be a serious programming language.  It was
designed to be a "scripting language", on the assumption that a
"scripting language" need not try to be a real programming language.
So Tcl doesn't have the capabilities of one.  It lacks arrays; it
lacks structures from which you can make linked lists.  It fakes
having numbers, which works, but has to be slow.  Tcl is ok for
writing small programs, but when you push it beyond that, it becomes
insufficient.

Tcl has a peculiar syntax that appeals to hackers because of its
simplicity.  But Tcl syntax seems strange to most users.  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.

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.  Both will provide
useful data types such as structures and arrays.  The former will
provide a simple syntax that hackers like; the latter will offer
non-hackers a syntax that they are more comfortable with.

I cannot agree with this.  o you have any evidence to support such a
sweeping statement? I, for one, find Tcl's syntax a good deal more
readable than any Lisp variant.

Tcl also wasn't designed to be used in a vacuum, but to be embedded
into a larger application. The ease with which this can be done is its
primary strength. If the language lacks features you desire, add them.
This, too, is relatively easy to do.

1) Tcl was not designed to be a serious programming language.

2) Tcl lacks arrays.

3) Tcl lacks structures from which you can make linked lists.

4) Tcl is inherently slow.

5) End-users do not like Tcl syntax.

I would point out:

1) I can find no documentation that Tcl was not designed to be suitable
for serious programs.  It is clearly based on LISP, which has been
widely used in the AI community among others for very serious programming.

2) Tcl has content addressable arrays, which are a superset of ordinary
arrays in functionality.

3) Tcl has no pointers, and shares this property with most LISP like
languages.  Deeply nested list structures can be created, though, which
provide much of the functionality of linked lists.

4) It remains to be seen whether performance improvements are possible
to Tcl.  There has been discussion on comp.lang.tcl on compilers.  On-
the-fly compilation would combine interactivity with performance.  Other
optimizations such as speedups for arrays whose index elements are
numbers should be possible.

5) I agree that LISP-like languages can be hard for amateurs to use.
It should be possible to make Tcl more usable by, for instance, creating
easier-to-use control structures.  Stallman's idea for two compatible
languages with different syntax is perhaps worth looking at, but frankly
I suspect that programming is an inherently difficult process and it
will be hard to dumb it down much and still retain the needed power.

One other point - Stallman mentions TECO as a language with limitations
similar to those he sees in Tcl.  I did considerable programming in
TECO back in the early days and IMO Tcl has practically nothing in
common with it.  Tcl is far more similar to the LISP variant used in
present-day Emacs and again IMO is considerably more readable.  The
shareware text editor Alpha for the Macintosh is Emacs-like, uses Tcl
in place of Emacs LISP, and the performance is fine.

There is plenty of evidence, in the form of the many posts to
comp.lang.tcl that express confusion about Tcl syntax.  Lately the
posts seem to be concentrating on unmatched braces in comments, but ""
vs {} quoting is also a favorite.

Tom

It's clear from Ousterhout's original Usenix paper that tcl was intended
to be used as a lightweight extension language, not a large scale
implementation language.

   2) Tcl has content addressable arrays, which are a superset of ordinary
   arrays in functionality.

They are not first class objects: you can't assign one to another, pass
or return them from functions.  Contorted "call by name" semantics are
the only workaround.

   3) Tcl has no pointers, and shares this property with most LISP like
   languages.  Deeply nested list structures can be created, though, which
   provide much of the functionality of linked lists.

|   Mr. Stallman, though I am but an occasional user of tcl, I am
|   sufficiently familiar with it to know that you don't know enough about
|   it to have an informed opinion.  Rather than embroiling myself in the
|   flamewar that your specious claims are sure to cause, I'll just observe
|   that that sort of politicking is utterly contemptible.

I found the above utterly contemptible.  let the first man with a gas can
and a lighter be responsible for the flame war, not he who states his
opinions, however unpopular.

Tsk. You of all people should know that I don't care about popularity....

Mr. Stallman said baldly that "[tcl] lacks arrays". That is either a
demonstration of Mr. Stallman's ignorance or it is an outright lie. Either
way, that *alone* is sufficient to disqualify Mr. Stallman from having a
valuable opinion on the subject. That *alone* removes his politicking from
the reasonable to the contemptible.  Never mind any of the other drivel!

|   Mr. Stallman, though I am but an occasional user of tcl, I am
|   sufficiently familiar with it to know that you don't know enough about
|   it to have an informed opinion.  Rather than embroiling myself in the
|   flamewar that your specious claims are sure to cause, I'll just observe
|   that that sort of politicking is utterly contemptible.

[Erik Naggum]

|   I found the above utterly contemptible.  let the first man with a gas
|   can and a lighter be responsible for the flame war, not he who states
|   his opinions, however unpopular.

[Jim Wise]

|   Actually, Mr. Wells was responding to an obvious and offensive FUD
|   attack on a language which many people, myself included, are quite
|   happy and impressed with.  While I greatly respect RMS and his body of
|   work, his attack is spurred by so little understanding of, or even
|   relevance to the intended uses and strengths of Tcl that it makes me
|   wonder what his motives are.

whatever one may think about RMS, his work or his motives, Tcl or anything
else, it was T. William Wells' attitude that I was addressing.  if the
statement of his opinions can cause only flames (at least in his opinion),
it is _he_ is who is starting the flame wars that he so despises.  this is
his problem, not RMS's, and nobody else's.  I find it utterly contemptible
to attempt to transfer the guilt of such irrational behavior to others, no
matter _what_ one thinks of the subject matter or _how_ one defends one's
views.  this is definitely politicking.  if one thinks certain kinds of
actions contemptible and engages in them at the first opportunity, who is
contemptible?

it should be possible to discuss the merits and demerits of RMS's statement
on Tcl without resorting to such flames.  if he is so obviously wrong as is
implied, this can be pointed out.  if RMS has strong influence on what
others may think, it is counter-productive, if one wishes to reduce this
influence, to behave irrationally.  this only tells bystanders that it is
his critics who must have less than pure motives.  this can actually cause
by-standers to believe what RMS is saying, _unchallenged_.

RMS's statement may be read as a slam on Tcl in favor of yet-undelivered
tools from the GNU project.  we may note that dejagnu uses Tcl at present,
and we may assume that some lessons were drawn from this.  RMS's statement
may also be read as urging people to consider alternatives because of some
things that RMS thinks are bad, and for which he gives a varying degree of
good arguments.  we may note that people are doing this all the time, and
apply the necessary precautions when reading such notices, instead of
imputing evil motives and ranting and raving in openly hostile articles
completely devoid of technical content, the very definition of "flaming".

I now know that Tcl has some sort of arrays, and that there are ways to do
what one wants in the context for which it was designed, and that people
are doing this.  this enables me to judge Tcl and RMS's opinions on it in a
technical context.  if I wish to know more, I know whom to ask.  I also
know that some individuals have given unsupported ad hominem attacks on RMS
in place of something that I could use to form my own opinions.  this only
gives me information to judge those who engage in such attacks, should I so
desire.  I am more interested in extension and scripting languages to want
to waste more of my time than to point these things out.  T. William Wells
is encouraged not to respond unless he can tone down his replies a bit.

        Of course, the final list that gets stuck on the end happens
in O(1) time; it's just all the other ones that don't...

        I could be wrong, though, or have misunderstood.  Please feel
free to correct me if so.

the obvious question is: why bother? we know RMS will not
change his mind. for gnu, his opinion is the one that
matters. done.

Take your flaming elsewhere, Naggum. They, and your paranoid ravings, are not
appropriate to this newsgroup.

I will repeat what I told you in e-mail, which you promptly ignored: I do not
want further e-mail from you, and I have, as I told you, filed that unwanted
e-mail unread. *Do not send more e-mail*.

    We use Tcl/Tk for nearly the entire GUI in one of our major turnkey
    projects, about 400 K of Tcl/Tk code.

    I have found Tcl/Tk to be excellent for smallish self contained programs.
    The GUI code I've written is comprised of approximately 14 relatively
    independant programs and a small set of common library routines and
    C programs for low level database access.

    However, the largest of these GUI elements rapidly bogged down in several
    areas as it was being coded.  The primary problem was with the lack of
    structure in the language and variable syntax.  It required very HEAVY
    commenting to keep things straight as event oriented procedures forced
    us collect variable sets in global associative arrays, which greatly
    complicated operation.  The language structure also has a lot of problems,
    especially with variable substitution and programmatic structures such
    as switch statements and loops.  These problems can be ignored for
    small (1000 line or less) programs but rapidly cause confusion in larger
    programs.

    I would have to agree that as a programming language, Tcl sucks rocks
    when it comes to largish projects.  It is an excellent tool for smaller
    projects (expect scripts, less complex Tk/Gui stuff) but Tcl is not
    something I would want to inflict on somebody as a standard.

    I also have to say that, personally, I think anything lisp-like is even
    worse, so this response should not be interpreted as being particularly
    for GNUs intentions.  Perl comes closest to what I believe GNU wants
    but so far nothing fits the bill exactly, and I do not particularly
    like Perl's variable syntax either (though it's better then TCL's).

:Some people plan to use Tcl because they want to use Tk.  Thankfully,
:it is possible to use Tk without Tcl.  A Scheme interpreter called STk
:is already available.  Please, if you want to use Tk, use it with STk,
:not with Tcl.  One place to get STk is from
:ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z

    Heh, you convinced me to try it. :-)

                                                -Matt

--

   1) Tcl was not designed to be a serious programming language.

   3) Tcl lacks structures from which you can make linked lists.

   4) Tcl is inherently slow.

   I would point out:

   1) I can find no documentation that Tcl was not designed to be suitable
   for serious programs.  It is clearly based on LISP, which has been
   widely used in the AI community among others for very serious programming.

I keep on hearing this, so it must be true (;-)). But in what way is Tcl
similar to Lisp ? I see no direct relation to the lambda-calculus for
instance. It is true that Lisps, especially those with dynamic scope, are
not a pure implementation of the lambda-calculus, but they do not stray
all that far from it.

   3) Tcl has no pointers, and shares this property with most LISP like
   languages.  Deeply nested list structures can be created, though, which
   provide much of the functionality of linked lists.

But Lisp allows sharing of data-structures, which provides a safe access
to most of the pointer functionality. How can you do that with strings ?

   4) It remains to be seen whether performance improvements are possible
   to Tcl.  There has been discussion on comp.lang.tcl on compilers.  On-
   the-fly compilation would combine interactivity with performance.  Other
   optimizations such as speedups for arrays whose index elements are
   numbers should be possible.

Basing a language on string-substitution is obviously not the best way
to get high-performance. Sufficiently clever analysis and/or string
implementation may allow most substitutions to be avoided, but why
does all this have to be necessary ? While the Tcl compiler is busy
trying to work out the program's control structure, the Lisp compiler
is already at work attempting to discover the types of its variables :-)

|>
|> 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.  Both will provide
|> useful data types such as structures and arrays.  The former will
|> provide a simple syntax that hackers like; the latter will offer
|> non-hackers a syntax that they are more comfortable with.
|>
|>

1. Under what licence terms will these GNU languages be distributed?  If
it is the usual GNU licence then this will prohibit commerical use or
involvement in their development --- this has been a very significant
factor in Tcl/tk (one only has to look at the people who have contributed
to the tcl/tk archive).  Furthermore, users can expect to meet the GNU
scripting language only on net-distriubuted software.  One of the major
attractions of working with tcl/tk even in an academic environment is that
future commercial products may well include tcl and or tcl/tk and therefore
our home-written applications will mesh well with commercial applications.

2. Tcl/tk are available now, relatively bug free, well supported and are
in extensive use simply because they do the job for which they are intended
really rather well.  Undoubtedly they can be improved upon, but arguing they
should NOT be used because at some time in the unstated future GNU will
provide (in their opinion and maybe in most peoples?) better tools seems
a poor argument indeed.  While I think the GNU project provides excellent
tools, their ability to deliver service of course depends on the good will
of individuals which sometimes means exceptionally long lead times into
projects (g77 is one such example).  In this respect the commercial input
to tcl and the focussed effort of the tcl community has led to excellent
"support", again a major factor in the popularity of tcl/tk.

3. What is a "large" project?  I have now written about 20000 lines of
tcl used as complete X applications, embedded scripting language in our
own F77/C image processing and data processing codes.  I have found managing
this size of project relatively easy and overall time to produce the finished
"products" significantly reduced over using C or F77 to accomplish the same
tasks.  While this may not be a "large" project it is not insignificant and
is well within the scope of tcl/tk.

4. The quality of documentation of tcl/tk is of an exceptionally high standard,
far superior to any other free (and most commercial) products I have used.
For me this is significantly more important than whether tcl is syntactically
better/worse than XXX, or whether it is 50% 100% n00% slower/faster than XXX ---
the point is occasional users can write tcl/tk code if the have access to the
available documentation.

If you want to be relevant, you will have to come up with some concrete
proposal of how to leverage existing technology to come up with an
alternative to Tcl quickly. You have that technology already: elisp!

Why not build an "algebraic" Tcl-like dialect on top of elisp?
You would want a "quote-by-default" semantics like Tcl that is optimized
for one-liners and trivial programs. But you would be able to call upon
the full generality of Lisp when needed.

Another view of the same idea: turn emacs into a windowing shell.
The primitives are for widgets instead of text editing.

Whether you have to put a "$" in front of variable names, use prefix
rather than infix syntax for addition, or put parens before rather
than after the function name really makes very little difference in
practice.

But Perl and Tcl do have serious syntax-related problems in the areas
of syntactic overloading, error recovery, scoping, and quoting.

Lisp wins hands down in all these areas, having a few, simple rules.
The only problem with Lisp syntax is that it doesn't give new users
that "warm and fuzzy feeling" of familiarity.

I wholeheartedly agree. (See also:
        "Why Tcl Doesn't Scale"
        $Id: why-tcl-doesnt-scale.html,v 1.1 1994/06/20 16:47:53 connolly Exp $
        http://www.hal.com/users/connolly/drafts/why-tcl-doesnt-scale.html
)

But first, I think RMS's article fails to give credit where credit is
due. Tcl is a great contribution and serves many purposes. Dr. John
Osterhout has written some excellent code which helps a lot of folks
get a lot of stuff done. I fear that the lack of acknowledgement
in RMS's article will spawn a great volume of flames... let's hope
not.

Now that that's done with... what will GNU software use? Where can I
find more details?

For example, tcl/expect is used in DejaGnu, the regression testing
tools. Tcl seems well suited to this task. Certainly expect is the
best available tool of its kind. Is the plan to replace tcl with some
other scripting language in that toolset? That would seem to imply
that all the test suites would have to be revised. (Is dejagnu
considered GNU software, or is it like gnuplot in that it just uses
the GNU name?)

I gather that scheme is a contender. I like schemes formal grounding,
but scheme standards (R^4RS etc.) leave a lot of parts of a software
development platform unspecified. As a result, scheme code tends to
not be portable between implementations. Unlike large bodies of
common lisp code, large bodies of scheme code tend to need "tweaking"
and "porting" to run on various scheme implementations.
        * I'm not advocating common lisp.
        ** I don't have a lot of experience developing in scheme --
           I've just looked at lots of net distributions.

Have folks looked at Scheme48? See:
        "Scheme 48 home page"
        http://www-swiss.ai.mit.edu/~jar/s48.html

Has python been considered? I like the language, though the
implementation has some limitations. (for details, see
comp.lang.python or
        http://www.cwi.nl/ftp/python/index.html
)

Here are some of the issues I find important in a modern programming
language, with a comparison of some of the options:

Threads: for interactive programs -- especially distributed applications
         which are now the rule more than the exception -- thread support
         in the language/runtime greatly simplifies development

Modules: or packages or whatever: some mechanism to help maintain
         the namespace is a must.

Continuations: the all-powerful construct from which anything can be
                derived. Makes foreign-function interfaces a mess, though.
                Perhaps continuations or even objects are enough...

Good FFI: Foreign Function Interface. A way to bind C functions.
          "Good" in the sense that lots of folks have used it to
          build useful applications.

Exceptions: You can't rely on a style of checking return codes for
            building large, reliable programs.

RPC Support: Support for making calls across address spaces easily.

        Embedded Languages:
                Tcl     Scheme48        Python  Perl4   Obliq
Threads         ???(1)  YES             YES(2)  NO      YES
Modules         NO      YES             YES     YES     NO
Continuations   NO      YES             NO      NO      YES
Good FFI        YES     NO              YES     NO      YES
Exceptions      YES     YES             YES     YES     YES
RPC Support     YES     NO              YES(3)  NO      YES

(1) I think Tcl as a language is consistent with a multithreaded
    implementation, but I don't think the current implemention
    is thread-safe. Certainly there is no language support for threads.

(2) The python threads support is kinda funky and not too stable.

(3) Python includes support for automatic marshalling of basic types,
    plus socket support. It's not a complete RPC system, but it's close...

        "Systems programming" Languages:
                CommonLisp      C++     Modula-3
Threads         NO              NO      YES
Modules         YES             YES(4)  YES
Continuations   NO              NO      NO
Good FFI        ???(6)          YES     YES
Exceptions      YES             YES(5)  YES
RPC Support     NO              NO(7)   YES

(4) Using classes as namespaces is a messy hack.

(5) C++ exceptions are a messy hack.

(6) Various common lisp implementations probably have good FFI's.

(7) There are several C++ based RPC systems based on COBRA.

I also consider it important that the language lend itself to static
alalysis -- whether that means something like Modula-3's excellent
type system and strong static typing, or even scheme's formal
semantics and static scoping which make thinks like type inference and
program proving somewhat practical.

Static analysis enables things like code browsers and optimizing
compilers (or even source-to-source optimizers...). For an interesting
example, see the Modula-3 library source code at:

        http://www.research.digital.com/SRC/m3sources/html/INDEX.html

Mow imagine doing that with a body of C++ code -- if the C preprocessor
was used with great discipline, perhaps. But in real life...

Dan