I agree with you, although I read your statements as disjoint, as opposed to conditional.
I think the “secondary” value it has created is immense. I’m not a Haskell programmer by any stretch, but thinking in terms of concepts evangelized by Haskell (isolating side effects, first class functions, monads) has totally changed the way many people design systems in conventional programming languages.
So, this may be a learning opportunity for me, but I thought the idea of separating out side-effects at the process boundary is a very old idea. The same for "first class functions". Haskell was invented around 1985. Lisp was 1958, Smalltalk 1972.
Besides, isn't Haskell fundamentally about about lazy evaluation and rigorous type safety?
Haskell enforces function purity (side effect isolation) using the type system. This is relatively novel, neither Lisp nor Smalltalk did it or even tried to do it, as far as I can tell. You could put together lazy values in Lisp manually but Haskell made the entire language lazy by default, and as a result, you couldn’t reliably sequence I/O operations if you tried to “cheat” the type system by giving pure type signatures to functions with side effects. The result was (eventually, in Haskell 1.3) the modern IO monad.
If you were using Lisp or ML, you could write pure code in the core of your program but fall back to impure code wherever you liked, because purity was not ever enforced. This explains why nobody really used stuff like monads in Lisp or ML—it wasn’t practically useful, because you could always just write impure code.
> Besides, isn't Haskell fundamentally about about lazy evaluation and rigorous type safety?
I’d say—no, absolutely not. It’s not about either of those things.
“Rigorous type safety” is kind of an ill-defined concept. I’d say Java has rigorous type safety, but it’s very different from Haskell. The lessons from Haskell is that function purity (side effect isolation) is incredibly useful, and laziness is the historical reason why functions in Haskell had to be annotated with the correct types—because a "print :: String -> ()" would not work in Haskell.
In other words, the fact that Haskell uses lazy evaluation forced the development of type system capable of expressing side effects and sequential operations, and now that we’ve discovered how to do that, we could discard the lazy part and make an eager version of Haskell. Some people have done that, there are a couple eager variants of Haskell out there. They are very recognizably Haskell.
There are a couple other cool things that came out of Haskell’s purity, like software transactional memory. Haskell didn’t invent STM, just like it didn’t invent purity, but Haskell is still the one major success story for STM. The lesson from trying to port STM to other languages is that Haskell’s purity is what made it successful there. Lazy evaluation, in a sense, is just the thing that breaks your program if your functions are not pure, keeping you honest.
Thank you. This was a very informative comment. I knew that Haskell didn't originally have monadic IO but the reasoning behind its adoption never occurred to me.
Yes, the concepts are pretty old. For a lot of people newer to programming, Haskell is the first language that compels them to be understood. That’s what I meant by “popularized”, to clarify. Changed it now to “evangelized”, to make the comment more clear.
I’d typed a whole paragraph on LISP, but deleted it because I’ve seen that whole regurgitation of history play out so many times on HN. :)
My comment was looking at Haskell as the standard bearer for FP, but it’s not of course.
I agree that lazy evaluation and rigorous type safety are what Haskell is best known for nowadays, especially since its less controversial components have found their way into most conventional programming languages by now.
I think the “secondary” value it has created is immense. I’m not a Haskell programmer by any stretch, but thinking in terms of concepts evangelized by Haskell (isolating side effects, first class functions, monads) has totally changed the way many people design systems in conventional programming languages.