[rprospero]

While I love what Haskell has done for me as a programmer, I don't think that it's finding the true semantics behind our problems. I rather think that it's finding a different basis. To take an analogy, monads and lambda calculus are like Fourier series. For many classes of problems, they produce a cleaner, simpler understanding of the solution. I'd hate to try and solve a boundary value problem with just Taylor series. However, while expressing linear functions with Fourier series is possible, it's less clear than the Taylor series and you're more likely to mess it up.

In the same way, monads, arrows, and recursion are great ways of describing many classes of programs. Additionally, they help with communication when your problem is a monad or an arrow. However, certain classes of problems are better described under other paradigms than being forced into the functional one.

This comes back to Carmack's point. It's important to know Haskell, since it's distilled computation down to a set of elements which are useful for describing a large class of problems. Being able to communicate these solutions is important. However, other paradigms are less error prone and do communicate solutions more clearly on other classes of problems.

[nightski]

I agree, but do not boil down Haskell to Monads. The most interesting abstractions are the ones you write. The only contribution Haskell has here is a flexible type system. It does not give you anything for free per se.

Rather, what I am saying is I see a trend in the Haskell community where the developers strive to find the best semantics for a problem and not just stop at the first arrived at solution because it works.

See all the conversations on pipes vs. conduit if you want an example.