Octavian Râsnita wrote:
*From:* Rolf Banting <mailto:rolf.b...@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
