perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: decline and fall of modperl?
Date Fri, 27 Mar 2009 17:24:51 GMT

----- Original Message ----

> From: john edstrom <edstrom@teleport.com>
> To: Octavian Rasnita <orasnita@gmail.com>
> Cc: modperl <modperl@perl.apache.org>
> Sent: Friday, March 27, 2009 1:13:18 PM
> Subject: Re: decline and fall of modperl?
> 
> 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.

Anybody whose been here a couple of years knows this discussion is 100%
offtopic for this mailing list.  Hell, it isn't even topical of the Subject
header.   That won't stop people who have nothing else to offer the list
except for their opinion to mutter onwards, because we tend not to boot
people off the list who abuse it unless it is obviously habitual.

Comparative analysis of programming languages has nothing whatsoever to
do with modperl, or even anything to do with the real needs of this community
of users.  It's simply an exercise in argumentation based on personal
experience alone by people who have absolutely no knowledge of any actual
relevant statistics on the subject (assuming there even *are* any such things).

> 
> 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 



      

Mime
View raw message