Mutations becomes first class values like numbers or arays, and hence can be primitives for more complex mutations, whose types can be inferred from the types of primitive mutations.
This means that the we have compile time guarantees that certain piece of code wont change anything in certain part of the state - This function wont change anything in that part of the data.
It is no joke, though not strictly true, that Haskell has been called the world's best imperative language.
I think this comes from early and continuous exposure to some forms of programming, rather than inherent to pure functional programming.
I personally find it much easier to use recursion and other functional techniques because it composes better. This probable comes from my exposure to Haskell much earlier than most.
> I believe the vast majority of programmers.
Yups. We get educated with imperative langs. The majority of us do.
This is what I was talking about in the section "Unlearning and relearning". While there are _some_ domains (like embedded systems) for which Haskell is a poor fit, a lot of the difficulties people have with it (and with FP in general) is that they have been heavily educated to think in a particular way about computation. That's an accident of history, rather than any fundamental issue with the programming paradigm.
Any paradigm shift requires re-learning I think. I don't actually think that's particularly hard, nor do I think it means the paradigm isn't a good one, it's just an inevitable consequence of a paradigm shift. Some shifts are easier than others, if the paradigms are closer together, but functional and imperative programming are quite distant in my view.
Nevertheless, I've seen some people find this easy, others find it hard. YMMV I guess.
Do you mean like this example of calculating the 5th triangular number with a procedural loop and mutable state? Haskell supports them just fine!
https://hackage.haskell.org/package/bluefin-0.0.7.0/docs/Blu...
Eh. Elm has achieved quite a bit of success just by having good tooling and a good ecosystem. Says something about people's willingness to learn pure functional programming, if the situation is right.
> I find some code easier to express with procedural/mutable loops than recursion
This is usually a familiarity problem, IMO.
I often say: people think mastering Haskell is about mastering monads. But it's actually about mastering folds.
with(require("ramda")) fn = pipe(…)
For those wondering `with` in JS is a bit like `extract` in PHP except it creates a new context right after itself rather than modify the context it finds itself in. It's super deprecated because it's inscrutable and silly except in this case and/or when you need to solve Codewars katas in a limited number of characters.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://www.php.net/manual/en/function.extract.php
EDIT ramda is a nice utility library in JS that supports partial application of arguments in arbitrary order https://ramdajs.com/docs/#subtract
Sure, a determined Fortran programmer can write Fortran in any language, but if they have trouble doing so, maybe the issue isn't the language.
I think exactly that all the time. It’s ridiculous.
> That's a problem no haskell user has, honestly.
I had this problem all the time when trying to write games in Haskell. Not every subject matter decomposes into semirings. Just like not everything decomposes nicely into objects. People tried to fix this with FRP or lenses. Both are worse than imperative programming for games imo.
In a sense, that's true: people who do have this trouble constantly (e.g. me) very quickly cease being Haskell users. But that's hardly an argument for TFA's claim that "Haskell is probably the best choice for most programmers, especially if one cares about being able to productively write robust software, and even more so if one wants to have fun while doing it"; if anything, it's a counter-argument.
"Execution in the Kingdom of Nouns" comes to mind.
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
You missed "lazy evaluation by default" in that list ;) Those properties are kind of the definition of Haskell, so without all of them you'd have another language.
Like the sibling commenter mentions, this seems more of a "I'm unfamiliar with this" thing rather than a problem with Haskell...