[aclug-L] Re: TCL vs PERL

[Tom Hull <thull@xxxxxxxxxxx>]

Jeff wrote:
> 
> Another real quick reply...

And another.

> On Sat, 24 Jun 2000, Tom Hull wrote:
> 
> > Jeff wrote:
> > > 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 don't even want to write kernel code in assembly, but I know folks
who are still most comfortable working in it. Given the choice,
people will almost always try to work in what they know best.

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

Often they start small and just sprawl. That's easier to manage in
a scripting language, because the minutiae gets buried, and what's
left comes closer to being self-documenting. If you start off in
something like C++, you spend most of your time implementing and
burying details. You also have to plan ahead in C++, whereas often
you can get away with a lot of slop in a script language. The
script language programs are easier to rework, too.

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

If you had to translate English into something dumb enough for a 
computer to understand, you'd be in for a _lot_ of effort. But I
think your point is that rich languages ultimately make things
easier, and I think that is true.

FWIW, in Ftwalk I tried hard to construct a scripting language
which would be intuitive to anyone who started out with a fairly
strong understanding of Unix programming (sh, awk, c, a little
c++). Since this prerequisite understanding is so large, a rich
language was needed, because that is how we think.

> > It has a smaller core command set.
> 
> As you mention below (or was it above), this is either a plus or a
> minus.

It's a plus in the sense that it gets you to a point where you think
you understand the language much sooner. Languages are daunting, and
this gets you past the fear factor.

However, it's a minus in that it leaves you that much more beyond
learning the language that you have to figure out in order to get
real work done.

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

TCL doesn't give you the option of not being rigorous about scoping.
I personally find this a pain, at least for small scripts, but I
imagine it would help keep novices from going astray. As I recall
from way back when, learning to debug was harder than learning to
write programs. When you write a program, you necessarily work from
what (little) you know, but when something goes wrong it could be
anything.

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

It does seem to be moving in that direction, but even so I think of
most CGI scripts as written in Perl but shoving something else out
to the browser -- mostly HTML, JavaScript. TCL/TK has support for
in-browser scripting; i.e., you load a plug-in which recognizes
TCL/TK from <SCRIPT> tags, and it gives you the same sort of GUI
controls in the browser as you get in standalone TCL/TK apps. I
haven't dug very deep into this, because I've never felt that I
could insist on my readers downloading the TCL/TK plug-in, but
in principle it should make it possible to turn the browser into
a thin client for an application server. There seems to be a
sizable market for that sort of thing.

(Presumably someone could write another plug-in to do Perl/TK the
same way, but I'd hate to have to figure out all of the security
angles.)

> > (Hint: TK packing.)
> 
> *shivers*

TK packing is pretty wonderful. It takes a bit of thought, but you
can pretty easily come up with GUIs that adjust cleanly to window
size/shape changes. Much, much, much more easily than you can do
anything comparable in something like Visual Basic.

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

TCL has associative arrays (aka maps, dictionaries, hash tables),
which are much more efficient than lists. The big problem with the
lists is that they're kept as strings, which makes them scale
abysmally. (Another problem is that floats are kept as strings,
which causes precision problems as well as performance.) Don't
know how much (if any) of this has been fixed in 8.0, but the
hype suggests some improvement.

-- 
/*
 *  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