How Perl can Avoid Java's Worst Web Messes

I've spent the past month developing an Enterprise Class web site (which means "a CRUD application written mostly in XML configuration files with a smattering of Java here and there") to help out a colleague who shall remain nameless.

The good news is that the Perl world (at least for those enlightened souls fortunate enough to be able to use modern Perl techniques) has little to worry about from the Enterprise Class world.

The bad news is that some of the problems afflicting Perl—especially for people who don't write it all day, every day—are common to software development in general.

For example: this CRUD project uses an Apache framework which has been around for most of a decade and is on its second iteration. Apache projects get a lot of credit for rigorous documentation...

... except that their documentation in this case is, as with most open source projects, a mish-mash of conceptual overviews, API references, contributed guides, tutorials, and links to mailing list archives and blog postings, with little narrative flow between them and, worse, often precious little internal information on which version of the framework applies.

Search for information with your favorite search engine and be ready to wade through inapplicable and inappropriate data, whether wrong from the start or rendered irrelevant several years later. (This is as much an indictment of search engines as anything else.)

Perhaps the most concerning trend in this project is that the Enterprise Class nature of the project betrays a desire not to express any design opinion. In fact, the dominant design opinion seems to be "Anything is up for grabs"—you can perform validation in several different ways, you have your choice of several competing templating engines, you can map URIs to controller actions in at least three ways, and there are at least two (possibly more) mechanisms of accessing model data in templates.

The cost of all of this complexity exposes itself in two places. First, you have to decide (through coding standards or stumbling into a design you like) how to structure your application before you can get anything done. Second, you swim through a Styxian deluge of XML to configure (and reconfigure and modify and adapt and configure and reconfigure...) anything and everything.

(A plugin exists which nominally supports convention over configuration, but the lack of documentation and, apparently, interest renders it far too risky.)

I hesitate to blame too much the authors of the framework for this mess (and, as such, refuse to name the framework). Certainly some of their design choices reflect fundamental flaws of the Java language itself (in particular, Java's relative inflexibility especially with regard to its silly static manifest type system combined with the IDE-based tooling necessary to manage its verbosity and lack of abstraction make even programming in XML seem more flexible). Even so, the ceremony necessary to produce even the single CRUD steps of "Create an item and view it" involves editing multiple XML files, creating several Java classes, and—if you do things the Enterprisey way—creating and configuring subtemplates for the entire layout of the site as well as embracing the inversion of control object instantiation and initialization pattern (and given the unpopularity of the immutable object pattern in Java as compared to bean-style mutators, it's not easy to reason about the state of your objects) is damning.

The lessons for Perl are simple:

• Avoid the overcomplexity of projects by emphasizing the flexibility and simplicity of the language. Yes, you read that right. Meditate on it.
• Write better documentation.
• When the best way to do something changes, deprecate old documentation and point to the new approach.
• Emphasize simplicity. Make the default a good way to do most things. Provide comprehensive tutorials which explain the entire system using that effective default.
• Provide smaller upgrade paths and avoid big-bang incompatible releases which fork documentation and knowledge.
• Unify where possible.