http://qs321.pair.com?node_id=631776

Yesterday I was reading one of cromatic's post on perl.com and the comments that followed that post. The post got me thinking about what is the reason that people make the assertion that "Perl code not maintainable"?

Though the most often cited (and in my opinion superficial) reason is that the syntax is hard on the eyes, I think it can have more to do with the TIMTOWTDI philosophy. Before everyone starts flaming me please read my argument through :)

For a large number of programmers/software developers, making software is a job and nothing more. It is not their hobby and they do not use their spare time to develop their skills and to read up on the latest tools and programming gizmos. They are generally satisfied if they have solution that works fairly well. They are not looking for the optimal technical solution, only something that gets to job done. (this premise may of course be wrong, I have not data to support this claim. It is just something that fits with my personal experience.)

BTW I don't think it is anything wrong with just viewing programming as a job. I fully understand that people don't think programming is as fun as I do.

So lets say we have a Perl shop with two of these average programmers, Sally and Bob. They work on different projects and for some reason they do not talk to each other that much. Sally was a Java developer and she has read Perl Best Practices so when she wants to create objects she wants the attributes to be private. For that reason she uses inside-out objects. Bob however has read the perldoc perlobj tutorial so he just uses blessed hashes as objects. Then Sally gets sick or she quites or whatever and Sally's project becomes Bob's responsibility. When Bob looks at Sally's code he doesn't understand it. For him it is voodoo code. I don't dare to touch it because that might break something, he thinks. Why, oh why didn't she use blessed hashes? wonders poor Bob.

Now the problem in this example is not actually Perl, but that Sally and Bob did not talk to each other and decided upon a standard way of creating classes. However it is the TIMTOWTDI philosophy that makes this a problem. In a language like Python or Java there is a standard syntax for creating classes (it is possible that there are none standard ways as well, but I am not aware of them) and this removes this problem. The language designers have already taken the choice of how classes should be constructed and taken that decision away from the programmer. For a hacker this might be a bad thing, however for the average programmer it simplifies their job.

So for someone that does not know Perl well it might seem like it is the language that is the problem while in reality it is the lack of conventions that is the real problem. It is my impression that languages like Python and Java have much more standard conventions and they therefore seem more maintainable.

I am not saying that the TIMTOWTDI philosophy is a bad thing or making any assertions that "Perl code is not maintainable". I have no data to support such claims. I am just presenting an idea of why people might find Perl code hard to maintain.

Well, it is just a thought. I might be completely wrong about this. You can let the flaming begin now.

Replies are listed 'Best First'.
Re: Some thoughts around the "is Perl code maintainable" discussion
by Mutant (Priest) on Aug 10, 2007 at 13:35 UTC

    I don't think your example (or even your problem) has anything to do with the language, or the way it's used. Your example would be exactly the same if two Java programmers worked on the same code base, and one of them used Spring, but the other had never seen it.

    Not being interested in programming outside of work is no excuse for doing a poor job. As part of being a good programmer, you should keep up with the latest technologies, methodogies, techniques, etc. These things change very quickly, and if you don't keep up, you will be left behind.

    If you really don't care about keeping up, that's fine, but you will never rise above the rank of code monkey. Any organisation who wants quality code should make sure they don't have code monkeys in charge. It's ok to have them on board, but they need to be working under the guidance of senior, experienced developers, who have a good understanding of various development practices (e.g. some degree of Pair Programming would have prevented the problem you describe occurring).

    Even beyond that, a good programmer should have no problem reading, understanding, and changing code that's at least written to a reasonable standard, regardless of whether they'd seen code written in that style before, or even in that particular langauge.

    The main reason why Perl has a reputation for producing poor code is the following logical fallacy:

    1. Perl has less restrictions built into language than other popular languages (e.g Java, Ruby, etc), therefore:
    2. It's easier to write unmaintainable code in Perl, therefore:
    3. All Perl code is difficult to maintain

    Basically, people assume that because Perl hold's the programmers hand a lot less than other languages, that there's no way anyone other than a genius can write good code. (TIMTOWDI is part of that, the specific merits of which are a completely separate discussion, IMO).

    Hand-holding might be fine for some people, but as I outlined above, you will never get good quality code without some experienced, capable developers around. (This is not just my opinion either, many have written about it in the last few years). These types of programmers do not need their hands held. In fact, they much prefer full flexibility, because they're in a much better position than the langauge to decide when they should use some part of the language that can be dangerous. They can also be the ones to hold the hands of their junior devs / code monkeys, again replacing the language. Surely they're going to be able to do a much better job than a language designer who has no idea what the problem domain is, the various skills of the dev, etc. etc.

    In the end, programming langauges have never been, and should never be, one size fits all. A lot of the Perl sniping boils down to just that: people don't want to have to learn something new, beyond what they already know well, so they wish less mainstream things like Perl would just go away. Sometimes hand-holding is good, sometimes it's going to make life difficult. It's good to be able to choose.

    So basically, no, I don't think TIMTOWDI is anything to do with Perl neccessarily producing unmaintainable code. It's just another argument that's raised (along with regexes, dynamic typing, flexible OO, etc.) by people who've never worked on a well-run Perl project.

      Thanks for a well-written reply. I think you make the point I was trying to make better than me.

      The point I was trying to make was not that TIMTOWTDI is a bad thing and that it is the reason for unmaintainable code. Just that it might appear to be the reason for unmaintainable code to someone that is not proficient in the language. The problem is not the language, but as you point out poor programming practices and the quality of the developers.

      Well any way the post was just an attempt to structure some thoughts I got from reading the discussion I mentioned.

      I totally agree that the merits of TIMTOWTDI is a different discussion.

