Goodbye TCL

[Ed Suominen]

I have debated about the wisdom of posting this message, knowing that a lot
of people whom I respect may not like what I have to say. On the other
hand, I wish that the person who told me "TCL is dead, try Python" two
weeks ago had somehow been able to get that message through to me much
earlier. As a longtime member of comp.lang.tcl who reluctantly considered
that advice but wound up finding its results incredibly illuminating and
productive, it seems only fair to pass it on.

I am dictating this posting into a Linux application window using speech
recognition software that is running under Windows in a VMware virtual
machine. Every time I dictate a bit of text into a Tk text widget on the
Windows side, that text is transmitted via a (virtual) TCP connection to a
daemon on the Linux side that generates fake keystrokes via X events. I
wrote the software that accomplishes this [1] over the course of the last
week or so, one week after beginning my study of object-oriented and
test-driven programming in general, more specifically of Python, and even
more specifically of the Twisted network application framework for Python
[2]. There was a lot of reading and head-scratching involved, but it was a
fascinating experience.

I have had extensive experience doing network application development with
TCL, most visibly with Privaria [3]. That experience involved a great deal
of low-level programming using the socket built-in function and its
companions. In both cases, I searched far and wide for suitable TCL
packages to do what I wanted but wound up just writing the stuff at a low
level because the packages seemed inactive, demonstrated buggy behavior, or
just didn't seem to do what I wanted. I spent many interesting but
frustrating hours sniffing packets and working out the details of TCP-level
communications -- buffer flushing, newline inconsistencies, blocking vs.
non-blocking reads, etc.

With this latest project, I was determined to see if Python was as widely
supported and powerful as its advocates claimed. I was not disappointed.
After quite a few hours of intense study (my first real exposure to
object-oriented programming, see above) I found the language itself
incredibly powerful, without the need for any external packages (which do
you choose, itcl, snit, or what?) to tack OOP capability onto a language
that is as procedural as the name of its function construct ("proc")
implies.

Namespaces in Python just happen; they don't need definition. If you
"import" a "module," all of its "attributes," which are classes, methods
(few), and variables (fewer) live in that module's name space unless you
indicate otherwise (which you can easily do). The number of globals
floating around is truly minimal, because defining classes that instantiate
objects making things happen in methods of objects is the default in the
way the language and its documentation (current and extensive) encourage
you to program.

But most significantly, I found, is that trying to reuse code that others
have written is no longer a frustrating exercise in skipping past "Error
404: Page Not Found" messages, pages that are found but haven't been
updated in three years and feature code that only links to tclsh8.1, and
packages that are TCL-only or manage to link but seem dangerously inactive,
buggy, and unused. For my first Python application (written just before the
one I'm using to dictate this) I needed to generate highly structured,
highly specialized HTML from various bits of data in text files here and
there. I found the HTML generation package in Python's standard library
(yes, there is one, is extensive, and it comes with the interpreter) to be
intuitive and powerful, in contrast to the tcllib tool that I wound up
having to extend with my own hacks on too many occasions. (There's a more
powerful TCL tool, but it doesn't seem to be active or widely used...)

For this dictation application, I used the twisted application framework,
which turns Python into an incredibly powerful networking and multitasking
machine. It was very difficult to learn because its documentation does not
keep up with its depth, and I wound up having to print and pore over a lot
of source files to understand how it works. But once I overcame that
learning curve I found that I could do amazing things with a few lines of
highly modular code. I never even got close to the TCP packets. I just
invoked a method of the "reactor" object that runs the whole show to listen
for TCP connections on one side and make connections on the other and
implemented various methods to send the data I needed. When new text
materializes in the text widget, a periodically-polled method senses it and
sends it to the other side. The other side tells its keystroke-typing
object about the new text and lets that object take care of calling its own
objects. All those objects' classes and method were unit tested
concurrently with their development, based on a testing framework someone
else wrote and is supporting. The whole things takes up about 800 lines of
code, including extensive "docstrings" (essentially
documentation-generating comments).

I'm not writing all of this to rub it in, to thumb my noses at those left
behind. But I think at some point people (like me, two weeks ago) should
question why their particular programming language, operating system kernel
(see, e.g., the Hurd), editor, etc. does not seem to be receiving as much
attention as they would like. Sure, such people can tout the benefits of
their particular choice and shake their heads in wonder at why others
haven't discovered it or have left it behind, but they might well take an
honest look at the question "why"? Perhaps there is a reason why Python has
several dozen books with recent publication dates and nothing new seems to
have been written about TCL for years. Perhaps there is a reason why the
comp.lang.python newsgroup has several times the volume of this one and the
typical Linux distribution has many times more Python-based applications
than TCL-based ones. The reason may be that many people are finding one
choice superior to the other.

Finally, let me add that some of my observations may be inaccurate. Any such
inaccuracies are unintentional and open to correction here. Hopefully this
lengthy message will be received in the constructive spirit in which it was
written.

Ed Suominen

[1] Very much in pre-release state, but available at
http://www.ossri.org/projects.php
[2] http://www.twistedmatrix.com/
[3] http://www.privaria.org