Why learning Haskell/Python makes you a worse programmer (2006)
Why learning Haskell/Python makes you a worse programmer

  
      
      
    
        I've found, contrary to what you sometimes read, that learning Python and
Haskell has not improved my programming using other languages. Haskell in
particular, being so different from imperative languages, is supposed to give
new insights into programming that will help you even when you are not using the
language. My current experience doesn't exactly tally with this, and here is
why:


Demotivation.
I find I think in Python, and even in Haskell to some extent, even though I
have used Haskell very little. I constantly find myself wanting to use idioms
from these languages, or noticing how much less code I'd be able to write if
I was using one of these languages (which, although very different from each
other, are both much more powerful than the language I use at work, C#). 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. Before, I was fairly well aware of the
problems that stateful programming and side-effects can cause, having dealt
with many scores of bugs related directly to this, and spent countless hours
debugging these problems. But without any alternative, I guess I had just
lived with it. Now I know there are other ways of doing these things, I find
it difficult to be satisfied with any of the code I write. I am constantly
aware that I am writing traps that other people are likely to fall in.
I also find C# code very ugly compared to both Python and Haskell. On the
visual level, the mandatory use of braces everywhere (OK, they're not
mandatory everywhere but are enforced by coding standards with good reason)
makes code contain a lot of line noise and empty space, and combined with the
verbosity of the libraries and type declarations etc, you find that a page of
C# hardly does anything. I'm also thinking of beauty on the mathematical
level, C# is a grubby mud hut compared to the breathtaking, elegant tower
that is Haskell.
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.


Using functional style obfuscates your code when using other
languages.
C# has begun to get some features that are more friendly to functional style
programming. So, the other day, when faced with a very common situation I
tried a functional solution. I have a list of Foo objects, each having a
Description() method that returns a string. I need to concatenate all the
non-empty descriptions, inserting newlines between them.
The code I wanted to write was this Python code:
"\n".join(foo.description() for foo in mylist
          if foo.description() != "")

Or this Haskell:
concat $ List.intersperse "\n" $ filter (/= "") $ map description mylist

Using generics from C# 2.0 and the methods they contain, the best I
got was:
string.Join("\n", mylist.ConvertAll<string>(
            delegate(Foo foo)
            {
                    return foo.Description();
            }).FindAll(
            delegate(string x)
            {
                    return x != "";
            }).ToArray());

If I had been starting with a different data structure, the C# version would
have been even worse – and C# seems to have hundreds of different collection
classes, used inconsistently in the .NET libraries. Also I should point out
that if you write any methods that accept 'delegates' (the nearest thing to
first class functions) you have to declare the function signature for them
separately if one doesn't exist already (or if you don't know where to find
one that already exists), further adding to the bloat of any functional style
code.
There are some big problems with the C# version. The first is that there is
very little reduction in size versus the imperative style code, if any.
Compare to the tedious loop I would have written otherwise:
string retval = "";
foreach (Foo foo in mylist)
{
    string desc = foo.description();
    if (desc != "")
    {
            if (retval != "")
               retval += "\n";
            retval += desc;
    }
}

There isn't much in it.
Second, it took me longer to write. I had to do some experimenting to see how
much type information I had to add to get it to compile (e.g. adding an
explicit cast for the delegate turned out not to be necessary, but I did have
to specify ConvertAll<string> instead of ConvertAll).
Finally, there is the problem that this code will get me into trouble with my
colleagues. Why am I writing such complex code – using such advanced
features as anonymous delegates – when a simple loop would have sufficed? I
actually left my functional version in, but was so embarrassed about it I had
to add a brief explanatory note.
The fact is that functional idioms work badly in languages that don't have
syntactic support for them. Java, from what I know, would have been much
worse. C# suffers in that although some features that enable more functional
programming have arrived in C# 2.0 (along with various other language
improvements), huge chunks of .NET libraries have not been updated to take
advantage of them, and our own code certainly hasn't.
It might be argued that you can still use the principles of functional
programming (no side effects, functions depend only on their inputs etc) and
get benefits that way, even if you can't use the idioms. In reality,
libraries and frameworks designed for imperative languages just don't work
like that. ASP.NET is an especially bad example. You develop controls by
inheriting from Control and then overriding various methods. Most of
these methods have no return value and no inputs, and work solely by mutating
the state of the object (or other objects). They are then called by the
framework in a somewhat subtle and complex order (yes, it is a nightmare to
debug).
In fact, applying the principles of functional programming would lead me to
use only static methods (no instance methods) as much as possible, avoiding
anything that mutates states (or even has the possibility of mutating state).
I would use a few ubiquitous, 'dumb' datatypes, and keep algorithms separate
from them. This flies in the face of the teachings, or at least the
practices, of the main programming paradigm popular today, OOP. I can't apply
what I think are good principles for writing code without rejecting the very
paradigm of the language and libraries I am surrounded with. It's fairly
hopeless.


So, learning Python and Haskell has demoralised me and encouraged me to write
code that is bizarre and difficult to understand, and, in the context of an OOP
code base, provides little benefit over imperative programming. I have no doubt
that in general I am a better programmer for learning these languages, but in
my current situation, I am not a better software developer – my productivity
has in fact nose-dived. When I get frustrated with the C# code I write, I then
go and write it again in Haskell and Python, to demonstrate to myself how much
better they are, which is a pointless exercise that only demotivates me further.
The moral of the story: don't bother improving yourself, unless you have the
freedom to improve your environment accordingly. That's rather depressing. Can
anyone put a better spin on this and cheer me up?
Update: I probably should have made it more obvious for some people that the
title of the post is not entirely serious, and mainly I'm just griping.
      




