Why I use mod_perl (PR stuff)

[James G Smith <JG...@TAMU.Edu>]

While we're talking about mod_perl, perhaps I can throw out a few
reasons why I have chosen it over other languages and technologies.
This might help us figure out where we need to do some intial PR
work.

We currently have our account management code using PHP (this is for
about 100k accounts).  We made this choice because that is what our
vendor supported with their libraries.  Unfortunately, the libraries
had run-time assertions in them that made them unusable in a
production environment, but we didn't find this out until we had gone
production.  The alternative at the time was Tcl if we wanted to use
vendor supported platforms.  I was very aware of mod_perl at the
time, but was unable to use it because of the vendor support.

Now that we know we can't use what the vendor supplied, we are free
to use a different platform, and we are moving in that direction.

The reasons I do not want to maintain our application in PHP (< 5):

  o No Namespaces
  o Poor object implementation - defaults to pass by copy instead of
    by reference (unexpected)
  o Difficult to separate along MVC lines (thus customer service
    won't touch anything for fear of messing up a program)
  o Difficult to manage exceptions
  o Configurations are parsed on each and every request
  o PHP is based on building small web sites
  o No support for testing
  o No support for documentation
  o No standard way to package and distribute an application
  o No way to declare variables / manage typos

Some of these might be due to my inexperience with the language (I
learned it by writing the account management system) and my
expectations from Perl.

The reasons I am going with mod_perl:

  o All the benefits of Perl
    + namespaces
    + objects passed by reference by default (due to how they are
      constructed)
    + unit testing
    + pod
    + CPAN
    + distribution / packaging standard
    + use strict
    + map, grep, and other lispy constructs
    + dangling commas are allowed
  o Perl has a strong sys admin history
  o Server startup hooks, so configurations can be parsed at startup
    and cached - allows more requests / sec.
  o Better integration with Apache request management, so I can
    control each of the different phases as much as I need to --
    Apache is an integral part of my application instead of something
    feeding requests to my code

I am not being exhaustive, but I think it gives some idea of what I
find important in my development environment.

The conclusion seems to be that PHP is nice for small systems and
applications, but for larger, more complex  projects, mod_perl is the
only one of the two that can compete with the expectations coming
from the Java side (which, as much as we may hate being compared to
Java, we have to address if we are going to make headway in shops
that are already using Java).  Perhaps we can find ways to leverage
that.
-- 
James Smith <JG...@TAMU.Edu>, 979-862-3725 
Texas A&M CIS Operating Systems Group, Unix

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Why I use mod_perl (PR stuff)

[Chris Shiflett <sh...@php.net>]

Not to discourage any PHP bashing (I'll often join in), but a few things
on your list aren't really that accurate:

--- James G Smith <JG...@TAMU.Edu> wrote:
>   o No support for testing
>   o No support for documentation
>   o No way to declare variables / manage typos

PHP has these particular things, although I agree with the rest of your
list.

Chris

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html