Good God! This kind of stuff is built for a very different kind of brain than mine, that's for sure.
I always come away feeling that Haskell makes the simple things tough, and the tough things beyond my reach. For me, it seems so much simpler to deal with in-place single-writer mutation, where aliasing is controlled by the type system, ala Rust or D, or, something like Elm's record updating syntax. Even Erlang will do in a pinch.
I hold Haskellers' abilities in high regard, but at the end of the day, I'm not sure if they produce better software than other equally capable/rigorous/knowledgeable developers. (Don't mean to dredge up the static/dynamic typing debate, but given the literature I have read, there is no clear winner).
Take heart! Plenty of very smart and capable people bounce off this sort of thing. I think it's a matter of temperament; some folks are wired for strict typing and struggle to see the value of dynamic typing, other folks vice versa. It's always valuable to walk a mile in the other shoes, but here we are.
For the record, it's not immutability that cause "the record problem" and bring these complex ideas, it's immutability + strict typing. Clojure's weak typing and tree-based immutability makes the record problem just as clean as the OO version:
(assoc-in person [:personAddress :addressCity] city)
returns a new record with the new city, and any other function with a reference to 'person' would not see it changed.
I will say that of the very few pieces of software I actually actively like (as opposed to begrudgingly tolerate), most are either written in Haskell or C. C software includes openSSH, wireguard. Haskell software includes pandoc, xmonad. So whether it's a property of the language itself or a second-order social filter effect (I suspect the former), it does seem to result in relatively good software. I think it's more poignant with libraries; the quality of libraries in the haskell ecosystem is incredibly good (although many people seem to dislike how the haskell ecosystem deals with e.g. documentation: by not writing as much).
> I always come away feeling that Haskell makes the simple things tough, and the tough things beyond my reach
I would say it makes (very) simple things a lot harder, but very hard things much easier. I like to think of it in terms of asymptotics. If you consider a mapping `f` from problem complexity to program complexity, python is something like `f(x) = 0.001x^10`. Very simple problems have very simple solutions, but complex problems have very (intractably) difficult-to-manage solutions. Haskell is something like `f(x) = 1 x^3`. Very simple problems become harder, but once you have a sufficiently complicated problem, the polynomial factors dominate and haskell becomes much simpler. The higher constant-factor cost allows you to handle vastly higher asymptotic problem complexity.
However precision comes at a cost, usually in verbosity and understandability. Coq, for example, requires even more precision. It's great for math, but terrible for writing a database.
For the systems I wanted to build, even Haskell feels needlessly precise in the areas I tend to get right in short order, but there's no (or not enough) support in the cases where I could use some help, such as the behavior of an O/S or database or network. I prefer F# and Erlang in their balance between precision, safety and system building ability.
> This kind of stuff is built for a very different kind of brain than mine, that's for sure.
No it isn't, and this attitude doesn't do you any good. This stuff only seems difficult because it's unfamiliar, but I can assure you it's simpler than whatever "real life" technology you are proficient in.
FP concepts are very simple (so very easy to understand!), the real power comes from their true compositionality, which is also why you don't need a "special brain" to understand what is happening -- concepts compose!
At a 50000 foot level, I will accept your statement. Concepts composition is a delightful property.
But at a lower level, it is a slog. I have tried somewhat hard (e.g understanding different monads, writing a tutorial --- doesn't everybody?) to plough through the language and the libraries, but after some point I got tired having to learn one more new concept, one more language extension, all for doing fairly routine things. Now, I'm reasonably confident that I _could_ master it if my life depended on it, but it feels so .... tedious.
> it's simpler than whatever "real life" technology you are proficient in.
That has certainly not been my experience, alas. I'm constantly unsure of whether a piece of code is idiomatic enough, abstract enough or whether it is a simple composition of some other concepts. I suppose there is a particular hump beyond which these things click into place, but I haven't come close to it. Secondly, producing any real life technology requires me to fit that tech and Haskell bindings (should they exist) together in one brain.
That said, Haskell's been a wonderful fit for writing a compiler for a pet toy language. And monads changed the way I write code in mainstream languages.
>And monads changed the way I write code in mainstream languages.
This is my main takeaway from Haskell and other FP languages and it is what I always tell others. FP is the "paint the fence" of code. Learn FP and you will become much more proficient in every other language that you end up using.
> I'm confused. How is Elm's record updating syntax related to aliasing?
It isn't. The key word was "Or".
In general, the point I had in mind is that mutability is a problem only in the presence of aliasing. Elm and Rust chose two different points in the mutability+aliasing space. Elm doesn't have mutation, Rust restricts mutation when there is aliasing.
> FWIW, Elm also doesn't have a nice way to update nested record fields, and there are lens libraries in Elm to deal with the same problem.
I always come away feeling that Haskell makes the simple things tough, and the tough things beyond my reach. For me, it seems so much simpler to deal with in-place single-writer mutation, where aliasing is controlled by the type system, ala Rust or D, or, something like Elm's record updating syntax. Even Erlang will do in a pinch.
I hold Haskellers' abilities in high regard, but at the end of the day, I'm not sure if they produce better software than other equally capable/rigorous/knowledgeable developers. (Don't mean to dredge up the static/dynamic typing debate, but given the literature I have read, there is no clear winner).