perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From john edstrom <edst...@teleport.com>
Subject Re: decline and fall of modperl?
Date Fri, 27 Mar 2009 17:13:18 GMT
FWIW, I'm enjoying this diverting discussion and think it should stay
here.  Clearly, its an organic outgrowth meeting a need of the other
business in this list.

On Fri, 2009-03-27 at 10:35 +0200, Octavian Rasnita wrote: 
> From: David Ihnen 
>         > > en the newer perl modules on cpan started to use OOP, and
>         > I guess this is because OOP is better, even though under
>         > perl it usually 
>         > > makes the programs run slower. 
>         > Perl's speed, even under oop, is good enough.  OOP makes the
>         libraries easier to maintain and extend.  You should well be
>         an advocate of 
>         > good-enough - thats what the php programmers are all about,
>         right?
>         
>         I know this, but the perl docs tell the truth that perl OOP is
>         slower than functional perl and the beginners don't like to
>         hear that using OOP under Perl make it slower.

Its also worth noting that it is often the case that using an efficient
OO package of, say 500 lines of code, will obviate the need for maybe
1,000 lines of procedural code that might be needed to do the same
thing.  Its not always a simple comparison.  Doing y = x + y in OO perl
is certainly a losing strategy, but manipulating a large XML document in
OO perl is almost certainly better than a procedural approach.


Somewhat off topic, I've noticed that nobody has yet mentioned Perl's
fabulous Inline module.  On more than one occasion I've had to resort to
Inline::Java to take advantage of some proprietary jar or standard java
class that does some obscure jiggery-pokery so deeply buried in vast
tangled class hierarchies that it can't be found, fathomed or faked by
mortal man.  Just write a simple java shim to massage data transfer
between java and perl domains and you're off to the races!  If the
off-loaded work is big enough the performance hit is negligible.  (The
first hit takes some time to instantiate a java interpreter thread but
everything after that runs quick as a bunny.)

I've also had to invoke perl inside php on occasion because the
available php html parser was just too clunky to do what I needed. (that
was in a Drupal site)  Once I learned that trick my toughest php
programming challenge was to not use it everywhere. :-)

The barriers between languages aren't insuperable; you needn't swing a
project to one language just to use some key package you need/want in
that language.


One last gratuitous point in passing is that one of my chief gripes
about php (chiefly, but also Java with its ever-growing uncountable
infinity of classes and interfaces) is that php is TOO function-rich.  I
find I spend a lot of time thumbing through documentation looking for
which of the two dozen regex thingies to use in a particular case
instead of thinking about the program I'm writing.  Perl only has one,
really.  Although there are more than one way to do things in both perl
and php, it seems to me that in perl you can often do it by something as
simple as rearranging your brackets while in php you have to suss out
the best reserved special function for that particular task if you want
to benefit from its inherent efficiencies.

My point is that discussions of how easy/difficult it is to learn one
language or another rarely come to grips with the real finite cognitive
limit of the human mind to keep more than 5 balls in the air at one
time.  Its really hard to be think creatively about evaluating 5
different strategies when you're forever changing mental contexts to
look up a dozen damned functions in some damned index.  I've been
writing php and perl for about the same length of time but I have never
once felt that I "understood" php.  On the other hand I haven't had to
consult my Programming Perl book more than a dozen times in the past few
years.  There needs to be an objective and quantitative measure of
ease-of-learning based on empirical measures of how badly beaten up your
copy of Programming Perl/PHP/Java/* is per line of code written over
time.


-- 
john edstrom <edstrom@teleport.com>


Mime
View raw message