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.

Taking this as a metaphor, there are times at work where I want to be asocial and work on a project alone. However, my company's culture is to be collaborative and do things in groups. While I can see their goal is to strengthen interpersonal bonds, I find it can be a waste of resources. This can happen mostly in cases where we're solving a new problem as opposed to maintaining a legacy system. When multiple employees are working in a realm where their knowledge is limited, but growing, it can cause wheel-spinning because of other commitments. Sometimes going solo allows you to back out of dead ends more quickly and make progress that you can eventually share with others.