Perl Makes You Cry Harder

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.