[aclug-L] Re: TCL vs PERL

[Tom Hull <thull@xxxxxxxxxxx>]

Jeff wrote:
> 
> On Fri, 23 Jun 2000, James G. wrote:
> 
> > If John would like a target to aim the flame throwers at, here
> > it is: http://dev.scriptics.com/advocacy/perl.html
> 
> I'm not sure whether to respond to this article or not, because
> it's not clear to me if the article is supposed to be taken
> seriously or not.

Well, it reads serious. Scriptics is a company set up to commercially
exploit TCL, and people do tend to get serious when money is concerned.
O'Reilly has a similar interest in Perl -- although O'Reilly is more
diversified.

One interesting thing about the article is how many of the talking
points are new to TCL 8.0/1. Part of this seems to be aimed at
consciously competing with Perl, but the Java experience also looms
large. (Ousterholt was as Sun when Java was unveiled as Sun's answer
to everything, so he had to pump out some spin to show how TCL helped
the Java strategy.)

There are similar articles in Perl camps, especially from Tom Christiansen:

  http://www.perl.com/pub/language/versus/

A big problem with all of these is that you tend to compare your latest/
greatest against the last version of the competitors' offering that you
bothered to sort of look at. (Disclaimer: I haven't looked at TCL 8, and
don't fully grok the Perl 5 changes, and have never done anything with
Python; I wrote Ftwalk, which IMHO is a better language than any of these,
but as far as I can tell has no other users in the universe.)

> Overall, though, I'd recommend that readers of the article take a
> few things into consideration:
> 
> 1) They're scripting languages!
>         a) most scripts are 1-offs to accomplish a task
>         b) most scripts aren't GUIs
>         c) most scripts aren't written with speed of execution in
>                 mind (being 1-offs)
>         d) most scripts aren't meant to be embedded applications,
>                 where executable size and speed are critical

Yeh, but some scripts do get pretty big. The attraction is having a
high level interpreted language -- easy to build, test, debug.

Some years ago, I wrote a TCL/TK database application that came to
about 60 pages of TCL. It probably took me a third of the time that
a C application would have took, including the time it took to learn
TCL and build some debug scaffolding. I found two bottlenecks where
the performance seriously sucked, rewrote those in C. The resulting
system was very usable, clean, robust, maintainable.

There are undoubtedly hundreds/thousands of similar stories with
TCL; same these days for Perl and Python. To a large extent these
three languages are competing for medium/large scale scripted
applications, not for the traditional "1-off" niche. Take a look
at what's been added to each in the last 2-3 releases, and ask
yourself how much of that's really usable from the command line
or embedded in a small shell script.

> 2) Perl was written primarily to be a "Practical Extraction and
>    Report Language" -- to combine data and generate reports. While
>    its functionality has obviously expanded, a language's raison
>    d'etre musn't be forgotten.  TCL is almost never mentioned in a
>    sentence without "TK". It's aimed at created GUI programs.

Admittedly, TK is in many cases the compelling reason to use TCL. But
there are non-TK applications of TCL: Expect is probably the most
famous. Expect is very good for developing test harnesses, especially
for interactive programs.

I think an interesting distinction between TCL and Perl is that Perl
is intentionally a distillation of other programming conventions (C,
sh, sed, awk, basic), whereas TCL essentially starts with a blank
sheet of paper and builds something simple and relatively easy to
understand. This makes TCL much easier for novices.

> With that, I offer my quick rebuttals:
> 
> 1) Simplicity:
>         TMTOWTDI.  There's more than one way to do it. I argue
> that this /supports/ simplicity -- you can program the solution to
> fit your mental model -- not the one forced on you by TCL.  Yes,
> there are cryptic perl programs -- tell me there aren't cryptic
> TCL ones.  Is it easier to create a cryptic perl program than a
> tcl one? Maybe. Is it a given that a perl program is going to be
> harder to read than a TCL one? No. See the response to #2.

TCL has very simple lexical rules, and almost no parsing. It has a
smaller core command set. It makes much less use of punctuation,
which is relatively hard for humans to decipher. It has explicit
variable declaration and scoping, and rigorous error checking,
which makes debugging relatively easy.

However, the real test is how hard is it to write the specific
application that you need. Sometimes Perl's relative complexity
and makes it more likely that it already has a features that
does something that you want to do now, which you would have
to implement in a simpler language. I suspect that every Perl
fan can show you examples of tiny fragments of Perl that do
mindblowing wondrous things; I can't think of anything comparable
in TCL itself, although TK is full of wonders.

