Goodbye TCL

[Stephen Huntley]

Ed:

I think your post is valuable.  Instead of trying to invalidate your
arguments, I will outline my reasons why I stick to Tcl.  Then we can
perhaps glimpse how strengths and weaknesses counterbalance.

The main reasons I stick with Tcl are:

1. Rock-solid stability.  I'm too old to spare time wondering if
frequent crashes in my software are my fault or the underlying
technology's fault.  Tcl largely removes this consideration from the
equation.  America Online's web server is written in Tcl.  It is
highly unlikely I will ever need to scale a product of mine to that
level, so there's a lot of headroom for me.

I have occasionally looked into new technologies, like Python, PHP,
Ruby, etc; but I've noticed that if you look beyond the FAQ's deep
into the developer mailing lists, you'll generally find statements
like: 'development of the core is going really really well, and within
the next few releases we actually expect it to be stable!'  Hold me.

I frequently use Tcl to write wrappers for other products to catch and
compensate for their shortcomings.  This would be pointless if it
weren't for the fact that Tcl is at least an order of magnitude more
stable and reliable than any other technology I've tried.

2. Freedom from bugs.  For years after college I did almost no coding
because I was sick of the fact that I would have to rewrite literally
everything I wrote two or three times to find a syntactically correct
version that didn't hit a deadly bug.  Imagine my surprise when my
first Tcl scripts Just Worked.  And the docs were accurate and
complete too, so I didn't have to spend half my time
reverse-engineering (another new experience).  For this reason alone
Tcl is almost single-handedly responsible for the fact that I am still
working in the computer world.

In ten years of Tcl scripting, I think I've encountered three bugs in
the core.  I found upon reporting that each one was already fixed in
the latest version.  I just don't bother to upgrade my core very often
because of 1. and 2.

3. Platform agnosticism.  Since Tcl was originally designed to be
embedded it play no favorites in terms of platform features.  It's
available on a wide variety of platforms and I suspect will be there
on the platforms of the future in equally reliable forms.  I started
with computers on Unix as a student, as a professional worked first
with Macintosh v 7, then on to Windows, and now a bit of everything
(five *nix versions, four Win*s and handheld devices).  AS/400 was in
there somewhere.  Tcl has been there every step of the way.  I'm too
old to relearn my chops every time a new OS fad blows through, and I
don't want to have to predict winners and losers.  I feel Tcl
minimizes the likelihood I will have to.

Here at work I suggested we use a free Tcl installer program rather
than a for-pay Java one.  Management chose the Java option.  Why? 
Because the Java company officially supported all the platforms we
needed to be on, and management felt they couldn't take the risk of
going without assurances.  It's turned out that the installer has
required special handling or patches for every OS (and almost every OS
version) we've tried it on, resulting in numerous gotchas and
release-note warnings for our customers.  And "official support" is a
bulletin board where their engineers' response is always "we're
working on it."  Meanwhile my build and test scripts run merrily and
without alteration everywhere.

Alternative technologies tend nakedly to favor *nix, and seem only to
offer a subset of function on other OS's grudgingly.  Python and
similar technologies treat platform-specific issues like pathnames and
line terminators as special cases with their own commands or
compensating strategies to handle them.  Tcl largely handles them
tranparently.  It was years before I was even aware of some of these
issues because Tcl handled them so well.  Python uses ASCII as a
default string encoding, but recently managed to bolt on a Unicode
library (same with PHP I think).  I haven't looked into its Shift-JIS
suppport, which I need for work (and is included with Tcl).

4. Tk.  Other technologies say 'We don't have a native GUI interface,
but there's a binding to the Tk library.'  For all intents and
purposes, Tk is the only game in town for cross-platform GUI
scripting.  When I'm using Tcl I know I have access to 100% of Tk's
features and the latest Tk version.  Is that true with other
languages' bindings?  I don't know, but if I had to bet money I'd say
no.

Tk follow's Tcl's logic, and it's a lot easier to program Tk
interfaces when in the Tcl mindset then try to access Tk's features by
switching gears from another language's mindset.  I don't do GUI
programming very often, but when I have to, it's nice to know that I
can do it as a trivial extension of my existing Tcl skills.

Ed, your voice-recognition project looks very interesting, and I look
forward to using it when it's ready for prime time.  I spend 90% of my
time in front of a Windows computer (my boss's choice, not mine): how
does it run on Windows?  How stable is it?  How does Twisted's event
architecture compare to Tcl's?


Steve Huntley