[Phoenix-pm] Perl Best Practices

[Scott Walters]

Hi Andrew,

I'll have to poke at this.  I'm still slogging through _Higher-Order Perl_.
Then I have a pile of things to review for Apress.

I thought _Effective Perl Programming_ was a great book and _Perl Best Practices_,
from it's description, sounds similar. _Effected Perl Programming_ showed how to
use Perlism like slices, but was primarily concerned with *when* such things
improved the clarity of a program.  

But that's all part of a larger problem you only hinted at.  To answer your
real question:  Perl is doomed.

Here's a choice quote from _Perl Medic_:  I wrote this book because I kept 
finding myself telling my students, "I'm going to teach you how to program Perl
well, but I'd have to teach you a lot more before you could take over a program
that wasn't written well, and you wouldn't appreciate taking that much time 
away from learing how to write good programs of your own." So I've written a 
book to fill that need. 

The "if you count occurances of the word 'Perl' in job listings, it's right
behind 'Java'" people fail to notice that Perl is almost always listed as a 
secondary skill (a desirement, if you will) and almost never as a primary skill.  
Companies are looking for people that can manage the Perl that's floating
around, but, by and large, there's moving away from it for new projects.  
Conversely, if you see Python as a job requirement, it's almost always a
primary skill, and you can be sure they're actually using it for new work.

Perl's reputation killed it.  Perl 6 might be fantastic, and it'll have good 
company with language such as OCaml, Haskell, Lisp, and Scheme -- powerful 
languages that are never spec'd for in projects.  

I have a theory, formalized at http://use.perl.org/~scrottie/journal/24103,
called "Basic Logo Pascal VB Perl - doomed newbie languages", where I
pontificate that languages generally learned as a first language by
legions of programming novices, are doomed.  It's easier for a novice
to blame the language than himself for the bile he pumped out in his
early years.  It's easier to start from scratch with another language --
such as one advertising it's for people who are interested in writing
clean code -- than it is to change how you see a language.  Logo is
actually a Lisp dialect.  I didn't know that up until recently.  Then
I was upset I started with AtariBASIC when Logo was available on ROM
for the machine.  My cool factor would be much higher.  But regardless,
classrooms full of kids learned to program, starting with a Lisp
dialect, and then abandoned it in favor of things like *C* (C is great
for systems programming, kernels, database engines, and microcontrollers,
but it's a handicap when trying to build an application of any sort).
And you see this quite often.  People switch to markedly inferior languages
as they turn over their leaf and disassociate themselves with their 
first language.  Of these example languages popular with novices, 
Pascal, which has a wretched type checking system, got off relatively
unscathed for at least preaching structured code and readability,
whereas Basic, Perl, VB, and Logo had an attitude of "you're learning,
don't worry about style, just try to make it work". 

The honeymoon is over.  Ten years ago, PHBs didn't pretend to understand
technology well enough to constrain projects to language they read
about in trade rags.  Now they do (they do pretend to, that is).  If it
were just programmers and technical people, Python and Perl could war it
out till the cows came home and both would subsist.  But the decision
isn't being made among technical people who consider technical merits
and tolerate divercity and difference of opinion, style, priority,
and philosophy.  The PHBs see the diversity as a conflict, or an argument,
and they're interested in solving it.  To them, the primary question
seems to be whether Microsoft is *the* solution or Sun is *the* solution.

With my frequent rants about employability as a Perl programmer, I'm 
hinting at all of this -- PHBs consider all programmers to be "about the
same", so they'll pick the one who seems more like a "team player" or
looks less likely to give them grief.  The attitude extends to languages.
Java (which I don't hate, and certainly has it's place and virtues) is
almost always programmed in teams.  Twelve programmers will work 
together, each banging out their own API or extending someone eleses API,
to accomplish something I've done single handedly in Perl, in less time,
with better code.  But if you take a PHB and try to convince them that
there's such a thing as a programming language that's twice as 
effective as another one, you'll fail.  It's all just "vender support",
and "availability of talent", and "industry standards" -- it's never
productivity, efficiency, or technology.  Perl has virtues, but it has
no sought-after virtues.

Interestingly, programmers seem to be adopting this attitude, probably just by
unthinking default.  They expect everything to be about equal, regardless.
These are the people who don't take time to learn Perl well, and aren't
interested in ever getting around to advance Perl concepts.  They don't
progress much on their own, they slog through their days, and you can't
convince them that if they learned a few tricks, their life would be easier and
they'd be more productive.  These are the people who will drop Perl without a
second thought when that COBOL or Java job opens up.

So, things like _Perl Best Practices_ are too late.  Even _Effective Perl 
Programming_ was too late.  They're just preaching to the choir because 
everyone has already taken their path of writing bad Perl or writing good Perl.
If Perl programmers cared about "standard approaches", they'd read things like
Refactoring and Design Patterns.  Object Oriented Design Heuristics is 
exceptional and less trendy and obnoxious.  They don't have to swallow this
stuff wholesale, but if they cared about programming, they'd care about what
the industry at large is up to.  But by and large, Perl programmers act like
your average PHP programmer -- who acts like none of the advancements we've
seen in the last 30 years exist (ask a PHP programmer who Tony Hoare is -- I
dare you).  You can't convince people to care, but when they start to care (on
their own), you can't stop them from switching languages.  Perhaps they're
afraid of what else they've been missing, living in isolation, ignorant of the
world, and the last 30 years, and what professionals are doing at work, and...  

It may have been Perl's reputation that killed it, but it's the novices who
learned Perl and then switched without ever having written a passable line of
Perl that gave it it's reputation.  

-scott

On  0, andypm at exiledplanet.org wrote:
> O'Reilly is about to publish a new book by Damian Conway, _Perl Best Practices_.  There is a sample chapter available on O'Reilly's site:
> 
> http://www.oreilly.com/catalog/perlbp/
> 
> I've read most of the sample chapter (which addresses subroutines) and I thought it was an excellent style guide for making Perl code clearer and more useful.  If the rest of the book is like the sample chapter, it could be an excellent resource for programmers writing complex apps in Perl, especially those that haven't written complex Perl before.
> 
> I'm interested in what others think of this book and the new push by some to define more "standard approaches" to Perl.  Given Perl's reputation in some circles as "line noise," I think this effort could make Perl more accessible, and thus more valuable, to more people.  What does everyone else think?
> 
> --aj
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm