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.


As an early adopter of Java, I thought "A rising tide lifts all boats". That's the secret of Java, it has momentum and popularity. The Java advocates hardly ever stop to figure that all the interesting work with Java is being done with a hodgepodge of pseudo-dynamic languages and not-that-Java reflection .

Beans? Reflection. Tag libraries? Reflection. JSTL? Reflection. Juice? Reflection. Web application from my last Java job? Reflection. Neato translation queue from the same job? Reflection.

What you said kind kind of triggered my recognition of XML being the unofficial dynamic language of Java. It's no wonder that Java had to develop a dynamic language interface.

I guess that's one thing we Perlers can be clear about, we don't go around pretending that dynamic is bad, and then "inspire" others to seek text-driven solutions to Java silos.

> 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"...

Wait. Isn't "anything is up for grabs" essentially the Perl way -- aka TIMTOWTDI? Are you saying that's not a good idea? ;)

On the surface, that looks like a contradiction, but the domains of language design and framework building are different.

A language is a toolkit with which you can assemble frameworks.

A framework is an opinion with which you can solve problems.

Once a framework ceases to save you time or effort, why use it?

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on April 1, 2011 10:18 AM.

Translations of Modern Perl: The Book was the previous entry in this blog.

Beans versus Immutable Objects is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?