Modern Perl: Are You A Dedicated Follower Of Fashion?

jared recently took considered - if mischievous - aim at the Modern Perl crusade:

A recent post from chromatic was the inspiration:

I'd go further.

No amount of automation, source control, testing, Moose or peer consensus will help unless you understand the problem at hand. And the pure fact is your understanding will change the more you work on the problem. Worrying about maintainability will widen your concept of your problem and make it more difficult to solve. Perhaps this is justified (what little empirical evidence there is suggests that re-usable code takes 3x as long to develop as code that is not consciously designed to be re-usable - see "Facts And Fallacies of Software Engineering" by Robert Glass) but even if it is exactly what can you assume about the future needs and skills of any others who pick your code up?

To crudely paraphrase Feynman - If you solve a reasonably complex problem after many hours, days or months, why should someone else expect to pick up the code and understand it in 5 minutes?

Work hard, research with an open mind, think about what you are doing and the limitations of what can be done, and you may end up with code that will be judged kindly.

In the meantime - if you want to increase your success rate - double your failure rate.


I face the temptation to write a lengthy response focusing on the use of the word "crusade", but I doubt enough people would understand the intentional irony.

Instead let me counter with my own experience: writing without maintainability (don't conflate that with writing for reuse or premature reuse) in mind is an excellent way to produce code which is difficult to maintain regardless of your improved understanding of the problem.

I am happy to provide voluminous code examples upon request.

Yeah, it's more difficult to write maintainable code, but it's worth the cost. Saying that writing maintainable code (intentionally) is too much of a burden to the programmer is ... incomprehensible. Maybe it's 3x harder, but the product is far more valuable.

Paradoxically, when you say "Work hard, research with an open mind, think about what you are doing and the limitations of what can be done, and you may end up with code that will be judged kindly. "... You are trivially close to simply saying "Code for maintainability." Working hard, doing your research (CPAN?), thinking about the problem and limitations of future work is coding for maintainability. Add in "try to use community-accepted standards and practices where possible" and you're there.

For one I don't work in an environment where 6 months effort will be tolerated when 2 months will fulfill requirements.

Understood, everyone's situation is different. I happen to work in an environment where months of my time are spent maintaining, refactoring, and replacing code written by people who had no concern for maintainability. These were largely graduate and undergraduate students who seem to have decided that as long as the system works until they graduate, that's all that matters. Having those experiences gives me a different perspective on the need to give some consideration to maintainability.

My beef is this: Any talk which states this or that will enhance maintainability assumes there is a clear quantifiable definition of what maintainability means.

I think then, we have an understanding. It's probably wrong to simply say "You must enhance maintainability, and X will accomplish that."

I was thinking more about people who ask, "How can I enhance maintainability?" If someone wants to know, what do we tell them? I assumed you were saying "You must say nothing, there is no correct answer," but it seems now you were saying "You must be careful what you say, as it may or may not be applicable in a given situation."

Always think for yourself, and reject dogma. That, I can comprehend. The problem is discerning between dogma and best practice, and having the experience to understand when best practice applies, and when it does not.

In “No Silver Bullet” Brooks based his argument on Aristotle’s classification of complexity into essential and incidental. Applied to maintainability the trouble is that introducing concerns about maintainability into the problem at hand increases the incidental complexity.

Fortunately Brooks is not dead yet, otherwise I believe that this would set him spinning in his grave: it is completely backwards!

Brooks’ argument is precisely that productivity improves by the excision of incidental complexity. Productivity on the scale that Brooks is talking about – the OS/360 project he led, f.ex. – most certainly is a superordinate concept to maintainability: you will quickly get bogged down as the code base grows if you do not maintain discipline in initial development.

Now in application to Perl: using declarative syntax for OO (as in Moose) and formal parameters (as in all the Devel::Declare-based stuff) is certainly an excision of incidental complexity compared to the use of raw hashref objects and unpacking of @_.

Leave a comment

About mrstlee

user-pic Is it just me or is perl too much fun to be shared with the unworthy?