[ this is a repost of an attempt to send this yesterday --strick ]
-----BEGIN PGP SIGNED MESSAGE-----
> On gnu.announce of 9/23, he writes "Why you should not use Tcl".
> Instead, those wanting to use the Tk tools are commended to a
> Scheme interpreter with it called STk. Available from:
> ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
Below is the post from Rich Stallman "Why you should not use Tcl",
and the reply from Ousterhout, which is basically: Why you should
not listen to Stallman, in this case.
The mentions in the [fantastic] Cyphernomicon of TCL are probably due
to my crypto-prototyping project. I did not take the choice lightly
when I chose TCL as my "glue" in this project.
Two issues that may be interesting but had *little to do* with
my decision are (1) language support for big numbers and
(2) the TK toolkit (which happens to be in TCL).
The reason I chose TCL is that it is designed to work
above, underneath, and alongside of C code. TCL has two published
interfaces: one is the language and standard commands, and one
is a C API for use in combining the language with other C packages.
I think of TCL as more of a subroutine library than a language: in
the same way that (say) C++ string, file, and dictionary classes
can help you be more productive in writing C++ programs, a
"little language" interpreter can make you more productive in
many kinds of programs. Crypto prototyping systems is one of them.
I am not new to LISP or PERL or AWK or POSTSCRIPT or FORTH or SHELL or
BASIC or HYPERTALK or various other interpreted langauges. For many
differnt projects I would leave TCL for one of them. However when TCL
came along, I recognized it as being just the language I had wanted to
write myself for doing projects like my current one.
Which may say more about what kind of a computer scientist I am
that about what lanaguage is best for you in your situation.
I'll add that I have a version of my crypto toolkit that is a PERL
interpreter, and I've looked briefly at embedding it in PYTHON as
well. My problem now is that I need a chunk of time to port it all and
package it on sun4 (currently it's on sun3). My problem is not yet
that I need more languages to port to. But i'll be glad to have some
people help embed these things in all the popular interpreted languages
soon. It would be particularly nice to have some people versant with
Macs and PCs to package crypto components on those machines -- in
applescript or hypercard or visual basic or whatever would help people
write crypt code.
Below I repost the original articles by Stallman (the spiritual leader
of GNU) and Ousterhout (the author of TCL).
I'll also point out my greatest respect for both of them, and for
their respective projects. They've both made my job as a
practicing cypherpunk much easier.
Talk about prototyping environments, but please don't spam the list on
religious issues. PERL and PYTHON and SCHEME are all pretty good
little languages.
happy hacking,
strick
Cypherpunks write Code,
but when do they release it? :)
[ thanks to iansmith(a)cc.gatech.edu and boyz(a)hkn.eecs.berkeley.edu
for bringing these articles to my attention. ]
- ------- Forwarded Messages
Date: Fri, 23 Sep 94 19:14:52 -0400
From: rms(a)gnu.ai.mit.edu (Richard Stallman)
To: gnu(a)prep.ai.mit.edu
Subject: Why you should not use Tcl
Newsgroups: gnu.announce,gnu.utils.bug,gnu.misc.discuss,comp.lang.tcl,
comp.lang.scheme,comp.windows.x.apps,comp.unix.misc
Followup-To: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme
[Please redistribute wherever appropriate.]
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.
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
- ------- Message 2
From: ouster(a)tcl.eng.sun.com (John Ousterhout)
Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,
comp.unix.misc,comp.windows.x.apps
Date: 26 Sep 1994 18:13:27 GMT
Organization: Sun Microsystems, Inc.
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.
- ------- End of Forwarded Messages
-----BEGIN PGP SIGNATURE-----
Version: 2.4
iQBVAgUBLpMs6Qq3IMgMJUNlAQGl8gH/WxquXwsd7RbN/Pv8mLwajyZVIN1d53AX
TSEtB/grWxbTyUYgPnAu/mzEj33DFPkfttP4/jvdDZir/HsCOxBM5A==
=EZgM
-----END PGP SIGNATURE-----
