stuff is cool

This post is a response to the blog post by Luke Plant titled Why learning Haskell/Python makes you a worse programmer. Now, in the interest of disclosure and keeping things civil, I actually do like this guy’s blog and particularly enjoyed his post A Django website that took (a lot) more than 20 minutes, and I think he’s shown himself to be quite a competent programmer in the other posts of his that I’ve read. That said, I heartily disagree with his contention that learning Haskell or Python makes you a worse programmer, and here’s why.

To the non-geek-inclined readers of this blog who have made it this far, here is a quick summary of the point/counterpoint. Python and Haskell are somewhat-lesser-used programming languages (read: tools), and his contention is that even though these tools are much better at getting more jobs accomplished it makes it more difficult to get the job done with more popular but inferior tools (in his case, the programming language C# which he is forced to use at work). With license for a little hyperbole, it’s kind of like saying that one shouldn’t learn how to use a Swiss army knife because it makes building things with just a hammer more difficult.

Now for a blow-by-blow. The first argument Mr. Plant raises in his blog entry is that it’s basically a letdown that he can’t use Python or Haskell in his work, because they more accurately reflect how he thinks about the problem at hand. A few choice nuggets from that portion of his entry:

It’s very common for me to notice that using either of these languages I could decrease a chunk of code by a factor of 2-5, and not rare to see a factor of 10-20 in certain parts of the code base.

Further, my experience with Haskell means that I now see potential bugs everywhere in imperative code.

Just reading those two things makes me think he’d be arguing the opposite point of view. At least in the latter one, he’s already improving his coding as a result of knowing Haskell, even though the first quote presents more of a “What if…” scenario that may never happen (since he must use C# at work). But, here’s where I think things start to go wrong:

The net result of these things is to make me very depressed and demoralised. I feel like a human compiler, translating the Haskell or Python in my head into a language which is a whole level lower.

Aha, we’ve found the problem and really it’s not an uncommon one at all. I mean, different programming languages are, after all, different languages. Perhaps often even more so than spoken/written languages. So as anyone who knows multiple languages (of any kind) probably realizes, we often treat the new language as something that we just have to translate to, often word-for-word. But, the new language might have constructions/tenses/idioms that don’t make sense in the original language. However, since we’re unfamiliar with them we tend to avoid them for a while at first. Eventually we adopt them into our understanding of the language and then we can even begin to use them effectively. Once you develop a sufficiently deep understanding of the new langauge, you may even find yourself “thinking in” that language (I’ve done so with Spanish, it’s very interesting). Now, while you may be able to make the smooth transition between the two languages, you’re no longer treating them as two dialects of the same language, you’re recognizing them as the separate languages they really are.

Keeping that in mind, let’s push forward to the second point Luke makes, and that is “using functional style obfuscates your code when using other languages.” (Translation for the non-programmers: literal translation gives messy results) Well, yeah, this shouldn’t surprise anyone, especially anyone who has tried to use Babelfish to translate anything semi-complicated. The tool that Mr. Plant is using (C#) has limited (and relatively new) functional language constructs, and the language wasn’t initially designed with them in mind so they don’t have the nice syntax that Python and Haskell have for dealing with them. As a result, trying to literally translate from Python or Haskell into C#, you get a mess. I mean, yes, it works but it’s ugly and awkward. Much like someone who doesn’t understand English well (but speaks another language fine) might be said to be speaking “broken English”, he is effectively writing “broken C#”. He apparently hasn’t learned to compartmentalize the two languages into different portions of his programmer brain, and is still trying to treat these programming languages as different dialects of some superlanguage (or maybe metalanguage) which all programming languages derive from. Now, in a sense, all programming languages are the same in that they can all quantifiably produce the same results, but lets not confuse Turing completeness with equivalence. Programming is, after all, a process and not a result — it’s not just making sure that you get there, it’s the path that you take to get there.

So, to conclude, it’s not learning Haskell/Python that will make one a worse programmer, it’s trying to shoehorn one language into another that will. Recognizing when is the right time to use certain idioms for certain language is a skill that takes time to develop but should eventually come along.