https://discourse.haskell.org/t/new-blog-post-haskell-doomed...
I honestly think this is/was an idiotic move; especially since the alternative reading 'avoid "success-at-all-cost"' is not thaaat much better, like (from the second link):
"An example is I/O. For literally years Haskell had no I/O to speak of; more precisely, I/O was unreasonably difficult. For practical utility that was pretty inconvenient. But we stuck to purity…"
I mean, would you want to rest your business on such an attitude? (Which is a great attitude, also gave monads, explained in the link, and advanced the language while keeping it pure). I am not saying a language/environment has to be business friendly, but if you want businesses to use it, it better be.
Haskell started as a research language by academics, for academics. Business concerns have not been a large concern in its language evolution. That's fine IMO, it's good to have a place where CS researchers can experiment relatively freely without having Big Corporate Stakeholders demanding absolute backwards compatibility for all time (see Python 2->3 for an example of that).
The best parts of Haskell have slowly been copied by other languages (for example: typeclasses became traits in Rust, list comprehensions are in Python, goroutines look a LOT like Haskell threads, etc), while the experiments that didn't work out as much (lazy I/O for example) just don't get copied.
"It's no good for business" just misses the point of a research language completely IMO. That said, some people want to make it more business-oriented and have been making strides towards that goal. Haskell does not really have a BDFL, so anyone can (try to) move the ecosystem in any direction they wish.
From a business pov, the idea would be to assess whether you're happy with what can be done in userland rather than expect syntactic or semantic changes. I can't think of a company that started doing haskell waiting for future features to be added in the language.
Anyway, removing the parenthesis makes it clear that the operations are associative. Otherwise the phrase would be wrong, and Haskell developers really dislike that kind of wrong.
I was saying that the Haskell people were unapologetic (and obviously tongue-in-cheek)... and that one perhaps shouldn't expect massive commercial success when the people in charge obviously weren't going for that.
It's seen adoption among at least a couple of large companies: Standard Chartered, and Facebook uses it to make a DSL for spam filtering. The key point for at least those adopters is that it has a fast turnaround time for quickly changing code and still having it be correct.
Is this objective data? No, certainly not, but it's probably better than pure speculation.
I personally speculate that it has a lot to do with what type of problem you're solving. If you're solving difficult/intricate problems language matters a great deal, but if you're just doing CRUD the language choice probably matters much less. Or if, as above, you're working in a domain where being correct the first time matters a lot.