[aclug-L] Re: TCL vs PERL

[Jeff <schaller@xxxxxxxxxxxxx>]

Another real quick reply...


On Sat, 24 Jun 2000, Tom Hull wrote:

> Jeff wrote:
> > 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. 

Yeah, it does. My response was mostly tongue-in-cheek.


> One interesting thing about the article is how many of the
> talking points are new to TCL 8.0/1.

Yeah, and these sort of one-uppance arguments fuel feeping
creaturism (to borrow a Larry Wall-ism).


> > 1) They're scripting languages!
> >         a) most scripts are 1-offs to accomplish a task
>
> Yeh, but some scripts do get pretty big. The attraction is
> having a high level interpreted language -- easy to build,
> test, debug.

Hrm, that was probably an over-generalization by me. I tend to see
most of the scripts I write as single-purpose glue or translation
programs. People of course, write programs of all sizes in all
languages (anyone want to write an app in assembly?)

I'd also add that a language that's "easy to build, test, and
debug" is tough to score. Someone who's fluent in the language
will find it easy to do those things.

I'm still not sure why people are writing huge applications in
scripting languages, though. (To answer my own question), probably
because they can.


> TCL has very simple lexical rules, and almost no parsing.

English has very complex lexical rules, and lots of parsing. Once
you know it, though, it takes less effort.


> It has a smaller core command set.

As you mention below (or was it above), this is either a plus or a
minus.


> It makes much less use of punctuation, which is relatively
> hard for humans to decipher.

English.


> It has explicit variable declaration and scoping, and rigorous
> error checking, which makes debugging relatively easy.

Perl has (allows) explicit variable declaration and scoping, and
rigorous error checking, which makes debugging relatively easy.
"my", perl -w, use strict, and splitting subroutines into separate
files.


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

Yes, the CGIs (is it Common Gateway Interface?) on web pages. I
tend to think of browsers as a lowest common denominator of GUIs.
Maybe I'm becoming tainted working as a web systems admin.


> (Hint: TK packing.)

*shivers*

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

Ah, I had thought they were referring to the typical flame-war of
"my code (in language X) runs faster than yours (in language Y)".
The assembly vs C, C++ vs C, etc.  Development time is certainly a
more important scale today.


> TCL has traditionally had speed problems -- not so much the
> interpreter as particular implementations, especially lists.

I completely forgot about this -- does TCL have any advanced data
structures, or is everything still list-based? Any CS graduate
will point out the benefits of non-list data structures.


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

*nods with a defeated sigh*

-jeff
-- 
If disaster strikes, it's God's wrath -- quote the Old Testament.
But if nothing happens, God is merciful -- quote the New Testament.
http://www.theonion.com/onion3546/y2k_survival_chart.html


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