When good programmers make bad choices for touchy-feely-smurfy reasons

Every now and again, I reserve the right to taunt a friend mercilessly. This is one of those times.

My friend Danny O’Brien was trying to decide whether to use Perl or Python for a project. He was originally leaning towards Perl; I blame the fact that he might have been living in California too long, or perhaps he’s inhaled too many fumes while changing his lovely daughter’s diapers.

He writes:

I’m utterly torn between Perl and Python. My first choice in this case would be Python, because bad Python code doesn’t seem to be quite so personal. I’ve seen people spit blood at other coder’s Perl, just because it’s not the way that they would do it. Perl demands rather more sympathy with your predecessor than does Python. With Python, it’s just more code to stare at.

This sort of statement makes me imagine Danny at an electrical engineering class: “But professor, how does Kirchoff’s Voltage Law make you feel?”

Danny’s statement seems to imply that Perl requires you to know the previous programmer’s “headspace” in order to be able to maintain his or her code. In other words, the language alone does not communicate the author’s intent without the kind of exegesis usually reserved for studies of the subtext of inside jokes that might have appeared in the Gnostic Gospels.

You wanna get all touchy-feely and sympathetic with the previous developer’s “inner child”, don’t read their code. Instead, why don’t you two curl up in front of the TV and watch Oprah, then go hop in the hot tub and kiss?!

What is this, the Matt Damon/Ben Affleck school of coding?

That said, your successor does need to actually know the language. Most of the people I can imagine maintaining this code will know Perl but not Python. Python doesn’t take that long to learn, but reading Python to take on someone else’se project just isn’t much *fun*. Sitting down to learn someone’s Perl, while tough, does teach you about the way they were thinking when they wrote the application. Python’s clarity, I think, cuts down on its expressiveness in depicting why certain decisions were made. When I had to hunker down and learn POE or Moveable Type, for instance, I came away with a very deep understanding of how it was supposed to work. It was fun, albeit time-consuming. I sometimes have problems doing the same with slabs of Python code, just because they can be very lacking in personality.

What you call personality, I call distraction. Yes, I’m probably bound to find out more about the previous coder’s approach to programming by their Perl code. I might even able to ratiocinate their astrological sign or whether they’re dominant or submissive. But damned if I can figure out what the hell they were trying to get the code to do.

Python’s clarity is what I like about it. My first Python project — an actual paying one with an actual deadline for an actual system to be used by actual users — required me to pick up where the original developer, who had to work on other parts of the system, left off. The clarity of Python actually allowed me to see his design decisions; the obscurity of Perl would’ve been a hindrance.

That said, I’m not paid to be a programmer. What is fun is a hobby can be skull-crackingly frustrating in a job with a deadline.

Even when I have plenty of time to kill (hah!), I’d rather have a language that let me concentrate on my task and less on the language’s idiosyncracies.

Danny, being the kinesthetic sort, learned his lesson by peeing on the electric fence:

Now, a couple of days into it, I’ve begun to seriously reconsider. I’m nowhere near the Mason bit of the application, and I’m getting continually bogged down in Perl style issues that really don’t have anything to do with what I’m trying to write.

To be honest, I think this is my Perl rustiness kicking in; and I think it may go away after a few more days hacking. Worse, though, is the effect of something I thought would be a real boon – CPAN. There’s a bunch of useful utilities there that I’d love to suck in and use in my program. But they all have different idioms – all of which I have to sit down and learn. Plus there’s the whole dependency issue: sooner or later I’m going to have to install all of this on the working server, and there’s a real penalty to be paid for being dependent on a lot of scattered Perl modules. Will they work? Will they still be maintained? Which of alternative implementations should I choose?

Not into the touchy-feely thing anymore, are we, John Gray?

Oh, I’m being cruel now. Group hug!

(I’m kidding, Danny.)

Luckily, he eventually made the right decision, and I’m happy to report that things are working well for him.

Otherwise, I might have to mock him even more.

5 replies on “When good programmers make bad choices for touchy-feely-smurfy reasons”

Oh yeah, /entirely/ unemotional defence of design issues there from young Mr. Spock. It may have been a while since I did any drum-therapy, but I think I know who’s tub-thumping here…

Look, here’s my less hippy-sounding approach to programming languages: they all suck. You just have to choose which sucking noise you find less distracting.

For you, the clear and straightforward nature of Python works great. And that’s lovely. But you and I know Lisp people who think anything that has more syntax than parenthese is “distracting”. And you know that they think you’re a big girl’s blouse.

I don’t think it’s touchy-feely to admit that Perl puts a lot of its expressiveness into the syntax, and Python puts that burden onto the programmer’s overall structure.

There are times when I first look at someone else’s Perl programs and think, what the hell, did this guy just sick up over the keyboard? But then again, here are times in Python where I crave some Perl-style syntax sugar instead of doing some endless string of lambdas or indistinguishable loops – whether it’s writing it, or reading it.

That’s what I mean by personality. And unless you’re planning on writing your own “Python Programmers Are From Mars, Perl Programmers From Some Wimpy Little Asteroid Whose Name Isn’t Even a Word, Just a Bunch of Numbers” self-help guide, I don’t think that’s a weird thing to say.

Anyway, enough of my emoting. I’ve got some chakra to re-align. I’ll leave it to any big manly Perl fans to put you in touch with inner child.

One truly rational-hard-nosed-mercenary way to decide between such choices would be to ask: “Which language is going to get me farther in finding a new job, should I need one?” I know there are some interesting-sounding Python jobs out there, even these days, though in sheer numbers there are probably more listings for people with Perl toolkits.


True dat. Un-1337 as it may be, VB has kept me in the lifestyle to which I have become accustomed more than any other programming langauge. Delivering working software that people can actually use trumps HAX0R bragging rights every time.

However, I believe that Danny was working on a hobby project than on a for-money project, so the “employability factor” in choosing a programming language wouldn’t have come into play.

Well done, Joey! The guy in the next cube wanted to know what I was laughing at so much. Of course, when I showed him, he just rolled his eyes and went away, but who cares? Thanks for making some good points in a thoroughly humorous (or is it humourous) way.

Joey, you just know that this item is going to be stering up comment like hornets from a nest you just hit with a brick…

Perl is NOT bad, if you have around on you can meet some strange and wonderful people who think keywords are for wimps, but if used in a reasonable fashion it can be useful and productive.

However, just do NOT get me started on using whitespace as a structural element of sourcecode! No, that just ain’t right!

Leave a Reply

Your email address will not be published. Required fields are marked *