Friday, May 06, 2005


"TMTOWTDI" is one of the selling points for Perl pundits everywhere. It is also, I think, the language's greatest weakness.

Very much in Perl fashion, the acronym serves to obfuscate an otherwise easily recognizable concept. That mess of letters stands for "There's More Than One Way To Do It." You'd think this would be a good thing, and when you're writing throwaway scripts it can be. Nothing beats Perl's regex syntax, and it's tough to beat it for quick text parsing jobs as well (Python lovers, put away your guns please).

A good, clear, responsible coder can also make some robust libraries with Perl.

However, there are also a ton of wacky shortcuts in Perl. You know what I'm talking about: things like "magic" variables, "implied" variables, etc. Because there are a zillion ways to do the same thing, a lot of Perl programmers like to show off how clever they are by saving themselves a couple of keystrokes here and there.

The problem with this is that you get code that is incredibly difficult to debug 6 months later. Sure, the original coder saved himself a dozen keystrokes by using as many implied variables as possible, but he often does so at the expense of several hours/days of debugging time a few months later. Wouldn't it be worth it to spend the extra 2 minutes coding clearly?

Perhaps that's why I like Java and C# and other languages that force you to be object oriented. OO languages don't let you be lazy: true, it might seem silly to have to write several lines of code just to print "Hello World" to the screen, but when the jobs get more complicated, I want the structure imposed upon me by this programming style.

I work for a company that has built the vast majority of its code base in Perl, so I use it every day and see a lot of lines of Perl code. Some libraries are very good: the programmer took the time to type those extra keystrokes and make everything as clear as possible beyond simple inline comments and documentation. But there are also a lot of BAD libraries: things where, through the simple laziness/"look how clever I am" mentality, you're forced to waste time figuring out what the heck the guy was thinking before you can use/fix his work.

Because of this, on those occassions where I get to work on the Windows side and write some C#, it is like a breath of fresh air. In the end, it makes me a better programmer because it forces organization, and that even helps when I go back into Perl because I've still got that organized mindset.

1 comment:

chornbe said...

Well said. The more I do in Perl the more I find myself sitting back and saying... kind of on both sides of the same coin... "Oh, cool!" and "What the hell??"

Structure is teh gud.