The content of the article makes it abundantly clear the author isn't talking about "understand thing," but rather specifically "understand Haskell." These aren't identical.
I didn't take it as that. I think his argument translates to other functional languages to some degree. I was working on a Scala project where the lead developer exhibited the exact behavior the author describes. Scala is a bit more "useful" than Haskell because it borrows from Java, and it's not too much of a leap to write something you can use. Opening a file in Scala and processing it is much less of an understanding task than it is in Haskell.
The "understand first, then use" aspect of many functional languages is what kills systems in the crib when you're trying to build something that provides business value.
> The "understand first, then use" aspect of many functional languages is what kills systems in the crib when you're trying to build something that provides business value.
This notion that one must "understand first, then use" is limited strictly to the particulars of the language. It's equally true of other languages: one must understand at some level how the language works to build anything with it.
It also isn't clear how having to understand Haskell and having to "understand thing" are the same thing, as the author asserts.
An uncharitable reading of the article is that it's a sophomoric insult to people who don't use Haskell, as it apparently dismisses them all as people who don't care to understand things but only to more or less mindlessly and practically randomly build stuff. I surely hope that wasn't the intent.
I don't see that at all. To me it was clearly about how using a language that is designed to be correct rather than useful/ simple places more responsibility on the coder to think about the entirety of their problem before digging in.
We can agree to disagree. I see no evidence to support your generalization in the article.
It's also a contentious assertion besides, since the implication is that people who don't use "correct rather than useful/simple" language don't "think about the entirety of their problem before digging in."
I’ve encountered multiple times that Haskell has forced me understand exactly what I was doing, otherwise the parts wouldn’t fit together, or I’d end up writing huge amounts of duplicate code. I’ve never encountered this in another language.
I can't see most "Info Services" type management buying into something requiring that level of effort prior to having anything to show for it. Right or wrong, just sayin'.
It definitely depends on the cost of failure. If it’s 30 minutes of downtime, it might not be worth it. But if it’s losing all customer funds, it’d be irresponsible not to put this level of effort into it.
Whether you understand a problem completely is independent of your choice of language to implement it in. The notion that Haskell is allegedly requires complete understanding first where other languages don't is both unsupported and also irrelevant. The implication that "Haskell people" seek to understand things first while other language users don't is an assertion at best (and that's being charitable).
