|Welcome to the Monastery|
TIMTOWDTDI, obfu and analyzis of codeby zby (Vicar)
|on Mar 12, 2003 at 11:13 UTC||Need Help??|
Abstract: I analyze why Perl is perceived an obfuscated language and propose a solution to that problem not compromising the richness of the language.
There is an obvious connection between the TIMTOWDTDI philosophy and the fact that Perl is perceived obfuscated. It can go three ways. First is that when the language is really powerfull than can write obfu. Second is that when the language is rich in constructions of simillar semantics people use just one of them mostly, and when they read code written by someone else then they need to get used to new constructions. The third is more psyhological - since the language is rich there is much to learn and it is simpler to just say that the code is obfu than to learn.
It seems to me that Perl 6 is even more rich language than Perl 5. Just name a language theoretical term and you have it in Perl 6. So the problem is going to be only worse with Perl 6.
Don't read me wrong - I really like the fact that Perl is such a rich language. There is much fun in constant learning New Ways To Do It and observing constant improvement in the way you code. Smaller programs means less bugs and better understanding of the code. So I really believe the richness is a Good Thing but the bad fame of being an obfu language has done much harm in the acceptance of Perl and we should cope with that.
Here is my proposal - something that could be useful for large projects. How about writing a tool that would report bad practices? What bad practices mean should be of course a variable - thus every project could suite it to its own convenience. For medium projects the tool would be less strict, for larger ones more, and each team could choose it's own style. I think it should rather report than not let to compile (like use strict) but it could be done variable as well.
And here is a beginning of the list of "bad practices" for large projects (I hope you will add your own):
A reference discussion can be found in this node: Why our company doesn't use Perl :(.
UPDATE: Style guidelines are nothing new - as the list provided by valdez shows. What I am suggesting is some tool for automatic checking of guidelines conformance, and I mean something flexible, and extendable as opposed to the great but fixed -w switch.
UPDATE: There seems to be a Parse::Perl project planned by Damian Conway. And there is the PPI library but unfortunately "Most of this is really broken, and put in CPAN for the benefit of the interested".