perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Octavian Rasnita" <orasn...@gmail.com>
Subject Re: [OT] Advocacy (was Re: decline and fall of modperl?)
Date Fri, 27 Mar 2009 10:12:13 GMT
You are right. Sorry for the last few messages.

I think that we all know that there are differences between the software market in different
countries, and that it is much harder to promote perl in the countries which are not so much
developed.

Octavian

--
Octavian

  ----- Original Message ----- 
  From: Joe Schaefer 
  To: David Ihnen ; Octavian Râsnita 
  Cc: modperl 
  Sent: Thursday, March 26, 2009 11:20 PM
  Subject: [OT] Advocacy (was Re: decline and fall of modperl?)


  Could we PLEASE move this lovely conversation to the
  advocacy@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 <davidi@norchemlab.com>
  To: Octavian Râsnita <orasnita@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




Mime
View raw message