Month: August 2008

Slashdot is linking to an ONLamp.com article, Why Corporates Hate Perl. I think it’s interesting that while zealots exist for every language, you rarely encounter the kind of vehement hatred for a language the way you do for perl. Which probably just fuels the antagonism in both directions.

Many Slashdot comments point out that the requirements specific to corporate environments are rather idiosyncratic. Some stress the “right tool for the job” philosophy, which I totally agree with.
And here’s one that makes a wonderful characterization about what perl is and is not:

The problem is, Perl is just a programming language, not a conceptual system. Arguably it is the antithesis of a conceptual system. Many teams then create their own application frameworks atop it (e.g. Mason, POE), and it’s rare for these frameworks to be compatible since Perl offers so many variations in the construction of even standard programming artifacts like classes & objects.

In addition, the level of expression (i.e. TMTOWTDI) means in practice that highly varying programming styles occur throughout large, long-lived bodies of code.

As a result, significant Perl-based business applications tend to become hard-to-maintain hairballs of divergent style and subtly variegated concept.

The root cause: as I started with; the absence of a standard conceptual framework for Perl means that during the early phases of a project, it’s much harder to reason meaningfully about the eventual form of the system than it is with, say, Java or .NET where many of the design patterns are explicitly standardised.

I wouldn’t say that “Corporates Hate Perl”. It’s just the Perl as an application language doesn’t suit the formal design & architecture process we’re seeing increasingly as IT departments start to grow up and realise that they’re not the most important people in the company.

That doesn’t disqualify Perl from being a useful tool, and it’ll always have a place in data transformation, but it does mean that Perl isn’t going to be one of the general-purpose application programming languages of the future.

Bravo. I’d add that what the author identifies as a “problem” is also Perl’s strength. There’s more than one way to do it, so do it as you please. That definitely has allure for many programmers. As a project scales up, though, I think this does in fact become a detriment, and not only for corporate projects.

In response to someone who wrote, “chomp is not ambiguous. RTFM and stop crying,” here’s another awesome comment:

http://perldoc.perl.org/functions/chomp.html [perl.org]
This safer version of “chop” removes any trailing string that corresponds to the current value of $/ (also known as $INPUT_RECORD_SEPARATOR in the English module). It returns the total number of characters removed from all its arguments. It’s often used to remove the newline from the end of an input record when you’re worried that the final record may be missing its newline. When in paragraph mode ($/ = “” ), it removes all trailing newlines from the string. When in slurp mode ($/ = undef ) or fixed-length record mode ($/ is a reference to an integer or the like, see perlvar) chomp() won’t remove anything. If VARIABLE is omitted, it chomps $_ . Example:

If anything I’m crying harder after reading that.

Amen, brother.

I’ve always thought Javadoc was one of the best features of Java. The Javadoc pages for the core API are invaluable for finding what I need very quickly. The utility can be run on any Java source files to generate a nice set of HTML pages that gives you a thousand-foot view of packages, classes, members, and method signatures. Nothing special or extra is required. Of course, you’ll often want to add comments and descriptions and that’s done by following commenting conventions that Javadoc can recognize and insert automatically into its HTML output, but you don’t need to do this for Javadoc to work.

Python’s docstring conventions are not quite as elegant, in my opinion, but they work just as well. Documentation is so much more important in a dynamic language like Python because unlike Javadoc, the pydoc utility can’t determine types. So if a parameter for a function or object method is “user,” one needs to know whether to pass in a User object, a username string, an integer id… or whether any of those will work.

Both Python’s docstring and Javadoc let you document as-you-go, eliminating or reducing the need for documentation as a separate task. If you change something, the documentation is right there for you to update.

Perl’s POD format isn’t nearly as convenient. The markup is oriented more towards layout and formatting rather than following the structure of the code. You can write section headers, indent, and list items in the documentation, but you don’t really attach them to subroutines or methods. Well, you can, sort of, with “=item” but each item must be nested inside other markup, and it feels kludgey and weird. The consequence is that the documentation feels really much separate from the code, even if it resides in the same file. It doesn’t encourage documentation as you go.

In the perl project I worked on, I wrote some POD comments in the very beginning but it fell by the wayside. I should have kept up with it, but it felt like an extra thing to do. My client’s taken over the code, and he’s spending time reading a lot of code to figure out what the parameters should be for various calls. In a dynamic language, there’s no easy way around this if there’s no documentation. Plus perl’s subroutine syntax can make it very difficult to decipher parameter lists quickly. It’s frustrating. I can’t really blame Perl for my own failure to write extensive documentation, but I must say, the idiosyncrasies of POD don’t exactly make it easy.