Re: Some thoughts around the "is Perl code maintainable" discussion
by dogz007 (Scribe) on Aug 10, 2007 at 19:01 UTC
    I believe that the problems of unmaintainable Perl code have less to do with individual programmers who collaborate on projects than the lack of company-wide standards of the organizations that employ them.

    For example, I'm an engineer, and when we make drawings at my company, we follow a template. Object lines are white, hidden lines are green and dashed, center lines are red and dashed differently, and dimension lines are a girly pinkish color that print with slim, slender lines on paper. Of course anyone can make drawings in any color they choose (TIMTOWTDI), but if I went to work on Monday and screwed with the colors in my drawing, all the other engineers that work on that drawing will get awfully confused, and I'll hear about it all day. So you see, it has less to do with our drafting software than with company standards.

    This is directly analogous to the Perl maintainability issue. Had Sally and Bob been trained to at least agree on a set standard for creating objects, then the communication issues (which maintainability really boils down to) would have been minimized. In fact, I believe that Perl's boast of TIMTOWTDI opens up the field for Sally and Bob to seek methods of coding optimized for their specific projects and to choose the best option to use as a standard. Indeed, this even smells of Continuous Improvement, which I'm sure my Industrial friends are sure to enjoy.

    I do not believe that these standards should be set by the creators of the programming language. The rules of the language should be open enough for any programmer to choose their own favorite method of coding. That's why I chose Perl in the first place. When I learned that I didn't have to declare variables if I didn't want to, it was like love at first sight. But don't think for one instant that I let my variables run amuck without clearly defined scope, like digital free radicals in a pristine body of code. It's the freedom to choose that was, and still is, most important.

      ... then the communication issues (which maintainability really boils down to) would have been minimized.

      All of my attempts to contribute to the meat of this thread are as nought as compared to the contribution of that single phrase, indeed just the parenthesised part of that phrase, though the context is helpful.

      I learned a while ago, somewhat less than 5 years, and entirely as a consequence of coming to this place, that it is always a good idea to review each communication to which one has contributed, at least several hours after one contibutes. And often again, a few days after that. I have often been surprised by the affect the later contributors had upon my opinions, but never more so that right now.

      As a complete aside, you deserve a whatever 'the poetic prose equivalent of a booker prize' is, for "... like digital free radicals in a pristine body of code.". And the fuddy dudies think that poetry reached its zenith with the Bard.


      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.
