> Those specs suck. Whoever asked you this don't understand their own needs, or are struggling with a legacy behemoth that should eventually be replaced.
That may or may not be true, but presumably you're not suggesting that Haskell is unsuitable for writing software for users whose specs suck, or don't understand their needs?
No language is suitable for writing badly specked software. And whatever language you are using, you'll get into troubles if not technical people start to make too many requirements about the way you organize your code (but don't despair, the first such requirement will be to not use Haskell).
"Badly specced" can be a number of things. Some domains have naturally well specified domains, others do not. The business rules of a company, a countries' tax code or building code usually is not an elegant business domain. It's usually a horrible mess of incremental decisions accumulated over decades. Often even logically incomplete or inconsistent.
Of course no implementation can be more elegant than the underlying business logic, the question is: how does the language help me write an implementation that is as nice as possible when the business domain is horrible?
I think Haskell code often looks beautiful but I attribute that not only to it being functional/pure/compact/elegant but also to the code usually being examples of "clean" domains (mathematics, etc.) being implemented in a way that is suited for demonstration, and the fact that it is usually written by excellent developers (who are the ones who tend to preach FP, for good reason).
What I'd like to see are some large-ish real world examples of FP architecture for horrible business problems, not nice ones.
The law is the prime example of horribly messy domains. Thankfully, the law is also human-made, which means it can be changed (at least in principle). We have wasted enough human-millenia already.
This doesn't really excuse the fact that Haskell is a harsh mistress that demands elegance. Many production languages are much more pragmatic about the quality of the spec, the quality of the developer, time constraints, and so on.
This doesn't really excuse the fact that Haskell is a harsh mistress that demands elegance.
I don't know how true that remains for expert Haskell programmers, but I agree that it's the way most introductory to intermediate material comes across.
In academia, you are often looking for the most elegant tool in clean situations.
In industry, you are often looking for the least clumsy tool in messy situations.
Perhaps Haskell is a good choice in one context but a poor choice in the other, at least for those first learning it.
That may or may not be true, but presumably you're not suggesting that Haskell is unsuitable for writing software for users whose specs suck, or don't understand their needs?