Why is tcl broken?

[Tom Cloney]

>   I'm trying to collect a list of all the _current_ issues making tcl
> a bad language choice...

Well, the troll aside, I do have quite a lot of experience with Tcl. Among
other things, I've written a workflow system on the Macintosh for generating
technical book catalogs using a combination of a relational database (4th
Dimension), image processing applications (Photoshop, NIH Image), page
layout and database publishing software (FrameMaker MIF) and other apps. Tcl
was used extensively as glue for doing things like process control and
analyzing Encapsulated Postscript files. The Tcl I used is the one embedded
in Pete Keleher's Alpha text editor, which is a real joy to use. I wish we
had something like it on NT. I've also used standalone versions of Tcl with
and without Tk. I worked with it a lot from about 1992 - 1996, writing many
useful apps. I've kept an eye on the language since then, and while I'm no
longer very Tclish, I reckon my basic take is still valid.

My opinions are, of course, shaped by the way I work. I lean towards
practical applications that one person can write and maintain and still have
a life. Most of the time I find myself practicing the Mad Max
post-apocalyptic school of programming, that is, cobbling together
interesting artifacts that come my way from both commercial and
non-commercial sources. I'm lazy -- I try to write only what I have to, and
then I look for the easiest tools to use to do it. I'm a businessman, so I'm
always balancing cost, productivity, and performance. I'm also aware that an
attractive solution may carry many hidden costs. I'm not going to get into
much academic hair-splitting here. For my purposes I judge language
environments by how easy it is to get things done in them, not by whether
they have a recursively bi-directed optimizing monkee gland compiler. YMMV.

Since the late 60's I've done practical programming in over 60 languages,
from FORTRAN, TECO, and microcode to Java, Python, and *Lisp, with many fun
stops in between (pause for chest-thumping and vine-swinging ;>), which
either makes me experienced or a fossil, depending on your point of view.
That said, here's my take on Tcl.


What I like:

Very readable syntax. A great language for writing more or less
self-documenting "dumb" code that you can come back 6 months or a year later
and still understand and modify. This is hard to overemphasize: clever
things _will_ be forgotten!

It's super when embedded in a text editor. Alpha is a great example.

It's a very nice hackery language. You can just whack away at things until
they do what you want. You don't have to be feeling sharp and clever on days
when you use it.

The language itself is pretty stable, that is, it doesn't usually crash in
bad ways.

It's one of the better languages for text processing. Not as nice as Perl,
but pretty darn good. Good regexp support. Lots of easy and elegant string
munging built in.

Support for lists, while not deep, is elegant and simple as far as it goes.
I don't like it when languages make list operations a big cumbersome deal,
so I appreciate Tcl's elegance here.

Support for hash tables (associative arrays, whatever...) is also elegant.

These three things: clean support for lists, hash tables, and regular
expressions are enough in themselves to make a language attractive. They
just make life much easier for a practical programmer.

GUI support via Tk is nice. It's a bit ideosyncratic, but good for many
things. It's not shrinkwrap-quality stuff, but think of all the great
languages whose inexpensive implementations are crippled by having little,
if any, support for GUI (Perl until recently), produce GUIs that feel slow
and clunky (Java), or make it cumbersome (like the joys of COM/IDL).

Wiser folk than I have said a good language should make doing simple things
simple. Tcl succeeds in this.

Good support for file system ops.

Straightforward interfaces to C etc. are a good thing.

Intangible fun factor. Tcl puts you in a good mood. It's easy. You feel like
you're cheating. You concentrate on the problem domain. You still feel good
when you look at the code six months later.


Now the cold slimy part:

Tcl scales very badly. All the same things in Tcl that make simple things
simple make complex things hard. Tcl is broad and shallow (which is not
always a bad thing). List structure doesn't really scale. There is no OOP
support to speak of, and although various people have hacked quick and dirty
examples, it's not something you would really want to build on. The very
brainlessness of Tcl is part of its appeal, but this is part of the price.
This is a _procedural_ language, which is actually nice on days when you are
too fuzzed out to think like a computer professional. It's not CLOS or
Eiffel, folks. It's not even Java.

The cute hacks that make string munging kind of cool can also be confusing.
You tend to spend a fair amount of time (by Tcl standards) finding subtle
bugs in the way you expressed complex string concatenations and such. It's
not that the language is buggy in this regard. The rules are relatively
simple. But the subtleties are hard to keep in mind. Tcl makes string
processing so easy that you tend to quickly give yourself enough rope to
hang yourself with. Easy debugging takes some of the sting out.

Tcl is slow. Oh, I know that's relative. For many applications it will be
fine. But complex parsing on large amounts of text can really drag. In one
application I needed to parse FrameMaker MIF files. These are SGML-like
ASCII files that often stretch to 600k or more, and which give FrameMaker a
lot of its power as a database publishing platform. Tcl was dog-slow. Perl
was about an order of magnitude faster than Tcl. C++ using the STL was a bit
faster than Perl, but still distressingly slow. I ended up using "cheating
C++", which is C++ with a lot of C standard library calls in it. The C was
about another order of magnitude faster than Perl. Tcl is great for nabbing
some text out of a file and doing some clever things with it (like nipping
the image size data out of an EPS file), but a cruncher it's not.

Perl can be much better for industrial-strength text processing. Perl has
better regexp handling than Tcl, in fact it's usually held up as the
standard by which other regular expression packages are judged. Perl is much
faster than Tcl. Perl 5 has rudimentary OOP support, which is a lot better
than nothing and allows Perl to scale in ways Tcl can't. The comparisons
with Perl are important because Perl does a lot of the same things Tcl does
and more. For a long time the dilemma was that Perl was the better language,
but Tcl had a GUI. Now Perl has a Tk interface (I haven't used Tk from Perl,
so I can't vouch for its elegance). After a while, as I developed more
complex applications in the languages, I found myself abandoning Tcl in
favor of Perl because of the performance and scalability. Perl code lacks
the beautiful brainless stickiness of Tcl, though. Perl is a "clever"
language, with what many would describe as "line noise" syntax. Cleverness
is dreadful when you have to look at it six months later. Tcl is the glory
of "stupid" programming, which I lean towards whenever possible. But it will
drive you crazy the minute you need speed or want to encapsulate something.

Tcl, Perl, and Python all hold out the promise of transcending the speed
problem via extensions written in C or another compiler language. This is
fine as far as it goes, but in the real world it's often difficult to fully
encapsulate speed-critical bits in separate modules (this could be the topic
of a whole thread). It's also somewhat complicated. Tcl makes it as easy as
anybody, but by the time you are organizing your work to the point where
you're designing a full component architecture, you're probably going to
find yourself thinking about using high-level compiler languages that let
you keep it all under one roof.

Tk ports are slow to arrive on some platforms and are buggy for a while. It
took years for heroic volunteers to get a workable Tk on the Mac. I think
Tcl helped show the way, but many of its enthusiasts have drifted away as
more alternatives have become available.

If you want to grind text, why not use Perl? If you want a slow, essentially
free hacking language with all the features of Tcl and very good OOP
support, why not use Python? And if you want a faster "scripting" language
based on the "Boy in the Bubble"* architecture, with built-in GUI, much
wider support, and a religion, there's always the J-word.

* Baby with the baboon heart sold separately.

-Tom