Re: Some thoughts around the "is Perl code maintainable" discussion
by chromatic (Archbishop) on Aug 11, 2007 at 05:05 UTC
    It is my impression that languages like Python and Java have much more standard conventions and they therefore seem more maintainable.

    But neither Python nor Java has interesting standard conventions that prevent interesting maintainability problems!

    You can always, always, always look up syntax in a language reference. Always.

    You can't always look up why another coder used a particular algorithm or what a poorly-named variable signifies.

    It's time to reject the idea that maintainability has anything to do with syntax (spend $40 on a language reference already!) or formatting (use a pretty printer!) and consider that maybe, just maybe, it's all of the creative work of writing programs that can get us into trouble.

    Update: TimToady said s/maintainability programs/maintainability problems/.

      But neither Python nor Java has interesting standard conventions that prevent interesting maintainability programs!

      Sorry, I did not understand this sentence. Could you elaborate a bit more?

      It's time to reject the idea that maintainability has anything to do with syntax [...]

      I do agree with you that people should stop focusing on the syntax when discussing languages. As you have pointed out (above and in other posts) there are other things that are far more important when it comes to maintainability. However saying that syntax does not have anything to do with maintainability is too strong in my opinion. In my opinion the syntax of the language does matter. I am fond of the following quote by Alfred N. Whitehead that says this better than I will be able to do:

      By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and, in effect, increases the mental power of the race. Before the introduction of Arabic notion, multiplication was difficult, and the division even of integers called into play the highest mathematical faculties.

      For example would not the creation of domain specific languages be an example of that syntax/notion matters? Take pattern matching for example. We could express pattern matching directly as finite state machines with states and transition, but the notation for doing so is cumbersome. So instead we use regular expression that are much more expressive, but can be automatically translated into an equivalent state machine. This makes our programs easier to read and to maintain.

      That being said, I do wish people would stop focusing on syntax when discussing languages. There are far more interesting and important properties to discuss.

        Sorry, I did not understand this sentence. Could you elaborate a bit more?

        Suppose someone names all of his variables and functions after the titles of Led Zeppelin songs. How does a language prevent that? Yet it's a maintenance problem.

        Suppose someone refuses to use built-in aggregate data types and rolls his own. How does a language prevent that? Yet it's a maintenance problem.

        Suppose someone refuses to use built-in string handling functions and rolls his own. How does a language prevent that? Yet it's a maintenance problem.

        Suppose someone has a program which watches the commits and reverts all changes to a section of code he feels that he owns. How does a language prevent that? Yet it's a maintenance problem.

        Suppose someone has a penchant for writing long, long functions because "the overhead of setting up call frames is too much for this critical path" and you end up with thousand-plus line monsters. How does a language prevent that? Yet it's a maintenance problem.

        Suppose someone writes a god object and couples it to the internals of every other object in the system. How does a language prevent that? Yet it's a maintenance problem.

        In my mind, all of these problems are much more important than "Wow, I've never seen that particular bit of syntax before", but somehow people get caught up on the idea that syntax and idioms matter more.

        For example would not the creation of domain specific languages be an example of that syntax/notion matters? Take pattern matching for example. We could express pattern matching directly as finite state machines with states and transition, but the notation for doing so is cumbersome. So instead we use regular expression that are much more expressive, but can be automatically translated into an equivalent state machine. This makes our programs easier to read and to maintain.

        I think maybe you are confusing the abstraction with the syntax of the abstraction.

        The presence of lack of an abstraction can have a dramatic effect on maintainability. The syntax used to express the abstraction has a far lesser effect.

        In JavaScript you can create a regular expression in a Java like re = new RegExp("\\w+") fashion or a Perl like re = /\w+/ fashion. In Perl6 you will be able to select between Perl5 and Perl6 (and maybe other) syntaxes for the expressions them selves. One form might be easier to write or read than the other, or a programmer might know one form and not the other, but any form existing in a language negates the need to program a state machine to do simple (and possibly complex) string matching.

      It is _not_ time to reject the idea that syntax affects maintainability. When you buy your language reference note how many ways there are of doing things; how many special cases; how many themes. Too many increases the chance that the other persons code is written with themes and idioms that the maintainer is not familiar with. How much does the community advocate machine generated code? Or elevate code obfuscation? They can lead to a culture of poorly written code being O.K. or even cool. Syntax and community have a lot of influence on maintainability of code! - Paddy.
        Too many increases the chance that the other persons code is written with themes and idioms that the maintainer is not familiar with.

        Why does your organization not have coding standards?

        Why are you not performing code reviews of some kind?

        Why are you hiring maintenance programmers without sufficient language experience or at least sufficient training in your organization's coding standards?

        You betrayed your own argument when you said "poorly written code". How can you even identify code quality without these things?

        If your maintenance programmers can't handle the style of syntax your organization uses, I can't see how they have any hope of handling the interesting problems of maintainability.

