These days, I wouldn't know where to start. However, modern engines are far more reliable, require far less maintenance, and have much longer service periods than those old ones. Again, an overall win.
I'm not really sure: while certainly modern engines and other mechanical stuff have several undoubtful advantages over old ones, I think that these tend to vanish when you take maintenance and duration into account.
It's not about the engine... but a pair of years ago while driving my dad's relatively new Ford Focus I happened to have one of my passengers open the glass beside his seat: as soon as he touched the button, the glass fell down like a guillotine. It made such a noise that I reacted angrily, thinking that he had opened the door and hit something: in fact it was winter and very cold, I had just raised the heating to the maximum for a few seconds because the front glass was becoming completely foggy. Well, apart the disappointment for the fragility of the mechanism, I thought in that situation that it would have been fine if there were an emergency one in the form say of a leverage system behind a removable panel in the door just to temporarily cope with such an inconvenience.
Other (counter-)example, not having to do with cars but with refrigerators: here, in our "country house" (it's not, really, but I couldn't come up with a better expression) we have one that has undergone the moving through two houses and is some 35 years old! I bet it's not terribly enviromentally safe, nor efficient nor nothing. But it does work! A newer one we got only few years ago broke down the last month, and to repair it would have costed more than buying a new one.
I think that what's expressed by the former two languages applies to most material devices: they're seem not to be made with duration in mind. Whether this is a circumstance, and a side effect of some other win they may have, or a precise design strategy is debatable. I don't think this could be translated to programming languages, though.
because, they argue, at some point in the future, it might be necessary to do something extra within the body of the loop, and then the maintenance programmer would have to reconstruct the loop to the second form. That would be a 'bigger change', therefore 'more' or 'harder' maintenance.
I say rubbish. If it becomes necessary to re-factor the latter concise form into the former, then the algorithm has changed significantly. And the issues of maintenance--what other effects that change of algorithm will require and what knock on effects that has on the wider code-base--are far more important that the small effort required in performing the refactoring.
Well, yes: it's called YAGNI in brief, but you surely knew.
In reply to Re^7: Some thoughts around the "is Perl code maintainable" discussion
by blazar
in thread Some thoughts around the "is Perl code maintainable" discussion
by oyse
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |