Python and Haskell Make You a Worse Programmer?

by Jeremy Jones

I stumbled across this blog post the other day on, once again, Ned Batchelder's blog. It's an interesting rant about how learning Python and Haskell have proved more frustrating than liberating because the author isn't able to use Python or Haskell at work. When faced with a task at work which has to be done in C#, the author states that he thinks in Python (or Haskell) and has to translate it to C#.

The post came across as more of a "Why I'm More Frustrated by Knowing Python and Haskell" than "Why Python and Haskell Make You a Worse Programmer". The frustration that this author describes is real. I've felt it many days when firing up Visual Studio to work on my at-work C# project. I would definitely prefer to code in Python than C#. And if I knew Haskell, I'd probably be saying the same about Haskell.

While most of what the author of the sited post was getting at was tongue-in-cheek/rant, he alluded to a potentially legitimate productivity penalty for knowing Python/Haskell. Many times, he would code up something in Python or Haskell to prove to himself that he could, in fact, accomplish the needed task more quickly and simply by using his preferred language. Even given the time "wasted" in such an exercise, I don't consider his broader perspective necessarily a productivity hindrance. It would be extremely difficult to prove that writing a throwaway implementation of a task in the non-target language followed by a second implementation in the target language really costs more in the end than writing it only once in the target language. Is the second implementation in the target language more maintainable as a result of having written the throwaway? Did "practicing" with the non-target language help solve some specific problem more quickly later down the road? Does "playing" with the non-target language increase a programmer's mental accuteness and clarity and allow easier, quicker thoughts when coding in the target language? I'm not asserting that this is the case. I'm just speculating. But I'm speculating that it's likely the case. Specifically, I'm speculating that a broader perspective and regular exercise with a variety of technologies is beneficial in the long run.

Ned, in his typically Neddish manner, provided a number of excellent suggestions to alleviate said C#-frustration. Definitely check out Ned's blog (linked to above). He doesn't say, "Try to forget Python and Haskell." He seems to be saying to embrace them, but sometimes work is, well, work. My conclusion is that if you know a language like Python or Haskell (or Perl or Ruby) and have to work on a language like C# or Java or C++, you're probably going to be frustrated. But keep yourself well rounded. Keep working in your language of choice when you can, whether at work or home. Try to do things idiomatically within the limits of the language you're working in. Don't try to force fit ideas from your favorite language into a less favorite language. And read Ned's blog. (Did I say that already? :-) He has some more tips on lowering the frustration level.


2006-10-05 05:13:17
The usual retort to "my language doesn't have feature x" seems to be "use a design pattern or common language idiom instead". The design patterns apply to any language with (relatively) full-featured OO, while the set of idioms is like a set of "manual extensions" to the language. If you must iterate over a collection in a language, you might use "for", "foreach", or pass an anonymous code block to a higher-order function that handles the iteration. Mark Dominus says that verbose idioms written over and over just indicate that the language has room to evolve.
susan senator
2006-10-05 06:51:43
I personally love it when Ned is being Neddish...
Jeremy Jones
2006-10-05 07:07:01

Thanks for dropping by! I hope the description "Neddish" came across as positively as I intended. Ned's Neddishness is the reason I read his blog. Take care and drop by any time!

Jeremy Jones
2006-10-05 07:12:02

I've just given the Mark Dominus article a cursory glance. Looks interesting. It'd be nice to think that all languages are evolving and will converge on a common set of idioms that model the way we think. All languages have a ways to go, I'm sure.

Jeremy Jones
2006-10-05 08:32:42

That was an _awesome_ article that you posted! Thanks for that. I just finished it up and am about to blog a link to it on a new post. Thanks!

2006-10-10 11:27:16
I completely understand this. It's terribly frustrating trying to program in Java and once again seeing a closure as a natural solution to a problem only to remember, once again, that I can't use closures. On the flip side, I once ported a Java implementation of Prolog to Perl and was cussing because Perl doesn't have built-in method overloading. Given Java's verbosity and bondage-and-discipline style of programming, I'll definitely choose Perl whenever I can, but there are days the language frustrates the heck out of me.
2006-10-10 11:36:10

And for anyone who's interested in the Perl version of his code snippets:

join "\n",
map { $_->description }
grep { $_->description ne "" } @mylist;

Or if you're feeling really persnickety:

join "\n", map { $_->description eq "" ? () : $_->description } @mylist;
Aristotle Pagaltzis
2006-10-18 19:54:33

Ovid: why the contortions?

join "\n", grep $_ ne "", map $_->description, @mylist;
albert bulawa
2007-01-03 13:39:30
I have programmed in Perl, PHP and Ruby for years (no Python though - this signifcant whitespace thing used to drive me nuts), then I joined a Java project without having written a single line of Java before.

At first it was painful, but then the relief came - having understood power of Java's static code analysis. Now, more than a year later I can't even imagine writing in a so-called dynamic language anymore. Of course, simply writing may be easier in Perl or Ruby, but it is always necessary to come back to own code after a few months because a bug has been found. Or, worse still, to come to someone else's code when that person is not around anymore. Lack of static type-safety is a disaster then.

And it's easier to think about any non-trivial project in terms of clear, static, well-defined interfaces than untyped somethings that may happen to do what they are supposed to, or not.

Justin Lesarge
2008-01-24 09:45:13

You just hit the nail on the head. Less typing doesn't necessarily mean better programming, because there is usually infinitely more to a project's life cycle than the fleshing out stage.

Though, I think that dynamic languages have their place. Mainly, in very short snippets that will never require any significant auditing or debugging. For instance, in event handlers within a markup language, or in very short user-supplied scripts to run within a large program, or in an interactive shell, or in certain micro-programs and system or web scripts.