Why is tcl broken?

[Paul Duffin]

Tom Cloney wrote:
> 
> >   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.
> 

Actually since version 8.0 Tcl has scaled quite nicely thank you, 8.1 has
reduced the scalability of string operations due to a naive implementation
of Unicode / UTF8 support but that will be fixed soon.

> 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.
> 

Tcl can be used to crunch stuff but you just have to be very careful how
you go about doing it. I have written a Tcl program to analyse the whole
Tcl source which is nearly 5MB and it did it very fast indeed.

> 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

Tcl 8.1 now has the same (bar a few weird hacks) regular expression package
that Perl has.

> 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

OOP support doesn't imply scalabity does it ?

> 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.
> 

It sounds as though you are being a bit unfair with Tcl. You seem to invest
an awful lot of brainpower in Perl (not to deal with the problem but to
deal with the language) but you don't spend any on Tcl because it is so
simple. If you invested as much time learning how to program efficiently
in Tcl as you do in Perl you would soon be able to match performance.

> 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.
> 


-- 
Paul Duffin
DT/6000 Development	Email: pduffin at hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880