Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Goodbye TCL

Reply
Thread Tools

Goodbye TCL

 
 
Ed Suominen
Guest
Posts: n/a
 
      04-15-2004
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
 
Reply With Quote
 
 
 
 
Stephen Huntley
Guest
Posts: n/a
 
      04-15-2004
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
 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      04-15-2004

"Stephen Huntley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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



 
Reply With Quote
 
Phil Dietz
Guest
Posts: n/a
 
      04-16-2004
Forget OO...
TCL still doesn't have a standard database API in the core yet....
 
Reply With Quote
 
David N. Welton
Guest
Posts: n/a
 
      04-16-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Phil Dietz) writes:

> Forget OO... TCL still doesn't have a standard database API in the
> core yet....


That could go in this lib too. nstcl and DIO are probably the
contenders here.

--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
 
Reply With Quote
 
Stephen Huntley
Guest
Posts: n/a
 
      04-16-2004
"John Roth" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> "Stephen Huntley" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
> > 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


I'm certain that Python is a lovely language with many uses. You're
right saying that since 1994 many new technologies have just worked
out of the box. The gotcha I have encountered is the problems you run
into a year or so down the line, when you want to move to a new
platform, or use an exotic character encoding, or scale up by an order
of magnitude. This is where Tcl has shined for me.

I would be curious to know what is the biggest-capacity Python network
application in use? How does it scale in comparison with AOLServer?
Any ideas?
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      04-16-2004
In article <(E-Mail Removed) >,
(E-Mail Removed) (Stephen Huntley) wrote:

> I would be curious to know what is the biggest-capacity Python network
> application in use? How does it scale in comparison with AOLServer?
> Any ideas?


How about the one you're using to post your articles -- Google.
 
Reply With Quote
 
Skip Montanaro
Guest
Posts: n/a
 
      04-16-2004

Stephen> I would be curious to know what is the biggest-capacity Python
Stephen> network application in use? How does it scale in comparison
Stephen> with AOLServer? Any ideas?

Off the top of my head I have no concrete examples, but you might want to
skim these pages:

http://www.twistedmatrix.com/services/success
http://pythonology.org/success
http://www.python-in-business.org/success/
http://www.python.org/Quotes.html
http://www.zope.org/Resources/ZopePowered/

I believe people find solutions using the twisted framework scale very well.

There's obviously some significant overlap between those pages (Google, ILM
and NASA pop up multiple times), and clearly not all of them are using
Python to develop large-scale websites but there are lots of interesting
entries in a number of fields.

the-whole-world-isn't-yet-a-website-ly, y'rs,

Skip

 
Reply With Quote
 
Cameron Laird
Guest
Posts: n/a
 
      04-16-2004
In article <(E-Mail Removed) >,
Phil Dietz <(E-Mail Removed)> wrote:
>Forget OO...
>TCL still doesn't have a standard database API in the core yet....


Was this intended as a contrast with Python?

'Different way to say this: "database", in this sense,
is a dirty subject, in that it's far more tied to grungy
details of specific implementations than the masses
generally realize, or than either Python or Tcl, both of
which prize purity in their own ways, generally support.
A general database abstraction is about as rarefied as a
general GUI abstraction.
--

Cameron Laird <(E-Mail Removed)>
Business: http://www.Phaseit.net
 
Reply With Quote
 
ulis
Guest
Posts: n/a
 
      04-17-2004
Just to add one.

ulis
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to build a loadable tcl dll with visual studio (microsoft C compiler)?[crosspost in comp.lang.tcl and comp.lang.c++] Michael Reichenbach C++ 5 02-08-2010 02:38 PM
Goodbye "Goodbye Ruby" Robert Schaaf Ruby 7 04-18-2009 09:37 PM
Inline::Tcl vs. Inline::Tcl Mumia W. Perl Misc 0 08-23-2006 04:09 PM
Goodbye Mozilla Joe S. Firefox 11 01-31-2005 11:08 AM
goodbye Wapi choo MCSE 4 12-20-2003 01:25 AM



Advertisments