Why learning Haskell makes you a better programmer

This is a great article.<p>To me, the most powerful example is this: "It forced me to think of every such problem as a chain of the primitive list operations, maps, folds, filters and scans. Now I always think in these terms. I "see" the transformation of a container as a simple sequence of these operations. "<p>That's a higher level of thinking that is faster and yet at the same time more precise than thinking in terms of imperative loops.<p>Haskell has taught him to think more powerfully.

&#62; Haskell makes your functions pure by default. You have to change the type signature if you want to do IO<p>The author seems to be conflating IO and side effects. IO is just one of the many ways that side effects can occur.<p>&#62; Purity also means you can't read or write global variables, that's just another type of IO.<p>Er... what? No, not at all.<p>Reading global variables is not side effects, much less IO.<p>Writing global variables is side effects, but has nothing to do with IO.<p>&#62; Functions that do IO are difficult or impossible to test.<p>Absolutely not, IO functions are not harder to test than regular ones. Is your function creating a file? Start your test, assert the file doesn't exist, call your function, assert your file exists. Done.<p>&#62; I now put all my IO in top-level functions that are called directly from main<p>This is great for homework, but in the real life, IO needs to be performed throughout your entire application, and unsafePerformIO is just not an option. You have to use iteratees for this kind of operation, which adds a pretty thick layer of complexity to your code base.<p>&#62; boo :: Map Integer String -&#62; String -&#62; Integer<p>This syntax is clean but it doesn't tell me anything that<p>def boo(map: Map[Integer, String], key: String) : Integer<p>doesn't tell me.<p>&#62; The point is, you can't confidently reason about a function from its signature if IO is involved.<p>Sure, you can: the mention of IO tells me this function operates within the IO monad, so I know <i>a lot</i> of operations and laws that apply to it.<p>Haskell is a fantastic language but this article is doing a very poor job at explaining why. I suspect its author has only recently started using Haskell and would have been better advised to wait a bit before sharing his enthusiasm.

I've felt the power of Haskell before, through tidbits I've learned and books like Learn You A Haskell. However, Haskell still presents itself as a giant rock in my mind, somewhat impenetrable and obtuse. It's so different from my normal thinking processes that my brain has an incredibly difficult time adjusting. It's like my thinking process turns to goo after the first few layout steps.<p>Basically, I wish I could understand Haskell so I could harness its power.

I'm sure the author is right about IO, but these sorts of articles always include such trivial examples that they do the opposite of the intended job. The one code snippet is from a dictionary look-up function. Here it is in Haskell:<p><pre><code> boo :: Map Integer String -&#62; String -&#62; Integer </code></pre> And here it is in C++ as a standalone function:<p><pre><code> template &#60;class Key, class Value&#62; Key boo (const Map&#60;Key, Value&#62; &#38;, const Value &#38;); </code></pre> or, more idiomatically, as part of a class:<p><pre><code> template &#60;class Key, class Value&#62; class Map { […] Key boo(Value &#38;val); }; </code></pre> The author's point is that the Haskell code can't do much other than use its parameters, because there is no IO involved, whereas the C++ version could do anything. Well, sure, it <i>could</i>, but let's be reasonable (which is all we can be without reading the code): it's probably gonna map a string to an int. It's just as likely that the Haskell code could do weird stuff (how does it behave if it finds multiple candidates for Value?) as the C++ code, practically speaking.<p>So this argument actually turns out to be an argument for good containers, or, more generally, for good built-in types. The author could make all those assumptions about his function from the type signature because he/she knew what "Map" meant, not because of anything inherent in Haskell's type system. I mean, I grant that Haskell has a great type system, and great built-in types. It's just that this example doesn't make the argument it claims to make.<p>Let's look at some code I'm writing now. Here is strstr:<p><pre><code> boo :: String -&#62; String -&#62; Int </code></pre> Not too helpful really. Here is a function which searches ComplexDataStructure, which contains file and directory names as well as other data, for partial matches of "string", returning a "goodness" value indicating the closeness of the match for the highest-matching candidate:<p><pre><code> boo :: ComplexDataStructure -&#62; String -&#62; Int </code></pre> I challenge anyone to work out what the function does from that. Sure, you can make more assumptions about the Haskell version, but, practically speaking, IO cleanliness has little to do with it. What matters here is knowing what the data structures do, and using decent types.

Rant: I needed an hour to get pointers and an afternoon to grasp what function pointer is in C. 10 minutes to grok recursion, and OOP (some parts of it) came as a just a sane way to do stuff ... I am hitting my head in the monad brick wall close to a month now.<p>Aside from that it is an amazing language that really kicks you to think differently.

I'm also fairly interested in Haskell but I think that studying data structures and algorithms extensively will make me a better programmer. Not learning a whole other way to program... That will not work. I am already very comfortable in C++/Java/D and other imperative languages. I can do the same work faster because I can use global state to get easier solutions to problems. If I want pure functions, I'll write a pure function. If I want shorter, more readable code I'll write a macro. Or maybe not.

I recommend some other functional language like Scheme or OCaml. All I got from my time with Haskell was frustration. I read RWH and worked through tutorials. I never got to a point where it didn't seem like the simplest tasks weren't painful.

<i>You have to change the type signature if you want to do IO... Purity also means you can't read or write global variables, that's just another type of IO.</i><p>If you've written so much Haskell that you think of global variables (!) as a form of IO, then perhaps you would benefit from writing in C for a while? Beware internalizing abstractions so completely that you confuse them with the reality.

Haskell helps you develop your imagination:<p>&#62; I have no idea what the word "boo" is supposed to mean when used as a function name. But I can be almost certain what this "boo" does. It takes a map that has Integer keys and String values, and a second argument that is just a String, and it returns an Integer. So I'm fairly sure that this function does a reverse mapping

As long as people don't abuse that power and don't write C++ code, full of statefull functors (intellegent fools they are, the worst kind), I'm happy.

Analogous to this I found category theory gave me a better/different view understanding of modern algebra and set theory.

Sure. Instead of learning the power of composition of high-order functions, you will learn that particular composition, with a trendy name, and will start to argue on forums, that this particular function composition is somehow superior to all other compositions and you must do everything using that particular composition, which is called monad..)<p>There is one question, before you press "down-vote" few times - what is the sequence of machine instructions your monad compiles into?

OT: why did you post the url with the "m=1" parameter in the end?

I swear if I see another gray on white web page, I will throw my own S#!7 at you like a 900 pound gorilla in a zoo!

And learning Lisp will make you a better Haskell programmer. Read PG's arc tutorial.

I'd also like to see an article about how learning Haskell makes you prone to preaching to other people about how better programmer it made you and why you should learn it too, despite not having much in terms of actual production to show for it...