Complete.Org: Mailing Lists: Archives: discussion: June 2000:
[aclug-L] Re: TCL vs PERL
Home

[aclug-L] Re: TCL vs PERL

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: discussion@xxxxxxxxx
Subject: [aclug-L] Re: TCL vs PERL
From: Jeff <schaller@xxxxxxxxxxxxx>
Date: Fri, 23 Jun 2000 20:41:02 -0500 (CDT)
Reply-to: discussion@xxxxxxxxx

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.

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
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.

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.

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.

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.

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

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!

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.

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.

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.

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


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.

-jeff
--
We are all agreed that your theory is crazy.  The question which
divides us is whether it is crazy enough to have a chance of being
correct.  My own feeling is that it is not crazy enough. -- Niels
Bohr





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


[Prev in Thread] Current Thread [Next in Thread]