python vs perl lines of code

[Edward Elliott]

A little out-of-order execution seems useful here. ;)

John Bokma wrote:

> Edward Elliott <nobody at 127.0.0.1> wrote:
>> I can readily believe that the "community" frequenting the newsgroups,
>> mailing lists, and blogs don't encourage it anymore.  But that's a
>> tiny fraction of all perl programmers, and most of them have no
>> exposure to this little clique.
> 
> Pfft, you are just guessing around now.

How many organizations have you worked at?  How much exposure to coders
whose daily job description doesn't include the word programming?  I've
been at Fortune 100 companies with thousands of programmers and support
staff, and at startups with a half dozen employees.  I've been employed at
3 universities from small to huge.  I know full-time software developers,
software testers, sys admins, network admins, managers, web developers,
graphic artists, physics researchers, bioinformatics researchers,
instructors, librarians, consultants, contractors, hardware engineers,
forensic analysts, and even a law professor.  They all code perl to some
degree.  Many of them don't even know what a newsgroup is, and you can have
their cookbook when you pry it from their cold dead hands.  Guessing?
Hardly.  Just not trapped in your insular world of who makes up the perl
"community".
 

>>> Don't forget that most
>>> of the book was written around 1998. Yes, 8 years ago.
>> 
>> Doesn't matter.
> 
> Yes it matters. 8 years is a lot of time in IT. In 1998 Perl5.005 was
> announced (22 July). [1] Which should tell you a lot if you indeed have
> 3 years of Perl skills.

Tell that to everyone who relies on the cookbook.  It gets their job done. 
They don't care if it was written in the dark ages.  Until a replacement
comes along, that's what they'll use.  Of course Perl itself has moved on,
that's not the point.

 
> If they are serious with their study they know that a 8 year old book is
> hardly up to date. I tend to take most IT related books I use that are
> older then 3-4 years with quite a grain of salt. I am not going to take
> an 8 year old Java CookBook very seriously for example.

Many/most people aren't "serious with their study" of perl.  They just want
to get things done.  Perl 5 works for them now, it will work for them 10
years from now.  Unless something significantly better comes along to
justify the cost of switching, they'll stick with what they know.  And that
includes perl 6.  One would hope an updated cookbook is out before then. 
Or maybe it's not needed because the current one works just fine.

Time isn't a great measure of language change.  A C++ book from 8-10 years
ago is just as good as one today in most respects (maybe exceptions and
templates are a bit underused).  A C book from 20 years ago is perfectly
fine for most purposes (how well does K&R stand the test of time?).  C99
and C++0x aren't revolutionary changes (ISO committees frown on such
things).  God only knows how far back useful LISP resources go.

 
>>> You can even find examples on my site that use imported functions
>>> (which I will fix, because I frown upon it :-) ). But I doubt you can
>>> find a majority in the perl community that *encourages* the use of
>>> imported functionality.

I'm not arguing what best practices the hardcore community recommends. 
Many/most perl programmers aren't part of that community, their only
exposure is the perl books (especially the cookbook), and they'll do
whatever it says in there.  Call perl a victim of its own success (a nice
position to be in).


>> For many people, whatever the
>> cookbook says goes.  If it's wrong, update it.
> 
> Well, contact the authors or O'Reilly. 

Sorry, I've got a bad case of "not my problem". ;)

> Seriously, are you using 8 year 
> old Python recipes without thinking?

Sure, if they do the job and an updated reference isn't handy.

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net