|
|
|
| We don't bite newbies here... much | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
Firstly, was this question directed to code written in Perl,
or can it be applied to Perl's own code--the Perl interpreter? What's the recent metric posted on p5p, 80% of Perl's ~1.5 million lines of code hasn't been altered in 10 years? That means either Perl's perfect or nobody can change it without breaking everything else; which, incidentally would be a good working definition for "unmaintainable".
Most of the replies so far could be summarized as "learn Perl better". Sure a subroutine or two can be cleaned up so as to be "maintainable", sure you can just learn Perl quirks for all 170+ operators and contexts, sure you can quit endlessly rolling your own and use canonical CPAN modules, and sure you can learn to stop writing all your code as if it will be entered into a japh/obfu competition. But what about Perl's maintainability for serious Perl hackers who know all of those lessons cold? At what point do Perl hackers secretly wish they could flee to the Zen of Ruby? (We all know full well that those who've deeply drunk the Perl kool-aid are incapable of regressing to Java/C++.) But I jest! In my experience, it has seemed that Perl becomes unmaintainable once the code base reaches a certain size & complexity. From the grunt's view from the trenches, you'll start feeling The Pain somewhere between 50k and 100k lines. Beyond 100k, The Pain becomes Kill Me Now and your efforts come to feel as little more than bailing water with a thimble. So what is different about a 50k line Perl application compared to a 500 line script for some sysadmin task? What actually makes the code unmaintainable? Sure Perl forces you into using peculiar syntactic structures, some of which are cripling in hindsight, such as the ad-hoc OO, the manage-your-own-sub-args, the use-hashes-for-everything Golden Hammer anti-pattern, the sigil/reference line noise, etc. These do add up. And even if you establish an ideal initial design and standardize the way to implement each of these issues, you can still blow away all your strict rigor in design by stuffing a UNIVERSAL::AUTOLOAD into some piddly module somewhere which then forces you to do pass your args in a certain way in another module, and that choice forces you to do add other boneheaded code to all modules which subclass that module, then your problem is everywhere, etc, and you repeat this process for a few years until eventually you can't win fights with your own code and you can't change anything without breaking everything else. Even refactoring only makes it worse. And this code deadlock is the state of being unmaintainable. But is this Perl's fault? Or just your own dumb design decisions which encouraged the accumulation of The Bloat over time? Unfortunately, Perl's freedom is a double-edged sword, and over longer periods of time, the TIMTOWTDI principle will eventually lead to the the introduction of code which violates the standards of an ideal initial design, leading to the code deadlock. But the advantage Perl has over languages like Java, C++, Python, etc is that you can get more work accomplished in less time and with higher code reuse and less complexity. A 100k line Perl app would be equally horrible as a 500k line Java app. But that Perl app took 1/3 of the time to develop and performs just as well. So Perl is just as maintainable as any other language as long as you can enforce some kind of coding standards along with a proper and sufficient initial design. In reply to Re: Some thoughts around the "is Perl code maintainable" discussion
by Withigo
|
|