Load bearing materials actually carry significantly higher loads than mud; those Haskell constructs have not even been used to build software as intricate as common industry practice, let alone break new ground. Are they truly more powerful? That's a popular hypothesis among those who are aesthetically drawn to those concepts.
I gave you an example last week, which you are conveniently ignoring. We have millions of lines of Haskell code at Standard Chartered bank. The type safety and purity have helped us build a more reliable and maintainable codebase compared to previous efforts. Ultimately the language is just a tool. If you are not interested in type safety, purity or expressivity then it isn't the tool for you.
I am not ignoring anything. On the contrary: You yourself have said that the kind of software you write isn't any bigger or more complex than similar software written in more mainstream languages, and that you have no evidence of significant bottom line benefit (except claim that your software is more maintainable, but without any metrics). I never claimed that Haskell can't be used to write simple software as well as other languages, or even marginally better (for some definition of better). But the commenter I responded to claimed that those advanced abstractions are analogous to building materials that are used to build much bigger buildings than those possible without them. You have not even made that claim.
No one is interested in type-safety or purity for their own sake (except for aesthetic reasons). I'm interested in better, cheaper software. If Haskell's purity (there are simpler languages with similar type systems) provides that then there should be evidence of that before the claim is made. You have not provided any such evidence, and even implied that you're not even carefully collecting metrics that can be used to construct such evidence.
> I never claimed that Haskell can't be used to write simple software
I can assure you our software is not at all simple. Standard Chartered has industry leading portfolio compression and XVA compute. Barclays has industry leading pricing of exotic derivatives (including pricing on GPUs). Both industry leading solutions built in Haskell on top of frameworks/APIs in Haskell.
> No one is interested in type-safety or purity for their own sake (except for aesthetic reasons).
So are all forms of static verification just aesthetics to you? Or just those offered in Haskell?
> I'm interested in better, cheaper software.
Then hire good people and let them use the tools they want.
The only evidence I could ever hope to offer is that good people build good software. But that would never make an interesting management report.
> So are all forms of static verification just aesthetics to you? Or just those offered in Haskell?
As someone who makes use of formal methods regularly, I am aware of how weak Haskell's static guarantees are. That is not to say they may not be useful in practice, but that's an empirical question, and the one that I'm desperately waiting for answers to.
> The only evidence I could ever hope to offer is that good people build good software. But that would never make an interesting management report.
It also doesn't support the claims made that Haskell makes a significant contribution.
That's excellent. So please publish some numbers so we could estimate the contribution. With so much hype and zero data I think that the skepticism is very well justified.
> The person responsible for our industry leading portfolio compression joined us because we use Haskell.
I have no doubt that some people really like Haskell, but that's not data.
Any of the MLs, really. Their type systems aren't necessarily equivalent to Haskell's, but given the lack of evidence for Haskell's superiority over pretty much any modern language, I doubt those differences make for even a marginal difference. The big thing about Haskell is that it's pure functional. Rust's type system is definitely in that ballpark, too, and maybe even Kotlin's.
