Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re: Some thoughts around the "is Perl code maintainable" discussion

by Withigo (Friar)
on Aug 15, 2007 at 09:41 UTC ( #632685=note: print w/replies, xml ) Need Help??

in reply to Some thoughts around the "is Perl code maintainable" discussion

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.
  • Comment on Re: Some thoughts around the "is Perl code maintainable" discussion

Replies are listed 'Best First'.
Re^2: Some thoughts around the "is Perl code maintainable" discussion
by BrowserUk (Pope) on Aug 15, 2007 at 10:26 UTC

    ++ to you and your reasoning. But ... there had to be one.

    The thing I don't understand about the 'size' argument (except which side of it girls really come down on :), is if (say), a 10k line app is maintainable. Then 10 x 10k line 'apps' are also maintainable. No?

    So unless you write huge monolithic apps where everything is intimately intertwined with codependencies on everything else--think COBOL programs with single, huge DATA SECTION; or FORTRAN 77 programs with COMMON blocks--then your 100k line app should ostensibly consist of (say) 10 x 10k line apps that communicate through clearly defined interfaces.

    So (with a nod to your reference to UNIVERSAL::AUTOLOAD which I've never used, but have seen (dire) reference to), 100k lines apps shouldn't exist (in any language) to become unmaintainable.

    Now I know people are going to say that it's unrealistic in a commercial world where needs change and grow over time, but I say no. If you cannot view and maintain your application, as a medium-sized app that uses several medium sized libraries or modules, then you did it wrong--regardless of what language you are using.

    That, in my opinion, is the biggest problem with perl itself. Although it is coarsely structured along fairly logical lines, av.c sv.c cv.c hv.c op.c etc. It is all compiled together into a single, humongous lump. Perl5x.dll/.so.

    I realise that this is a fact of history and the language used and programming practices at it's inception and on the platform of it's birth, but if those humongous individual C sources were each a subdirectory of related, small files that were compiled individually and linked to create import libraries.

    And if those were split along broadly functional lines--the infrastructure (memory management, IO, wrappers over POSIX); the parser; the interpreter; the built-ins--and compiled to separate dlls/sos, then the 1.5 million lines could be seen and treated as 5 or 6 x 250,000 line 'apps'.

    Would that make it more maintainable?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://632685]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2018-06-23 06:53 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.