To the other people saying that pure functional programming is the reason that it's difficult to explain Haskell to other programmers and blaming them for doing too much imperative style coding, it's the wrong assumption. Pure functional programming has nothing to do with the difficulty in explaining Haskell. Pure functional programming is in Lisp/Schema/C#/Clojure/and other languages and people have no trouble learning it.

Haskell is difficult to explain because it has many terms, vocabulary, and syntax that are not familiar to people. It's ML-style syntax doesn't help.

Most tutorials targeting Haskell beginners implicitly assume the readers already know the Haskell syntax, terms, definition, etc, and go right ahead to explain the advance concepts like functor, applicative, or monad. It's like teaching them how to fly before they know how to walk, in the Haskell land. No wonder Haskell beginners are frustrated with any of the monad tutorial.

The thing is. Stop. Stop telling beginners what monad is. Just show them the basics in Haskell and get something useful going. Get them to write and use Haskell programs. When the need arise, they will look into what monad is. Programmers have used STL plenty without knowing the internals of C++ templates. Same thing can be done with monad.

Just to follow up on your other comment:

> When the need arise, they will look into what monad is.

I couldn't have said it any better. This is the exact scenario that this post is aimed at.

>There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this.

That's probably because most of the tutorials you've followed have adopted an imperative style of programming. It is easy for you to follow along because it really isn't all that different from what you are accustomed to. Functional programming really is a different beast entirely. It's often said (though I remain skeptical) that it's actually easier to learn functional programming as a non-programmer than to un-learn your imperative programming tendencies.

>The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought.

I don't think that's a fair assessment. You could say the same thing about starting from functional programming and switching to imperative; some people actually do this! They find the idea of mutating a variable to be completely counter-intuitive!

I would love to meet this mythical being who understands functional programming but has no clue how to write an imperative program.

While going through a Math undergrad program in the mid-90s, I noticed that some number of my fellow students had a distaste for programming.

As someone who'd done reasonably well with both and had thought of them as heavily overlapping areas, I thought this was interesting, so I tried to poke at this a bit.

One of the concepts I got back from a talented classmate was basically a complaint about mutable variables -- that in an algebraic description of relationships for a given system what we call "variables" are less variable and more "unknowns" which represent fixed if unidentified quantities. Others similarly noted there was something absurd about writing out equations like "x = x + 2".

I can see why they think that, but the important thing is that "x = x + 2" is not an equation. It's just an arguably poorly chosen operator (Pascal gets this right and uses ":=" for assignment).

The trick is to stop reading that line (in your head) as "x is equal to x plus two", but instead "x is assigned the value of x plus two".

> It's just an arguably poorly chosen operator (Pascal gets this right and uses ":=" for assignment).

That's one potential takeaway, but when I turned over the complaint in my mind, this was arguably another way of complaining about mutability.

Also, given the timing, it's pretty likely that one of the languages they'd learned was Pascal: that was the language of the first few CS classes at my school in the 90s, it was also the language of any high school curriculum that led to the AP exam, and Borland's Pascal products were still pretty popular PC dev environments.

They could've also been unlucky and received their first exposure by choosing to do a numerical analysis class in Fortran or C, of course. :/

Most students of pure mathematics get functional programming much faster than imperative programming if they have never programed before.

Source: all my classmates.

People who exclusively use Excel spreadsheets to program is a good example. Most people who use spreadsheets never use functions in a cell whose effect is to change the function or value in another cell.

> They find the idea of mutating a variable to be completely counter-intuitive!

The notion of mutation is implicit in the definition of "variable."

Except it isn't. Unless you learn imperative programming before you learn basic algebra, the first definition of a variable you encounter is that of an immutable one.

Actually an algebraic variable is named that way because you can change it every time you do the exercise.

So you don't change it during one exercise, but you can and certainly will change it when you change the exercise to another one with the same principle.

That behaves just like a function: the values of the variables change each time you call the function but not within. When you do a new exercise, it's really a bunch of new variables with the same name--variables cannot affect each other between exercises!

That's not analogous at all to mutation.

Right, but you're not mutating it in the middle of your calculation.

If you have a sum for example sum_{x=1}^{10}x^2, x definitely changes quite many times during your calculation.

No, that's an example of recursion. With recursion you aren't mutating the variable, you're shadowing its definition. This is a subtle, but important, distinction.

Recursion? The "function" is not calling itself at all. I'm quite sure that is not recursion, neither in the mathematical nor computer science sense.

Recursion is how you implement a sum without mutation (an imperative loop is how you'd implement it with mutation). You've merely given me the function written in a declarative notation.

I think we are talking about different things.

For example, if you integrate x^2 dx from x=0 to 10, x changes continuously.

It's clear that x is not fixed to any particular value.

Yeah, you're talking about the mathematical definition of a bound variable. Functional programming languages use this whenever you define a function:

   foo x = x * 2

Every time you call foo, x is bound to a new value (but only within the scope of foo). This is not the same as mutating some memory location associated with the name x.

x does not mutate at all. x is simply a placeholder for the values in the series of additions that your expression expands to, that is, 1² + 2² + 3² + ... + 10². Or stepwise, to 1² + sum_{x=2}^{10}x² etc. all three expressions are equivalent, and no mutation of x occurs anywhere

The series of additions can also be infinite, in which case it would be quite difficult to expand fully, but that doesn't prevent you from doing mathematics with it.

An algebraic "variable" is perhaps better called an "unknown"

This is a pretty common idea, but it's because pure functional programming is, at first, all about getting you to significantly change your programming POV. It's a shift for anyone---in fact, the better you are at understanding C/Ruby/Python/Perl/Java/ObjC/Lua the harder a shift it is.

At the end of the day, you adopt a new way of thinking that is incredibly clarifying for all programming. One simple thing is that it allows you to "see" where state, re-entry, evaluation, IO, and failure are happening in a program---things that you are blind to when you're used to languages where the answer is "always".

This article isn't even meant to explain why you ought to learn Haskell. It's more like a signpost on your path to mastery, should you begin walking it.

Post author here. I'd love to know where you stumbled!