[ts0000]

As someone strongly favoring a functional or even purely functional approach, I strongly dislike the flood of pro-functional-programming blog posts that attack the straw man of "imperative programming wrapped in classes". I don't want to believe that is what experts of the paradigm consider object-oriented programming. I would love to read an honest comparison of both, judging benefits and cost.

[lolc]

Well said. I think a lot of people are drawn to Haskell because the abstractions are so well integrated. I remember reading the Prelude and muttering "wow so true" all the way. But then I got stuck when designing a first program.

OOP to me is not imperative control flow but about managing responsibilities. What does this object know, what can I ask it to do, what does it need for the job? If I look at my program at the level of for-loops I'm lost in the brush. And granted, sometimes I do miss Haskell's expressiveness in the brush.

[marcosdumay]

> I don't want to believe that is what experts of the paradigm consider object-oriented programming.

Once you get to the scientific literature about the subject (where actual experts reside), it tends to be much more common to see the conclusions of "there isn't any formal difference between OOP and FP languages", or that in Haskell in particular "implements an strict superset of OOP".

The problem is that FP and OOP are ill-defined concepts.

[rienbdj]

Formal differences don't capture how awkward something can be to use. For applied programming this matters. Maybe I can do functional programming in Java, but if it's much more verbose than Haskell and the type checker occasionally falls over then it's not a good choice.

[AnimalMuppet]

In what sense is Haskell a "strict superset" of OOP?

[marcosdumay]

In the sense that you can recreate all the usual OOP syntax and behavior on Haskell. What people only do on practice for very limited extents, because it's not very useful to import those concepts to a language aimed at dealing with pure functions.