OP was complaining about having to understand Functors, Monoids, etc... like they are nuisances in the way of writing real code. In response 6gvONxR4sf7o and I were saying that programmers really ought to be taught these incredibly useful abstractions. After more than a decade of coding professionally in popular languages and then 4 years of writing Haskell I cannot begin to tell you how amazing it is that we have these abstractions to rely on. There are virtually endless data types out there and instead of having to study each and every one of them I can just look at whether something is a Monoid and immediately know that I can append them and there is a unit. I can look at whether something is a Functor and immediately know that I can map any function over it. I only need to know a few of these generic patterns and "magically" I can write functions that operate on any of the countless data structures out there. This is true code reuse. Not teaching these to future programmers, not exploiting the timeless, powerful knowledge behind these is in my opinion a disservice to them.

I've been writing Haskell for 12 years so I'm aware of the abstractions it offers. At the end of the day though, either we're building a bridge or we're not.

If we're building a bridge (i.e. a distributed database, a real time system, fly by wire system, etc.) Haskell is useless if for no other reason than how it does memory allocation.

Dependent types are also a dead end for building bridges in my opinion. Proving any non trivial invariants is basically impossible in the real world (http://web.archive.org/web/20200113205635/http://blog.parall...).

And even if it wasn't, dependent types are for a program. But our "bridges" aren't programs, they're systems! If there's one thing that the Haskell community don't understand, it's that. The scary issues that crop up in large scale distributed systems aren't from the nodes, they're from the edges. So any system of correctness that is focused on the nodes [i.e. type systems] is avoiding the real issue.

That's the power of TLA+ by the way. By modeling the system, you have a specification that gives you some confidence what you're building is correct before beginning to implement your bridge.

And if we're not building a bridge? The business doesn't really care about correctness, they care about shipping features. Rollbacks are an acceptable cost. Our job is to sit down and bang out a solution to the problem at hand, not build the perfect abstraction to the problem. When we use languages like Haskell, we take that power out of product's hands.

At work we're building a novel DSL and its ecosystem for a specific industry. Not sure if you consider that a bridge or not, the naive part of me likes to think it's akin to one but maybe i'm deluding myself. Of course we could use any language under the sun but imho Haskell is a really great fit for this project. It also helped hiring some truly great talent (I'm the hiring manager for this team so I know first hand). I don't have much experience with TLA+. From the little I know and learnt about it over the years I think it's brilliant which is why i agreed it should be taught and used more. For the record I've also been involved in multiple large-scale micro-service-obsessed projects in the past, none of them used Haskell or TLA+ and they all were a terrible mess of hidden entangled complexity. Not sure if there's any takeaway just an anecdote.