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."
Not a troll, but something I'm genuinely wondering about - haven't things like J2EE, .Net and PHP made mod_perl obsolete? Back in the bad days of the web, the choice was C or Perl hooking directly into the Apache API to avoid spawning too many processes. Then along came Java servlets or ASP for those drawn to the dark side. Would anyone really consider mod_perl for a serious sized web application any more?
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.
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.