Slashdot Mirror
Help Test mod_perl 2 Release Candidates
stas writes "After almost 3 years of work mod_perl 2 is almost ready for its 2.0.0 release. We plan to make the gold release in a few weeks. Please help to test the release candidates by starting to port your mod_perl 1 applications to mod_perl 2. Make sure to read the documentation and report
any problems that you may have discovered. Thanks."
Well, there is of course slashcode, and Amazon.com also uses mod_perl and HTML::Mason (see http://www.masonhq.com/?AmazonDotCom/). I'm sure there are many others as well.
It's not really fair to equate mod_perl to per-page interpreted languages.
mod_perl, and to a certain extent Java servlets, gives you a huge amount of power over the web serving process, and are suitable for developing web applications that can do almost anything with HTTP.
PHP, ASP and the like give you a per-page interpreted language, oriented to producing one page of HTML at a time. They are much easier to get started with, and they're the "right" choice for most websites.
Of course middle-men between the two camps exist: Servlets have JSPs, for example, which obey a per-page paradigm but are run by servlets. There are also third-party templating system with greater or lesser degrees of flexibility/depth/power (Tapestry is a particularly impressive one.) My own website (http://n3dst4.com , rather than the one in my profile) is written in Mason, which is an interpreted component and template layer on top of mod_perl. Because of the depth of control that mod_perl has, Mason can do some things that PHP can't, like having a completely programmable request handler, global or per-directory pre-handlers, a seamless component model).
I'm not dissing PHP, though. The site in my profile (Sacred Steel) is written in PHP, because it was the right tool for that job.
Oh, and remember that .net and J2EE are allegedly complete enterprise programming platforms, while mod_perl is just one specific technology for web application programming.
In order to have two different versions of things like Apache::Request (which have changed implementations without changing names), the modules get installed as $libdir/Apache2/Apache/Request.pm. Of course, you're then expected to "use Apache2" to add $libdir/Apache2 to your @INC path. Of course, this breaks every other element of the Perl toolchain that expects that @INC is not changed in such a radical fashion.
This release currently has problems with the PAUSE indexer, the CPAN installation tools, perldoc, and installation of manpages, because they all expect @INC to not be so badly hacked. Stas is trying to work out solutions with the community, but mostly in the form of "This is the way modperl2 works, please fix all your tools", and that's not flying well.
So, beware to those who install this release.
There are several frameworks for Perl.
slashdot big enough for ya?
It has more of a learning curve than php at first, and probably is not appropriate for small static sites, but I have never seen PHP or Java rip out major stuff as fast as Perl, then migrate, modify or otherwise perform client expectations that require redesign. I have worked for two companies where we went to Java. At both companies, more than half the stuff that went to Java was sent back to perl to decrease response time for client needs. Another company I contract to went to PHP for their site when they started, but wound up re-writing the whole thing in Perl with mod_perl when they had a database change. It was faster, and the code came out more manageable, faster and more stable. We learned very quickly that a programmer who writes bad code does it in all languages, and all the good programmers wrote clean concise well documented code (most of the time). And when they wrote something sloppy, it was no more difficult to figure out what they had written than it was in the other languages (Java, php, C, C++, sql, ...)
It is very simple. I am paid by my clients to provide, maintain and modify code. They expect that I will charge them less than others and provide strong solid support and service. Most of them expect one day to one week turn around for change requests. Since we manage the code ourselves, it is very important to us that the code be quick, clear and concise. It must be as reuseable as possible. It must be able to be picked up with and run by new people or contractors. The Java took too long to make the same things happen and PHP ran into dead ends (could not, or more often took too long) when upgrading sites, migrating to new client databases or other client changes. In short, Perl has allowed us to undercut almost all of our competitors in this area. The ones we have not undercut are, believe it or not, perl based shops as well. Java does beat perl for some things as does php for some things, but in so many cases, perl has beat them both.
InnerWeb
Freud might say that Intelligent Design is religion's ID.