Re: Some thoughts around the "is Perl code maintainable" discussion
by renormalist (Sexton) on Aug 11, 2007 at 09:49 UTC

    As many others already said, it's probably not the TIMTOWTDI that's different to other languages. The difference IMHO is the culture of celebrating that kind of freedom, that scares other people.

    And it's a pity that even in todays colorful times most source code has to be shown without syntax highlighting, newspapers, books and even blogs mostly show it black/white.

    If there would be more syntax highlighting then people would see how much more expressive and more readable Perl code can be compared to other languages which just don't have the syntactic richness to express different things differently and therefore are not able to color them accordingly.

      I totally agree on the importance of syntax highlighting. While code should arguably be readable without it, it makes reading far easier.

      That's why I even built my own offline CMS which handles syntax highlighting via Text::VimColor.

      Having regexes built into the language (rather than having a library which generates them from stings) makes it possible to do syntax hilighting for regexes.

      syntax highlighting is fantastic, and yet i've never seen an editor get it right for perl.

      i've got a number of source files littered with #'#fix vim highlight to give hints to the editor that, no, s|'|"|g; is not the start of a runaway string.

      only perl can parse Perl is the usual mantra. most software can't do it -- no wonder humans have trouble, too. ;-)

        yet i've never seen an editor get it right for perl

        I've been more than happy with emacs's cperl-mode (and mostly happy with perl-mode) syntax highlighting. So IMO emacs gets it right.

        syntax highlighting is fantastic, and yet i've never seen an editor get it right for perl.

        Yep, but then I bet that even perl, which can properly parse Perl, would have some difficulties syntax-highlighting certain kinds of code in a meaningful manner. OTOH most smart enough editors do a decent job on most reasonable and common code. Sometimes you have to trick them or help them in some way. Mine not only helps me with SH, but also does automatic indentation etc. but again in some cases it gets it wrong, e.g. with

        local ($,,$\)=("\n") x 2;
        In this case the closing parenthesis is seen as quoted, and this screws up the following lines of code. Of course using
        local ($\,$,)=("\n") x 2;

        instead prevents the problem, and is also clearer a priori, but it was just to come out with a reasonably "real" enough example.

        Similar situations when here docs are included, even more so if they actually contain code. Then, in the rare situations in which I need to do a string eval, I prefer

        q{ ... }; # or qq{ ... };

        Over simple quotes, since then my editor won't recognize them as strings, but mistake them for code blocks, which is fine in this case. The Right Thing™ would have been... ehm "wrong" in this case.

        In some regexen like the one you mentioned, I overquote inside the regex, just not incur your same problem.

        Oh, and as a minor point, comments are only recognized if there's some whitespace on the left of #. So I always include some, but that's not a big harm since I consider it a good practice anyway. OTOH when I have to comment out big portions of code I use the "indent region" function of the editor itself, which is a big help especially in connection with its "unindent region" companion.

        One thing that is occasionally annoying is the confusion between "multi line" anonymous hashrefs and code blocks: to cope with that I often put parentheses instead, that I substitute with curlies later. Not terribly hard, but... well, annoying.

Re: Some thoughts around the "is Perl code maintainable" discussion
by GrandFather (Saint) on Aug 11, 2007 at 10:51 UTC

    If something is a language in any real sense of the word then it must be capable of TIMTOWTDI - otherwise it is only capable of expressing exactly one thing in exactly one way. A language can not constrain articulation of it to a single expression of it. Any language allows circumlocution and shades of gray, even formal languages such as computer languages. For example, the following two expressions are equivalent (in most languages), but one is likely to provide a little more resonance than the other:

    (2 * 60 + 15) * 60 + 5 8105

    Despite no variable names, or any other context, the first expression provides a strong clue that hours, minutes and seconds are involved. But if TIOWTDI then only one expression would be allowed wouldn't it?

    The point is that TIMTOWTDI allows the freedom to express it in the way that allows some appropriate combination of ease of understanding, ease of maintenance and efficiency. The appropriate balance can often only be reached by considering a much larger picture that the implementation language is capable of dictating.


    DWIM is Perl's answer to Gödel
