Could we PLEASE move this lovely conversation to the
advoc...@perl.apache.org mailing list? We have an
entire mailing list dedicated to baloney of this sort;
please use it so the rest of us trying to provide this
little community with meaningful software and support
don't have to wade through it.
Thanks!
________________________________
From: David Ihnen <dav...@norchemlab.com>
To: Octavian Râsnita <orasn...@gmail.com>
Cc: modperl <modperl@perl.apache.org>
Sent: Thursday, March 26, 2009 5:10:58 PM
Subject: Re: decline and fall of modperl?
Octavian Râsnita wrote:
From: Rolf
Banting
> 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
