[SunRescue] Anyone else here hate Perl?

Steve Pacenka rescue at sunhelp.org
Wed Apr 4 07:00:56 CDT 2001


Chris Byrne wrote:

> I think my main problem with perl is the bloat. It has grown and extended
> far beyond what it's original goals were. Normally this isn't a bad thing,
> but that growth has been very convoluted and , from my perspective, poorly
> managed.

Well, I'm a big Perlfan and I use it for a lot of things, having put aside C, 
shell scripting, Awk, and Pascal for most purposes over the last ten years. 
But I have to agree that today it is a monster.

A fitting reference:

  camel = horse designed by a committee
  perl = camel designed by a committee

Perl started off as one person's attempt to combine features from several 
languages.  Over the years it has accumulated more authors (Larry Wall is such 
an accommodating fellow) and is as eclectic as any language I've seen.  (PL/I 
was the closest competitor.  That similarly tried to blend different languages 
including COBOL and FORTRAN.)


> That said, it still doesn't condemn the language as a whole. It just
> encourages uses for which it is entirely unsuited, such as writing an entire
> multi-thousand line application with another entire multi-thousand line GUI.
> These could generally be much more efficiiently programmed in C or Java.

Perhaps unfortunately, Perl IS suited for this now.  So is the similar TCL+Tk, 
which at least has a smaller and simpler basic design.  I'm typing this within 
the wonderful EXMH mail client program which is a GUI front end to the mh or 
nmh mail user agent suite.

What does "efficiently programmed" mean?  Lines of code to implement a given 
function?  Execution time?  Development time?  Ease of modification by the 
original author?  Ease of cooperation among several developers?  Ease of 
maintenance afterward by another author?  Code reuse?

For me at least, Perl holds up pretty well by most of these metrics.  CPAN is 
an outstanding example of code reuse.  I find Perl to be extremely efficient 
in lines of code terms, taking many fewer lines for the kinds of programs I 
write in it (file processing, number crunching) than any other language I 
used; Awk was close.  The edit/run paradigm without a visible compile/link 
step feels faster for incremental development than the Pascal and C IDEs I 
used before.  Perl's database (for example, dbm files) access has been very 
helpful, along with the string processing strengths it inherited from Awk.

It is possible to write unmaintainable code in any language.  (Obfuscated C 
contest, anyone?)  Blame the coders.

> Perl is and always will be at it's heart a regular experession based, string
> oriented scripting language, and any attempt to use it for something else is
> probably inefficient at best, and nightmarish at worst.

That is Awk's heart, only one part of Perl's early heart.  The database access 
(originally dbm and now much more), array handling, and network socket 
operations were there way back when and Perl remains something that is well 
beyond Awk because of them.

-- SP





More information about the rescue mailing list