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.