Why learning Haskell/Python makes you a worse programmer

 

    今天google搜資料的時候，無意中搜到一副新版的Language Fans的搞笑圖片，配合發現的一篇有趣的博文，真是相得益彰。so，把它們放在一起。在這裡做個收藏備份。原始連結在這裡：http://lukeplant.me.uk/blog/posts/why-learning-haskell-python-makes-you-a-worse-programmer/

 

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:

1. 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.

2. 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<br /> if foo.description() != "")<br />

Or this Haskell:

concat $ List.intersperse "/n" $ filter (/= "") $ map description mylist<br />

Using generics from C# 2.0 and the methods they contain, the best I got
was:

string.Join("/n", mylist.ConvertAll<string>(<br /> delegate(Foo foo)<br /> {<br /> return foo.Description();<br /> }).FindAll(<br /> delegate(string x)<br /> {<br /> return x != "";<br /> }).ToArray());<br />

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 = "";<br />foreach (Foo foo in mylist)<br />{<br /> string desc = foo.description();<br /> if (desc != "")<br /> {<br /> if (retval != "")<br /> retval += "/n";<br /> retval += desc;<br /> }<br />}<br />

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.