> 2) Maintainability:
>         This results from #1. If you, as a programmer, know that
> your script is not agoing to be 1-off, you comment it. You
> document it. You program legibly.  None of which perl prohibits.
> In fact, it could be argued that if you're familiar with perl,
> perl provides /many/ mechanisms to /support/ maintainability. If
> you're not familiar with perl, why are you programming in it?
> 
> 3) GUI:
>         Perl allows you to create GUI programs if you want (with
> the Tk extensions, among others).  What sits behind 90% of the CGI
> programs out there today?  TCL?  Um, no.

What's CGI got to do with it? (Assuming you mean Computer Gateway
Interface, not the obsolete graphics CGI.) I think it's fair to
say that more people use TCL becuase of TK than the other way around.

> 4) Development tools:
>         The article appears to focus on code development, which is
> a separate flame-war.  What environment you choose to develop in
> is a personal preference, IMHO, and not a factor in choosing a
> language.

This argument is a plug for Scriptics' commercial products. In a way
it's a counterargument on the language. If the language is so easy
to learn/use, why do you need an application builder for it? (Hint:
TK packing.)

> 5) Internationalization:
>         Apparently this article's author hasn't checked CPAN in a
> while. I8N, Unicode, Soundex, and on and on.

They're saying Unicode support is built-in, not an add-on package.
FWIW, Unicode is something TCL picked up from Java.

> 6) Extensibility:
>         If you think perl isn't extensible after looking at CPAN,
> you have a different idea of extensible than most, IMHO. The
> beauty of perl is -- if you want to add functionality to perl, you
> write a perl module!  Not C, not C++, not Java, not some /other/
> programming language.  Then you can share it with the rest of the
> perl world!

There are thousands of extensions in all manner of languages for both
TCL and Perl. TCL is probably better designed earlier to facilitate
extension, but it's really a moot point now. TCL does not have the
strong package module concept that Perl has, but that is partly
because TCL was more conservatively scoped in the first place.

> 7) Thread-safe:
>         I'm wondering why you care if a /script/ is thread-safe.
> If you're concerned about this (and a bunch of other 'serious'
> programming issues), you shouldn't be trying to write your program
> in a scripting language.

Interesting issue here. Thread support opens up whole new application
classes to higher level languages. I think this will be an attractive
feature, and that Perl and Python will follow suit. (Again, TCL is
following Java's lead here.)

You skipped the real #7, Embeddability. I've never tried embedding
Perl (it certainly is supported), so I can't comment on how simple/
difficult it is. I have embedded TCL, and it is indeed clean/simple.
TCL was sold heavily on its use as an embedded extension language,
which is why Richard Stallman hates it so much. (RMS favors Guile,
or E-Lisp.)

> 8) Range:
>         This one really makes me laugh. Again, check CPAN.
> Notice how the meat of this point is really just a recap of
> previous points.

Both sides have mind-bogglingly huge user bases. I'm sure TCL had
more 5-6 years ago, but I'm not sure now. I think there's more TCL
buried in commercial products, but don't see that as a point in
its favor.

> 9) Event handling:
>         Just plain wrong. Apparently the author hasn't ever tried.
> Type 'perl' at your favorite command prompt and enter these 2
> lines:
> $SIG{'USR1'} = sub { print "Hello, USR1!\n" }
> while (1) {}
> (Now hit Control-D)
> In another window, find the PID of the perl program
> (ps x | grep perl) and type
> kill -USR1 that_pid
> an watch your customized event handling say hello.
>         Or maybe they're talking about TCL's event-driven
> programming model, which stems from it's GUI-driven purpose. A
> mouse-click sends you to this subroutine. A double-click sends you
> here. Hitting ENTER takes you there. And so on. Apples & Oranges
> at that point.

Clearly this claim needs some more documentation. I thought they were
talking about select, but Perl supports that. Maybe threads? Maybe
on NT, where thread support is really needed for event handling?

> 10) Speed:
>         See the point about using a scripting language in the face
> of serious programming concerns.

The main selling point of HLLs is faster development time, which is
a nice goal regardless of how large your project is. The main downside
is speed, so it stands to reason that faster makes it possible to use
HLLs on more projects.

TCL has traditionally had speed problems -- not so much the interpreter
as particular implementations, especially lists. Things run fine for
small test cases, but scale horribly. The claim is that TCL 8.0 fixes
all these speed problems, at least as good as Perl (which is generally
regarded as about as fast as any interpreter can be).

> I'd add a comment to the page, but it's just not worth trying to
> convince people one way or the other. Knowledgable people will
> make intelligent decisions.  One hopes.

Doesn't seem to work that way, but maybe that's because nobody's
really knowledgable. We all just have vastly different interests
and expertises, plus some anecdotes that pass unconviningly for
facts.

-- 
/*
 *  Tom Hull * thull@xxxxxxxxxxx * http://www.ocston.org/~thull/
 */

-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi