[meindnoch]

While I consider Uncle Bob a bad programmer, there is some merit to this article. This paragraph was particularly prescient:

>But before you run out of fingers and toes, you have created languages that contain dozens of keywords, hundreds of constraints, a tortuous syntax, and a reference manual that reads like a law book. Indeed, to become an expert in these languages, you must become a language lawyer (a term that was invented during the C++ era.)

And this was written before Swift gained bespoke syntax for async-await, actors, some SwiftUI crap, actor isolation, and maybe other things, honestly, I don't even bother to follow it anymore.

[pydry]

I agree, but i think his point applies more to haskell than, say, kotlin. There is a balance between type strictness and productivity and if you go too far in one direction you get horribly buggy code and if you go too far in the other direction you have a language that is grindingly slow to develop in.

Another thing I dont think a lot of people appreciate either is that types have sharp diminishing returns catching the kind of bugs tests are good at catching and vice versa.

[raverbashing]

Yeah once you get into Monofunctor or 'PorcelainPile<static const volatile String&>' lawyering you know you went too far

[mrkeen]

TIL about Monofunctor.

Pretty nifty. It's for cases where your type is a container of something (as opposed to anything).

I.E. you can .map (or .Select if you're .NET-inclined) over the Chars in a String, but not some other type, because String can't hold another type.

https://hackage.haskell.org/package/mono-traversable-1.0.21....

[repelsteeltje]

He has a point in that paragraph, but as a C++ developer I couldn't help being agitated by his passive aggressive comment:

> [...] (a term that was invented during the C++ era.)

...like it's some sort of relic, or was in 2017