Modern Perl: Are You A Dedicated Follower Of Fashion?
jared recently took considered - if mischievous - aim at the Modern Perl crusade:
http://curiousprogrammer.wordpress.com/2010/07/29/does-your-perl-suck-if-you-dont-use-moose
A recent post from chromatic was the inspiration:
http://www.modernperlbooks.com/mt/2010/07/a-checklist-for-writing-maintainable-perl.html
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.
Is it just me or is perl too much fun to be shared with the unworthy?
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.
How far do you go with keeping maintainability in mind when you code? Who do you keep in mind? The neophyte, the competent, or the battle-scarred veteran? Or is it possible to satisfy the needs (How do you define what they are?) of all?
The problem is that maintainability cannot be proved a priori, only in retrospect. To say that a particular convention, module, or practice will make your code maintainable without any form of quantitative evidence places the argument in the sphere of opinion. Or, to go put De Bono's hats on for a moment (http://en.wikipedia.org/wiki/Six_Thinking_Hats), is Red Hat thinking. Which is fine, but where is the White Hat?
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. Whether or not it is always worth the effort is by no means a one-sided argument in a commercial environment with tight deadlines.
Software Engineering as a practice has been around over 40 years now. In that time many have tried to solve the maintainability problem. The fact that people are still trying indicates that there has been no solution found so far. With a Red Hat on I don't believe the problem can be solved since the problem is so difficult to define objectively. In fact there is no single definable maintainability problem.
So what can be done? The principles of good system design haven't changed - all that's needed is years of thought and effort in to putting those principles into practice. You'll never get it completely right but as I heard one battle-scarred vet say to skeptical colleagues - the big advantage of perl is that it lets you make your mistakes quicker.
It is not so straightforward I think. For one I don't work in an environment where 6 months effort will be tolerated when 2 months will fulfill requirements.
"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"
Ok, my fault but that's not really I meant (not that you could have known). For one thing I meant research in a broader sense - for example read about the Halting Problem, functional programming, read "No Silver Bullet", "Godel, Escher, Bach", and "The Structure And Interpretation Of Computer Programs".
Nor did I say you shouldn't bear in mind the future when designing and building a system. Inevitably you will, particularly as you gain experience, but ask yourself how far ahead can you profitably look? There is a cost to be taken into account which has to be weighed against very-difficult-to-impossible-to-quantify alleged maintainability benefits.
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. Otherwise you can't state what the benefit is without resorting to the equivalent of "Well, it's obvious", or, "That's what I think". Does anyone have such a definition?
There is too much dogmatism in soft dev circles, whether it qualifies as community consensus or subjective assessment. It can, and should, be questioned.
Well, that's my subject assessment anyway.
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.
The problem is discerning between dogma and best practice, and having the experience to understand when best practice applies, and when it does not.
Nicely put.
I sympathise on the grad front. Been in the same position. It bugs me - an organisation invests millions in a software system and then lets people with minimal if any experience monkey around with it.
Seems to me part of the problem is due to a lack of management appreciation of just how complicated soft dev is. You want good software in good time you need good people, not more people.
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
@_.AB? I think not.
Developing with maintainability concerns in mind can only increase the problem space beyond the narrower confines of a particular development exercise. Increasing the accidental complexity of the problem in other words. The question I posed is whether it is possible to assert that the increase is always worth the effort.
The argument goes beyond mere syntax but since you brought it up - Brooks asserted (who said he was dead btw?) that no technological advances would bring an order of magnitude increase in productivity. This was at the time OO was starting to go mainstream. As far as I know no one has since said he was wrong. Meaning any contributions Moose's declarative syntax can make are limited to less than any increase due to use of OO (If any. Where is the evidence?).
In practical terms - you may not like writing
my ($self,$arg1,....,$argn) = @_;
but how much of a burden on maintainability is it?