[aclug-L] Re: TCL vs PERL

[Patrick Klee <trekkie@xxxxxxxxxxxxx>]

Hey!  You know what I just had an idea, why don't the Perl people stick to
Perl, and the TCL people can stick to TCL and everyone is happy, and I won't
get mad about having email flames piling up in my email box.  Kopesh?  Nuff
said.

on 6/23/00 6:41 PM, Jeff at schaller@xxxxxxxxxxxxx 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.
> 
> 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
> 


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