Goodbye TCL

[John Roth]

"Stephen Huntley" <blacksqr at usa.net> wrote in message
news:f82c8ae7.0404151057.67333d4e at posting.google.com...
> 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:

What's amusing is that every one of your arguements in favor
of TCL are also arguements in favor of Python. This is, after
all, 2004, not 1994. Languages don't get widespread use
today unless either 1) some mega-mastodon is pushing them,
like Java or C#, or 2) they just work out of the box, and
solve real problems for the people using them.

John Roth

> 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