Re: Some thoughts around the "is Perl code maintainable" discussion
by syphilis (Archbishop) on Aug 10, 2007 at 12:41 UTC
    Hi oyse,

    TIMTOWTDI is a terrible thing. You finally get something working ... and then spend the rest of your life wondering whether there's a better solution.

    Otoh, TIOWTDI would mean that once you have found a solution, you have found the best possible solution (as there is only one solution).

    As a statement of fact, there's no doubting the truth of TIMTOWTDI, but I've long wondered about the presentation of TIMTOWTDI as a "selling point".

    I guess the value of TIMTOWTDI over TIOWTDI is the implicit notion that if TIMTOWTDI, then you stand a better chance of finding a solution (at least under the laws of probability :-)

    Cheers,
    Rob
          Otoh, TIOWTDI would mean that once you have found a solution, you have found the best possible solution (as there is only one solution).

      by this logic, this is also the worse possible solution also!

      But I agree with commenters who say that there's not such a real-world language with only one solution everywhere.
      but languages having more TIMTOWTDI freedom give more freedom to programmer, but sometimes this freedom is not good, like in example by OP.

      TIOWTDI would mean that once you have found a solution, you have found the best possible solution

      There are a couple of things that jump out at me here and scream bullshit.

      1) There's no such language where there is only one way to do things. You can always do things multiple ways, unless your knowledge of the language is limited to copy-pasting code. There's usually more than one algorithm to accomplish some task. For example, sorting -- is there only one way to sort in these supposedly TIOWTDI languages? I'd hope not, because they have no way of knowing the best possible sorting algorithm for your particular problem. (On the other hand, maybe that's the sacrifice you make for an easier to use system?) Even if there's a sort function that supposely solves all sorting the best possible way, there are some people who will use the language to badly reimplement a quicksort, etc..

      2) Assuming there was only one solution, do you really want to limit yourself to it? What happens when your application starts bogging down, do you just throw your hands in the air and say "well, it can't possibly be done better, since there is only one way to do everything"?

        There are a couple of things that jump out at me here and scream bullshit

        Well ... when one speaks with tongue firmly planted in cheek, there's always the risk that some observers will see only "bullshit".

        Still, it surprises me that you saw even one (let alone two) elements of "bullshit" in the statement "TIOWTDI would mean that once you have found a solution, you have found the best possible solution" - because, to me, that statement is tautologically true ... and you surely can't get a truer "true" than a tautological one.

        There's no such language where there is only one way to do things

        Agreed. And one therefore wonders why we perlers bother to mention the TIMTOWTDIness of perl - given that every other language offers exactly the same.

        Assuming there was only one solution, do you really want to limit yourself to it?

        Ummmm ... "assuming there was only one solution" would you have any choice other than "to limit yourself to it" ?

        Cheers,
        Rob
        There's no such language where there is only one way to do things.

        Well, not really: neither at the single statements and expressions level, nor at the "bigger picture one". But some languages push this "additional degrees of freedom" thing further than other ones: certainly Perl is a winner in this game. It's just a philosophy. Just like breeds of beer, it may fit some people and disgust others. So there's an opposite philosophy: TIOWTDI, which is of course limited in realizability since as you correctly say there can't be only one way to do it in the absolute sense of the word. But speaking of existing languages, Python is well and mostly known to outsiders for forcing indentation. And I remember clearly that at some point a specific feature of it was removed acrosse a release change because there was already another way to do the same, and that had to be the "official" one. Unfortunately I don't know it enough to give more details...

Re: Some thoughts around the "is Perl code maintainable" discussion
by Tabari (Monk) on Aug 13, 2007 at 11:53 UTC
    If Bob and Sally had been doing code review, part of the lack of informal communication might have been mitigated. It all boils down to company organisation and standards, not language.
    Tabari
Re: Some thoughts around the "is Perl code maintainable" discussion
by paddy3118 (Acolyte) on Aug 12, 2007 at 07:42 UTC
    (Big thank-you guys for an interesting and non flame series of posts. I do realise that I might have unpopular views, but I've tried to be polite and you've responded in kind).

    perlmonks++
    - Paddy.
Re: Some thoughts around the "is Perl code maintainable" discussion
by Withigo (Friar) on Aug 15, 2007 at 09:41 UTC
    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.

      ++ 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.
Re: Some thoughts around the "is Perl code maintainable" discussion
by dwm042 (Priest) on Aug 13, 2007 at 14:36 UTC
    Just my own two cents, but languages with richer operator and function sets tend to get the reputation for being "harder to maintain". Back in the days when Pascal was just out and cool, I heard arguments about how hard C was to read and maintain. C was a language richer in operators than Pascal and someone going from Pascal to C would have to go through the learning curve of dealing with the larger set of operators.

    If you need a simpler example of this in operation, think APL.

    When I asked a friend once why they chose Python for a development project, one comment in passing was that they could write Perl that they themselves wouldn't understand 3 months later. What this says to me is that as code grows complex, more effort should be spent in simplification and documentation.
      The main problem with C before ANSI-C was the lack of standardisation. Portability was an added burden, especially when several of the C compilers had their own methods of allowing mixing in assembler code. For me, ANSI Standardisation was wonderful, and allowed me to move from Pascal to (ANSI), C as my preferred programming language.
A reply falls below the community's threshold of quality. You may see it by logging in.