Warning. I’m ranting. I’m annoyed. I’m frustrated. You might want to put on your rant-proof galoshes before proceeding.
Ready?
Perl should be considered a Write-Only Language.
Code that is written in it is generally incomprehensible by anyone but the person who wrote it. It’s great for one-offs, quick simple jobs, and low-scope tools. But anyone who says it’s appropriate for an enterprise level application (and I mean anything over about a thousand lines) should be strung up, draw, quartered, glued back together, and shot into space.
The main problem is Perl is so weakly typed, it should be considered not to have any. That means that parameters passed to methods are not type-checked, and therefore there’s no way to tell if you’re calling a method correctly, except to see if the app blows up when you run it. Editors and IDE’s cannot magically determine that “such and such a method requires an integer, a string, and a hashmap containing such and such values. You’re doing it wrong.”
Because of this weak typing and lack of structure, Perl libraries become worthless. Let’s leave aside the fact that Perl OOP implementations are complete and total trash (OOP is designed to organize your data into object form, and stabilize how components are used, defining a rigid structure so that when you use the component, you must use it correctly). In the case of libraries, it’s impossible to use a library unless you understand how it works. Libraries are not self documenting, they don’t even have a standard method of organization. They’re just loose collections of Perl code, again, with very little defined structure.
Therefore, people who come along to maintain code after the first person has suffered the above fate has no clue how a method is supposed to work, unless the original coder documented it, or built in type checking in their code. I have seen NO Perl code that actively makes sure the parameters being passed in are of the correct type. At best, they make sure the parameter are not null. And if they’re super-advanced, they even use prototypes.
And yes. I am in the unenviable position of maintaining thousands upon thousands of lines of undocumented, badly maintained, incomprehensible Perl code. Yes, the developers could have documented, formatted, and put the code into a form that’s easier to maintain. But they didn’t, and to me that’s the languages fault, not the developers. A language should have some element of maintainability, and not require the programmer to make up for it’s inherent ambiguity. If it does, it’s doubling the burden on the programmer. They not only have to write the code, they have to document it, and make it maintainable.
In my opinion… Perl by its very nature encourages sloppy organization and unmaintainable code.
And now, back to the trenches.
About Dave Shevett
A wandering geek. Toys, shiny things, pursuits and distractions.
View all posts by Dave Shevett
I’m currently at the Lone Star Ruby Conference in a session on TDD.
@Matt – feel free to present my rant as evidence. In the interest of full disclosure, I’m actually a Java programmer with a PHP background 🙂
Well, yes.
People deride, e.g., Java, for being restrictive. But they completely miss that one of the major dimensions of functionality for a language is how easy it is for the next guy to maintain. (Or even for you, plus two weeks.)
Self-documenting code, formal structure, highly encouraged informal structure (Beans), type-safety — all of these lead to better coding practices, leading to ease of debugging (often) and improved readability.
You are on solid ground that Perl lends itself to “write-once” code. But my sense is that the Perl-way (as opposed to the Java or Ruby way) is squarely to blame for the vast sea of incomprehensible Perl code out there. Behind that I would put Perl’s constructs – similar to Python – as promoting poor design practices.
Strong typing causes more pain in reliability/fragility than in readability. For example, most of the Ruby I have written and read is highly readable – yet it is very much the dynamic language.
I just finished reading Martin’s Clean Code (great as a spring-training reinforcer). It occurs to me that we just don’t see such texts being written for the Perl community. Why is that? I mean…one certainly can write clean Perl code. This is where I tend to look at the Perl-way and challenge developers to take ownership of the problem.
I wouldn’t quite say that we don’t see books like that being written for Perl. Higher-Order Perl and The Perl Cookbook are two examples. They’re not about a particular programming methodology but they do try to promote by example more structured and disciplined coding practices.
Personally, I think the larger problem is that Perl was deliberately designed from the beginning to allow programmers to do reckless things like what Dave describes, and for a long time the Perl wizards were reluctant to criticize people on the basis of style. I think that’s less true than it used to be but the damage has been done.
I’m also working with a rather large Perl codebase (our automated test infrastructure), and I count myself fortunate that nearly all of it is well-structured, intelligently formatted and documented (enough so that the small pockets that aren’t so really stand out). This is in part because we have strict coding standards and documentation requirements (for all of our code, not just Perl), but I think another factor is that we don’t have any code ownership in our development process. This means that everyone is at some point maintaining everyone else’s code, so there’s a strong collective interest in keeping it maintainable.
This is not to argue with your rant, of course. No language makes it difficult to write crap code, but Perl does seem to encourage it more than most.
One can write awful code in any language. Just because a language gives you an OO implementation you can’t ignore doesn’t mean it helps you write good code. I’ve seen way too many ObjectAccessorGeneratorFactory style classes in the Java I’ve had to work with.
Most of the Perl codebases I hear people ranting about were written without any time or budget allocated to design, architecture, testing or even requirements gathering. Whatever it was, it was already late and management needed it NOW. It’s no surprise that when these things get rewritten with 5-10 years of field experience, proper requirements gathering, budget and a dev team with some technical leadership, they come out better than that thing that two guys put together in their spare time in 1997. It doesn’t matter if the new implementation is Python, C# or Intercal.
Like every other language in common use, Perl has come a long way in the past decade. If you haven’t already done so, it’s worth having a look at Moose, a modern, proper implementation of the MOP for Perl that provides the sorts of structure and constraints I expect you’re looking for. If all you want is to enforce constraints on parameters being passed, you’re looking for Params::Validate. Also, it’s worth noting that prototypes don’t actually have anything to do with method calls. Their primary reason for existence is as parser hinting for certain kinds of functional programming.
Skewering Perl for having dynamic dispatch and weak typing is a little disingenuous. It’s a Dynamic Language. So are PHP, Ruby and Python. They all share this attribute.
None of this will magically improve the bad code written by untrained programmers with bad habits and poor technical leadership you have to work with. But I can guarantee you that if it were written by an equivalent Java, C or Python team at the same time, you’d be just as frustrated with the code base and your tools would be just as ineffective at undoing the mess they made.