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 <edst...@teleport.com>
