As a sign that Haskell will never be a mainstream language, see this page on their info page. This is the kind of gobbledygook that drives me wild. https://wiki.haskell.org/Zygohistomorphic_prepromorphisms

Here’s an introductory video on the principles involved:

Agreed, but I do love saying zygohistomorphic prepromorphisms in casual conversation. I know I'm not the only one who finds humor in the byzantine verbiage of Haskell. If you're going to toil in obscurity, you should at least make the most of it.

The FP equivalent of JavaEnterpriseBeanFactoryControllerVisitorFactory

Also wow that was written in 2008, when github launched...

I don’t know if the correctness argument is all it’s stacked up to be. I know a few projects where people made things as complicated as possible whilst arguing that it was “correct because of FP.” I’m sure determined socratic questioning would reveal they have no idea if it’s really correct merely so complicated there are no obvious bugs. Those people would have done a better job in Python with better teamwork and far more emphasis on communication. I don’t see how correctness is served through obscurity. I was taught to put clarity first - especially in mathematics and proofs.

The limit of the correctness is that the model is checked via a proof assistant, usually coq based. You can make “correct” programs, it’s just very very expensive. I’m not calling using list comprehensions correctness here; it’s usually some 6k monstrosity written in coq proving a model correct. Then using a “real” programming language (like Haskell, hah) you implement your model, and this can introduce gaps. You could write it in python, but it’s easier to say you’re following your model in a language with more static guarantees like Haskell or Idris though.

@Don Abrams “You can make “correct” programs, it’s just very very expensive” - exactly. The real cost is thinking at that level of precision. Lots of software customers aren’t aware of that level of detail and don’t see the point. It’s very easy for it to come across as obsessing over tiny details that don’t matter. The business model for lots of development work favours writing bugs and heroically fixing them. (“Build my half-baked idea. I can’t be bothered to even notice the gaps and inconsistencies in it or half-describe it but I need it by next week!“… “and although I can’t describe what satisfactory is, I’m holding you responsible.“)

Yep, MTTR over MTBF

Several times I’ve heard technically capable developers (that should know better) tell me “we don’t always have time to finish the story so we just move on…“. What I hear is “We’re under pressure to get this done, so we lie and mark it as complete when it isn’t”. I heard this once on a project I was called into because they had lots of bugs and needed help making it stable - and more recently on an application that’s certified as a medical device. Theorem proving isn’t where our problem is. We have a problem being honest about what it takes to get stuff right. By the time I left the “certified medical device” project I was ill. It’s hard to make assurances building on a pile of things I can’t trust.

Does Haskell want to be a “mainstream language” (whatever that means)? I was keen on learning Haskell not because I hoped for a better language than what I was using at the time, but to expose myself to a radically different set of paradigms and techniques. I wanted to expand my collection of approaches to solve problems and was hoping to transfer some of the ideas that Haskell would inspire back to the languages I knew better and that I found more useful for practical work. And it worked! It’s certainly true for me, although many have expressed that learning Haskell made them a better programmer in whatever language they prefer over Haskell. And that doesn’t just apply to Haskell, but other “extreme” languages as well. I’m glad there is a community of language nerds and computer scientists with a knack for the overly theoretic parts of language design, as much as I’m glad that there are purists and pragmatists that wouldn’t let a static type definition anywhere near their variable declaration — I’m happy to learn from both communities and there's plenty they all have to teach me.

I love those recommendations. It seems very wise and addresses a lot of the problems I’ve seen with overenthusiastic Scala developers. We need to hear more of “identify your complexity budget and stick to it.” A single team with a common codebase needs to agree the same complexity budget otherwise we’re in for a masala of unmaintainable inconsistency.