[whateveracct]

The nice thing about Haskell from a readability standpoint is to unpack what code does at any point, you only have to perform substitution (i.e. beta reduction) over and over. This is a key difference from most other programming languages, which require you to have a little VM in your head. "Localized reasoning" is what Haskellers call this.

To read it quickly, you do have to learn & internalize abstractions. Both a common set of them (the usual type classes) & abstractions custom-built in your project. Abstractions in Haskell tend to be true abstractions & not encapsulations. You don't necessarily need to know the internals to understand the abstraction. I've seen this put off systems programmers before (people used to writing C etc and understanding the assembly).

I wouldn't expect someone with no Haskell knowledge to understand Haskell code. I've seen higher-level people (e.g. VPE-level) get upset by this and knee-jerk decide Haskell is problematic. I'm of the opinion that such knee-jerks aren't worth listening to..I don't care about opinions of people who haven't met (or honestly tried to meet) the prerequisites.

Regardless, I will say as someone who has learned Haskell: Once you learn it, it becomes so stupid easy to do everything. I feel like I can solve more complex problems faster & better in Haskell than other programming languages I have comparable (or more!) experience in.

[verttii]

You mean that decomposing abstractions with substitution works better in Haskell than in a lot of the other languages because programs in Haskell are essentially (pure) functions and abstractions are built by composing functions?

[whateveracct]

Yeah - referential transparency is what allows it to Just Be Substitution.