Why Learning Haskell/Python makes you a worse programmer

 

Today, when Google searched for information, it accidentally found a funny image of the new version of language fans. In combination with an interesting blog, it was a perfect match. So, put them together. Create a backup file for favorites. Original link here: 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 hasNot
Improved my programming using other
Ages.
Haskell in particle, being so different from imperative versions,
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 ages, or noticing how much
   Less code I 'd be able to write if I was using one of these
   Ages (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 ages I
   Cocould decrease a chunk of Code by a factor of 2-5, and not rare
   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 javasscores of bugs related directly
   To this, and spent countless hours debugging these problems.
   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 satisfiedAny
   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 uugly 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
   Ages.

   C # has begun to get some features that are more friendly
   Functional style programming. So, the other day, when faced with
   Very common situation I tried a functional solution. I have a list
   Of Foo objects, each having a description () method that returns
   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) <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 wocould have been even worse -- and C # seems to have hundreds
Of different collection classes, used inconsistently in the. NET
Libraries. Also I shocould point out that if you write any methods
That accept 'delegate' (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
Any functional style code.

There are some big problems with the C # version. The first is that
There is very little protective ction in size versus the imperative Style
Code, if any. Compare to the tedious loop I wocould have written
Otherwise:

String retval = ""; <br/> foreach (Foo in mylist) <br/>{< br/> string DESC = Foo. description (); <br/> If (DESC! = "") <Br/>{< br/> If (retval! = "") <Br/> retval + = "/N"; <br/> retval + = DESC; <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
Compile (e.g. Adding an explicit cast for the delegate turned out
Not to be necessary, but I did have to specify
Convertall <string>

InsteadConvertall

).

Finally, there is the problem that this code will get me
Trouble with my colleagues. Why am I writing such complex code --
Using such advanced features as anonymous delegates -- when
Simple loop wocould 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 different ages that
Don't have syntactic support for them. Java, from what I know,
Wocould have been much worse. C # suffers in that although some
Features that enable more functional programming have arrived in C #
2.0 (along with varous 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 usePrinciples
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
Imperative versions ages just don't work like that. ASP. NET is
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
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 wowould
Lead me to use only static methods (no instance methods) as much
Possible, avoiding anything that mutates States (or even has
Possibility of mutating State). I wocould use a few ubiquitous,
'Dumb' PES ypes, and keep algorithms separate from them. This
Flies in the face of the teachings, or at least the practices,
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
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 ages, but in my current
Situation, I am not a betterSoftware 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,
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 shoshould have made it more obvious for some
People that the title of the post is not entirely serous, and mainly
I'm just griping.