perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Ihnen <dav...@norchemlab.com>
Subject Re: decline and fall of modperl?
Date Thu, 26 Mar 2009 21:10:58 GMT
Octavian R√Ęsnita wrote:
> *From:* Rolf Banting <mailto:rolf.b.mr@gmail.com>
>
>     > Functions are first class citizens in Perl - so you get
>     functional programming built in. You don't in Java.
>
> Even 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?
>
>     > How are standards of OO quantified and compared?
>
> Simple. They should follow the "modern" standards, standards made by 
> those who have the power to promote their way - Sun, Oracle, IBM, 
> Microsoft.
> This is because if a student learns C#, and learns Java, he will find 
> easier to learn an OOP style similar to that from Java than a way like 
> the one used in Perl.
I can't believe you would say that the particular syntactical constructs 
used in the object oriented declaration is even slightly relevant to the 
usability of the language.  saying 'package' instead of 'class'?  Saying 
'use' instead of 'import'?  I'm agog.  Any language transition involves 
learning new syntactical constructs for the new environment you're in.  
And thats the only real difference between The Java/C# 'style' and perl, 
is it not?  THe keyword syntaxes?  As for design patterns, perl does 
them with fewer hoops than the other languages - which is what a 
learning student needs to learn. 

>             And anyway, for the beginners, this is not a big problem.
>             The biggest problem is that perl is harder to learn. The
>             programmers might want to learn a language for a year, and
>             get a job, and after this they hope that they will find
>             time to learn the chosen language better while they have a
>             job.
>
>     Harder to learn than what? Is there any evidence for this?
>
> Yes. Most PHP programmers I know, that also tried to learn Perl told 
> me that PHP is more easy to learn and to use.
And C is easier to use than C++, but you don't see anybody going around 
saying that they should use C to write enterprise applications these days.

Unfortunately I think some are trying to be written in php.
>
>             > There are very many recent books that teach Perl.
>
>     Why is "recent" important? The language features haven't changed
>     much so why would the learning resources?
>
> Because Catalyst is very fast changing, DBIx::Class the same, 
> HTML::FormFu the same, CGI::Application the same, because Moose 
> appeared, but there are no very many books that talk about them (or 
> other modules).
The moment a fast-changing thing is documented, the documentation is out 
of date.  Its a fundamental problem with dead-tree editions of 
anything.  I'm not surprised that there aren't books on these things.  
Mostly because the documentation is readily available online and 
anything written is obsolete before it hits the presses.
> Perl is great, but I think it will remain a niche language for a long 
> period, even though we know that we can do everything with it. The 
> truth is that we can't do really everything with it. There are 
> applications made in Java that do annimation, graphic games, search 
> engines, and many other things that we can't do only by using perl, 
> without C or other languages.
Yes, we cannot do everything with perl.  But that is okay.  What is 
important to remember is what we CAN do with perl.  Even when you have a 
high-performance graphical processor module written in C/C++/Java, the 
business rules, glue, and associated logic that is not fine-grained 
performance critical are best implemented in a scripting language just 
like Perl.

Implementing your application in C++ because you need *some* 
fine-grained performance critical code is, in my experience, foolish.  
Yes, implement your critical code in a tight language.  But when most of 
the application just comes down to glue, field name translation, and 
rules checking - this is better scripted than coded in a compiled 
language.  I've wasted tens of thousands of dollars of my employers time 
compiling and debugging because of the application's shortsighted 
architecture put many of the business rules in C++ instead of a script 
like perl!  (it was all the worse because at an arbitrary divider, some 
of the rules WERE in a not-quite-perl like configuration language - if 
they had taken it all the way a job of months would have taken weeks) 

It was quite a mind-blow when I realized that the c++ application that 
took a gig of memory *per process* to run that I and my coworkers 
struggled with making behave for so long came down to something that 
could have been implemented with daemontools, a WSDL checker module, 
DBI::Oracle, and a passel of business rule implementation classes.  
(Turns out the windows on that building don't open...)

Playing nicely with other applications is merely a matter of interface 
definition and integration testing.  Well defined specifications and a 
perl module service can interact with any other.  Being able to work 
with your application because it doesn't take 40 minutes to compile a 
SQL typo fix is not priceless, but its worth a heck of alot.

David


Mime
View raw message