Looking for balanced critique of Perl

[Tom Christiansen]

I suspect that most readers here have already read things I've posted
extolling the virtues of perl programming over shell programming, so
I'll try to skip such scintillating remarks.  On the darker side, I 
honestly do maintain that there are several areas in which perl is weak 
and therefore a sub-optimal pick as the programming tool of choice.

Interacting with binary data is cumbersome and error-prone, albeit
feasible.  I say cumbersome and error-prone because even if you set
things up to automagically rebuild the perl version of <sys/acct.h>
when the C version in updated (I do), you've probably got an $acct_t
variable somewhere to serve as the format for pack/unpack conversions,
and this WON'T get automagically rebuilt.  So you lose and there's
nothing to warn you of this.

I'm not entirely convinced that socket-level networking is really moost
appropriately done in perl, although I've written some programs of the
order of 500 lines that do appear easier in perl.  There are no
facilities for RPC calls.  I'm not sure there ought to be, either.

I don't know that I'd be thrilled to see Xlib built into perl, and
while I know Larry's adding curses, or at least providing the ability
to do so, I wonder how well this will work out.  I'm concerned about
efficiency and ease of coding of these things.  Will the ability to 
patch in your own C functions cause people to turn from C in cases
where this is not honestly merited?

I also wonder how well perl scales to very large applications.  My
largest single perl program (man) is itself a bit over 1300 lines long,
not a long program as programs go, but due to the frequency with which
it is run and the annoyance factor of having to wait a couple seconds 
for the parse to complete each time, I've undumped the script into an
a.out, at which point it does beat the C version man program (and does 
a lot more, too.)  But I'm sure there must be a point of diminishing returns.

I've also had plenty of experiences with bugs, although to his credit I
must admit that Larry's been a lot more responsive in this arena than
any software vendor I've ever had dealings with, even though THEY were
getting paid for maintenance.  Still, sometimes you encounter a nasty
bug and get a core dump or wrong answer and spend hours isolating it to
prove to yourself it's not your own fault.  Sometimes even when I'm
convinced it's not, it really is, such as a sprintf() problem I had
with a %-1000s field or some such similar nonsense.

The bug that bites me worst right now is that sometimes in large
programs, function calls under the debugger mysteriously return 1
rather than the value they are supposed to return.  This problem
evaporates when subjected to intense scrutiny: if run NOT under the
debugger, or reduced to a small test case, all works well.

One of the criticisms that one can make of perl is that it's prone to
obfuscation, even more so than C.  The regular expressions can easily
become illegible, and with the ability to eval newly generated code on
the fly, all things are possible.  Of course, much of the guilt lies
on the individual programmer for poor coding and commenting habits, but 
nonetheless there seems something in the language that too easily 
lends itself to obfuscation.

Don Libes, the original poster, mentions that most of what he's read
in magazines and on USENIX has been over-enthusiastic, with little
criticism to the contrary.  Well, if you've read Kolstad's UNIX REVIEW
articles of the past three months (inspired/derived to a certain extent
from my USENIX tutorials), you'll see that Rob has in several places
been less than fawningly complimentary.  He mentions that it's a
kitchen-sink language, perhaps a little feature heavy.  He speaks of
the daunting, information-dense man "page".  He complains that how are
you supposed to just "know" that to access the aliases DBM database you
have to concatenate a null byte, as in $aliases{'kolstad'."\000"}.
(This latter actually makes sense when you figure it out, but I won't
try to explain it here.)  So he's at least trying to acknowledge some
of the difficulties people may have with it.

[Don Libes also ponders what "real computer scientists" have to say about
the language.  Well, what's it take to be a "real computer scientist"?  Do
O/S people count, or only language designers and compiler writers?  Do you
need certain degrees, publications, or world renown?]

It's true that I was the first here to use perl; I grabbed it when the
first version came out.  But unlike Don Libes's site, there are quite a lot
of people using perl here.  Some of these are for projects purely in perl,
some are as auxiliary tools for major projects involving C and C++, while
others are for automated software test scripts or system administration
purposes.  It was originally for purposes of system management that it was
first appreciated, but in the last year or so many others have embraced it
as well.  I don't really know how many perl programmers we have here now:
it's well over a dozen, maybe two, and the number continues to grow weekly.

So in answer to Don's question, yes, I do think that other people than
Larry can program in perl.  I might amend that to say that the answer is a
qualified yes.  The qualification is that I don't believe anyone can
program quite so effectively in perl as can Larry.  He of course
understands not just some but each and every one of the semi- and
undocumented nuances of the language.  I think I'm pretty good at
programming in perl, but still most of what I do still comes out looking
like C with embedded sed.  Larry takes a problem, looks at it a different
way, and often comes up with something two orders of magnitude simpler and
faster because of his intimate acquaintance with the language.  It's only
now and then that I come up with something that doesn't look very C-like,
as in:
    next if $sections && !grep($mandir =~ /man$_/, @sections); 
and even then I feel somewhat guilty about it. :-)

I hope that most of the subtleties of the language will be outlined in
that fabled tome, the perl book he and Randal are working on.  I'm
especially interested in matters of efficiency and optimization.  Larry
often writes thing with big multi-line evals, and I'd like to have a
better grasp on why this is so often so important for getting the promised
'faster-than-sed' performance.  I think that this book has the potential
for making perl more accessible to the general public.

One final concern still makes me wonder, and is not a new one: just where
is this thing called perl going to?  Towards what is it evolving?  Will it
reach a point in its evolution when it is "done"?  I hope so, but let it
not be at the hands of some maiming standards committee.  Let it be the
handiwork of just one craftsman, one vision.

I'd like to be fair and optimistic without an undue quantity of zeal
fueling my discussions.  I, too, am very interested to hear what others
who've used this tool long enough to have a balanced view of it have to
say.  I've heard, and myself written, plenty of the good, and I, too,
would appreciate hearing the darker experiences people have had about it.

There is no ultimate answer to anything, let alone programming.  But for
what it was designed for, perl is a refreshing and pleasant change of
pace.  I'm reminded of around a decade ago on a little Z-80 running CP/M
with only an assembler how very painful it was to generate any program at
all.  When I finally got a C compiler, it was such a refreshing pleasure,
I cranked out a new tool on nearly a daily basis.  (Of course, some may
argue that the pleasure was as that of stopping banging your head against
the wall. :-)  

I will dare to suggest that some of the bad experiences people may have 
had with perl stem from trying to use the wrong tool for the job, but I 
don't know that for sure.  All I know is that for much of the quotidian 
toil that faces the tool builder and the system administrator, who often
have to whip together a passably functioning piece of software in nothing
at all resembling the normal, well-deliberated process of planned software
development, that perl is a true blessing.  It is in my sincere and considered 
opinion the most significant piece of general-purpose software to hit the 
software community since awk, and in that respect far exceeds awk's humble
ambitions.

--tom
--

    Tom Christiansen                       {uunet,uiucdcs,sun}!convex!tchrist 
    Convex Computer Corporation                            tchrist at convex.COM
		 "EMACS belongs in <sys/errno.h>: Editor too big!"