But are they more productive, get shit that we care about done, or do they go down monadic rabbit holes?
By all means Haskell away in your pet projects, but having a company invest into a team to deliver things customers want, I'd like to see some evidence this makes sense outside specific niche areas (Cardarno possibly being a good example where it makes sense).
But I’ve seen way more useful software fall down the show off well in C++ than in Haskell.
I think it was Thompson or Ritchie who said: “debugging code is twice as hard as writing it, so be half as fancy when writing as you could be.”
And your spot on with the C++ reference, but there its more the case the language was adopted in industry then it expanded into intellectual twiddling, Haskell has that as its starting point.
Don't get me wrong I like programming in Haskell, C++ and others, I enjoy going beyond what I need to get the job done and amusing myself in doing things 'clever' ways. But no longer being paid to write the code and having different concerns to manage, its hard to qualify Haskell as a good choice.
I never agreed with the conclusion. Clearly the observation implies that you should use all your brain power to write your code in such a way that it is easy to read, understand and debug.
That often means using eg the right abstraction for the job. Not the dumbest one.
The problem really nice abstractions have is that they encode too much into too little code. They are very concise, and people who aren’t as knowledgeable (avoiding the word “smart” here as I think it’s wrong) will treat it as “magic”. Magic in code is a really bad idea when you need to debug it. The ML type system can create these magic moments that make someone who actually wants to understand how the hell that works have to go down a multi-hour rabbit hole just to figure it out. The best example of this that I’ve directly worked with is Finagle. If you look at the code for it, you’re very often left scratching your head trying to understand how it manages to get so much done with so little code. Having been there while it was developed, I will say it didn’t start off that “pretty”, it got there over 3 fairly major revisions to the underlying type abstractions. The result is beautiful, but opaque to most of the mere mortals that use it.
I would argue that Go has been successful largely because everything that’s happening is “out in the open”, where the average developer can see it. It’s a very different philosophy, one that I think the quote-creator aligns with better than your typical Haskell devotee.
I think there's a balance to be struck between "getting shit done" and "write something that will be maintainable in the future".
It might be true that (some?) Haskellers overdo it, but I've definitely seen enough of the "let's just get shit done" people who create messes that are completely unmaintainable and full of bugs after just a year or two.
And IMHO, the software industry is in a really sorry state, considering how bug-riddled most software is, how most software projects fail or are considerably above budget, etc. [1]
I've seen quite a number of failed projects in the companies I've been so far, a number of them involving quite a lot of resources. I've seen companies trying to rewrite hopeless messes and failing at it, grinding everything to a halt, because the code base is full of implicit assumptions that nobody bothered to properly specify anywhere. I've read about Shopify spending a whole year to upgrade to a newer version of Ruby on Rails.[2]
Probably the industry doesn't yet know how best to find this balance but I don't think that the Haskellers are solely to blame for this.
[1]: https://danluu.com/everything-is-broken/
[2]: https://shopify.engineering/upgrading-shopify-to-rails-5-0
