I learned Haskell in just 15 years

> You can have mutability in Haskell too.

Haskell enforces this via a type system.

What safeguards around mutability does Clojure have?

If I import a method 'foo()', is there any kind of contract, notation ... anything which could suggest whether it mutates or not?

Pandoc seems useful, but maybe "mass market" is a bit of an overstatement?

And since many programmers like myself had to learn Haskell, I think Haskell should have a better head start and be in a better position, if it would be so useful for "real world" use cases.

But please don't take this as an attack on haskell. I have nothing against the language, or its users and I did not suffered because of it in university, I am just curious on the appeal. Because I love clean solutions, but I also want to ship things. So part of me are wondering if I am missing out, but I so far I see not much convincing data. (But I am also mainly interested in high performance and real time graphics and haskell is really not the best here)

Yeah I can't really follow these threads.

I saw:

> What's the benefit of learning a PURE functional programming language, opposed to just using a language which has adapted the best bits and pieces from the functional programming paradigm?

I also saw:

  Though you can break purity with just inputs:

  define f(o): return o.x
  let a = {x=1}
  f(a)
  a.x = 2
  f(a)

I don't know if that's the tail-end of a reductio ad absurdum which is trying to demonstrate the opposite of what it stated. Either way, to be clear, the above would be rejected by Haskell (if declared as a pure function.)

I guess if you learn a functional language "which has adapted the best bits and pieces from the functional programming paradigm" then you might think that the above is broken purity, but if you learn a "PURE functional programming language" then you wouldn't.

Well, I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication. It also ends up being more than double the size of the Java code. And, as the author admits, it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array.

So, one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell... I maintain this is a good example of making an easy problem tough.

In theory, you could pick up your one language, say, Java, and through the course of a normal career learn everything necessary to program in that language in the best possible way.

In practice, it's a pretty well-known phenomenon experienced by many skilled programmers that being forced into different styles by different languages results in learning things that you would only have learned very slowly if you had stuck only to your original language. To be concrete about the "very slowly", I'm talking time frames of your entire career, if not your entire life and beyond. It would be a long time programming in Java before you discover the concept of something like "pure functions" as a distinct sort of function, a desirable sort of function, and one that you might want organize your programming style around.

Of course, having heard of the concept already, we'd all like to fancy ourselves smart enough to figure it out in less than, say, three decades. But we're just lying to ourselves when we do that. Even the smartest of us is not as smart as all of us. You are not independently capable of rediscovering everything all the various programming communities have discovered over decades. If you want to know what even the smartest of us can do on their own without reference to decades of experience of others, you can look into the state of computer programming in more-or-less the 1980s, 90s if you're feeling generous. I think we've learned a lot since then, and the delta between the modern programmer and a 1980s programmer certainly isn't in their IQ or anything similar, it is in their increased collective community experience.

By getting out into systems that force us to learn different paradigms, and into communities that have learned how to use them, we draw on the experience of others and cover far more ground than we could ever have covered on our own, or in the context of a single language where we can settle into a local optima comfort zone. Jumping out of your original community is kind of an annealing process for our programming skills.

"The best “fp” I’m using nowadays is closures, currying in the form of func.bind(this[, first]) and map/filter."

That is really not the lesson about software design that FP teaches, and blindly carrying those principles into imperative programming is at times a quite negative value, as your experience bears out. FP has more to say about purity of functions, the utility of composition of small parts, the flexibility of composition with small parts, ways to wrap parts of the program that can't be handled that way, and providing an existence proof that despite what an imperative programmer might think it is in fact possible to program this way at a system architecture level. I actually agree 100% that anyone whose takeaway from FP is "we should use map everywhere because they're better than for loops and anyone who uses for loops is a Bad Programmer" missed the forest for the leaves, and I choose that modification of the standard metaphor carefully. I consider my programming style highly influenced by my time in functional programming land and you'd need to do a very careful search to find a "map" in my code. That's not what it's about. I'm not surprised when imperative code is messed up by translating that into it.