...
Tcl/Tk
Anthony Clark
Xavier Torres
That's what's being tested you mouth-breathing tard. Everyone understands it is the standard libraries at play.
Elijah Harris
It's a shit test.
Asher Russell
Propose a better one.
Wyatt Richardson
I don't know who this Richard Stallman guy is, but he doesn't like TCL.
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
Jackson Taylor
For good measure, here's the rebuttal by Tcl's creator, John Ousterhout.
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.
Lincoln Bell
That man is a liar and a charlatan.
ergoemacs.org
Ryan Torres
No mention so far of aolserver. sad.
Back in the day, this was the choice for very large sites. Remember this was in the time where pedestrians were using cgi scripts to power their webapps. Aolserver (naviserver) ran rings around it.
The benefits to having multi-threaded, tcl based scripting, with built-in DB connection pools was a killer combo.
Looks like they posted the code to github, but seems development has stopped.
Ian Ortiz
So many shit languages came from this kind of thinking, and it's why we're still stuck with the nightmare of shellscript today. Interesting to see that some people used to think this kind of half-assed language design was a good thing.
Adam Sanders
No, everyone either used Apache, ZEUS, or wrote it in C on IIS. aolserver was almost completely unused in '99 when it was open sourced and the oldest usage numbers I can find for after were in 2004 when it was on 7k sites vs 31M running apache.
panoptic.com