Re: virii

[Richard Cobbe <cobbe@airmail.net>]

Nori Heikkinen <nori@sccs.swarthmore.edu> writes:

> on Fri, 26 Jul 2002 11:14:31AM -0700, Craig Dickson insinuated:

> > No. The point is just that Wall's occasional references to the
> > linguistic basis for Perl's design are basically BS. He may have a
> > bachelor's degree in linguistics, but he isn't a linguist, and
> > according to my friend at Stanford, most of what he says about
> > linguistics in connection with Perl (or programming language design
> > in general) is wrong.
> 
> to what exactly are you referring?  i'd be very interested to see what
> he says on that score.  the only reference i've run across about that
> is this http://www.wall.org/~larry/natural.html, which isn't
> particularly BS, but doesn't draw any non-tenuous conclusions, either.

I tend to agree; Wall has an amazing ability to talk for a great deal of
time without really saying very much.  

One also wonders exactly why he has decided that the principles of natural
languages should automatically apply to programming languages as well.
They're really two very different things, that are processed by two very
different systems.  The human brain is really very good at resolving
ambiguity, largely by figuring stuff out from context.  Computers don't do
so terribly well at this.

One could argue that Perl tries to be smarter about figuring things out
from context, and there's some truth to that.  This does, however, come at
a price: the rules that explain exactly what a particular perl program does
become far more complicated.  For quick-n-dirty 50-line scripts,
programming `by intuition' may be OK.  For `serious' work, though, the
programmer has to have a detailed mental model of exactly what his
programming language will do.  Because of all of the disambiguation stuff,
the mental model necessary for Perl is very large and very complicated,
especially when you compare it with languages like C or Scheme.

Then, combine this with implementors who are, not to put too fine a point
on it, clueless and completely unaware of the last 20-25 years of work in
programming language design and implementation:

  - Perl uses a refcount GC.  Why?  These are known not to handle cycles
    well, and we've had better alternatives for the last ~35 years.
    (Mark-n-sweep was mid-60s, copying was mid-70s, generational was '84,
    and there are some more recent developments as well.)

  - Continuations, to be added to Perl 6.  Why?  Well, basically, because
    they sound cool.  At least one Perl implementor has publicly said (at
    last year's Lightweight Languages conference at MIT
    (<http://ll1.mit.edu/>) that he didn't reallly understand how they
    worked or what they were for, but they sounded cool, so they were going
    in.  (Don't get me wrong, continuations *are* pretty cool, but only if
    you understand what's going on under the hood.  Otherwise, they'll get
    you in a heap of trouble, fast.)

So, we've got a complicated, ill-designed language, implemented by folks
who are more swayed by hype than by solid technical and logical reasoning.
Sounds like a winner to me!  (<sound of Richard retching in the corner>)

Now, don't get me wrong; there are some things that Perl does very well,
like string handling.  It would be wonderful to see, say, Scheme (my
language of choice) do better at this.

Richard


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org