|Perl: the Markov chain saw|
Some thoughts around the "is Perl code maintainable" discussionby oyse (Monk)
|on Aug 10, 2007 at 12:18 UTC||Need Help??|
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.