Re: What are the relative advantages of Python and Tcl?

Ty Sarna (tsarna@endicor.com)
Tue, 12 Apr 1994 05:57:31 GMT

In article <GARNAAT.94Apr11094748@cacao.wrc.xerox.com> garnaat@cacao.wrc.xerox.com (mitch garnaat cacao garnaat@wbst128) writes:
> In comparison, tcl has such a paucity of language features that
> you have to resort to inventing your own syntax. That probably
> sounds rather imflammatory, but it really isn't intended to be.

The syntax I need to invent in these cases doesn't exist in any of the
various languages -- their specialized syntaxes (syntaces? syntaxen?)
for particular applications. I'm talking about things like mailer
ruletables (would you really want to write these as gynormous gobs of
'if' statements?), sub-languages (sub-embedding interpreters or compilers
for special virtual/real/state machines, etc). This is stuff you pretty
much _have to_ invent syntax for to make working with the tool
comfortable, and you can either invent your own limited language (as
sendmail does, as assemblers do, etc), or you can take an extensible
language and add your syntax to it, producing a tool that's much more
flexible. Neither Python nor Perl would be suitable choices for this
kind of thing.

To look at it another way, Perl provides syntax to make dealing with
strings and files easier. Python presents syntax to make dealing with
various other complex data structures easier, and Tcl has almost no
syntax of its own, but allows you to add syntax to support data
structures that the other two languages can't manipulate easily. It
happens that you have one set of syntax needs which Python supports. On
the other hand, I may have syntax neds which it doesn't, and which in
fact no ready-made language supports, so Tcl is attractive as a language
which allows me to add support for my peculiar syntax needs. Tcl is
designed around the concept off extending syntax -- most of Tcl is
actually implemented as extensions to itself. Tcl has no intrinsic
flow-control structures and such. Instead these things are implemented
as add-ons that just happen to be availible almost all of the time.
This is similar to the way that C provides no intrisic I/O support, but
instead gives it to you as an add-on library that's almost always
availible. In both cases you can ditch the standard add-on stuff if you
don't happen to need it for your specific use.

> Tcl is fine as a shell-like language, but python provides so
> much more as a language (real types for a start) that its difficult
> to compare them.

This is my point. They are different, and each have their uses. For
the kinds of things I use Tcl for, I *want* a shell-like language (and
not just any shell-like language). For other tasks, I might want a more
general purpose language (so I might use Python), or I might want to do
some heavy string gymnastics, so I would use Perl, which provides
special syntactic support for such things. I'm just trying to point out
that Tcl DOES have a reason to exist, and that neither Python nor Perl
are quite direct competitors with it or with each other, though there
are many tasks for which their uses overlap. The original assertion was
that Tk was Tcl's only useful feature; I'm trying to prove that's false.
I wouldn't want to write everything in Tcl, but then I wouldn't want to
have to choose any one language to write everything in.

-- 
Ty Sarna                 "As you know, Joel, children have always looked
tsarna@endicor.com        up to cowboys as role models. And vice versa."