If that's the case then all the people running around praising the ""simplicity"" of golang got the wrong end of the stick completely from Rich's classic presentations.
The thing is, Hickey was entirely right to reject this idea of “Simplicity” being the same thing as “Easy”. But he then decided to conflate in “comprehensible” which it turns out is very much a matter of aesthetics.
Turns out if you really focus on composability above other concerns you get Haskell.
> But he then decided to conflate in “comprehensible” which it turns out is very much a matter of aesthetics.
Did he? I seem to remember a quip in one of the presentations about German not being comprehensible to him being his own problem, because he never learned German.
The problem is his disdain for "easy". It's one thing to create composable building blocks, but frequently, 99% of users will use them in the exact same way, so you might as well produce the easy thing on top of the simple thing, too.
The Clojure tools.build process has this exact problem. It's too low-level, so everyone got to write their own build scripts on top of that to do the same thing as everyone else. Now there's a situation of a 1000s of bespoke build scripts and 3-4 different front-ends, all effectively doing the same thing.
"In my line of work, sister, sometimes a second chance is a chance to mistake the same mistake twice" - State and Main
"Easy" vs "comprehensible" is exactly the trade-off Haskell makes: it might be difficult to learn, but it's easy to reason about once you learn it. (Of course, both sides of that equation come with their own caveats...)
