[tathougies]

> Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator.

Haskell had ad-hoc polymorphism way before Java was a twinkle in its creator's eye. Before Haskell, Miranda (the language Haskell was based off of) could have kicked Java's polymorphism to the curb. Neither Java nor OOP invented polymorphism. If anything, they butchered it by introducing subtyping.

> Do Haskell programmers not create mocks to test external components?

The equivalent in Haskell would be having some kind of 'effects' system. An effect system differs from a mock object in that it limits in its totality what kind of interactions can take place. Typically, each layered effect also has a set of laws. Pure interpreters can be written for these effects, but the impure (i.e., real-world) interpreters are not privileged in their consumption of this effect. The pure interpreter also provides a proper implementation, such that you should be able to replace your real program with all pure interpreters, supply all your input at once, and still have a correct program. In other words, a Haskell program is typically polymorphic over which effects it uses in a way that other languages simply aren't.

> Encapsulation: You definitely want encapsulation if your data is mutable.

Again, Haskell, Miranda, and Lisp had encapsulation long before OOP came about, and Lisp has mutable data.

[mgummelt]

I think we're in violent agreement here. AFAICT, the feature sets of OOP and non-OOP languages have converged so much that inheritance is really the last differentiator. Maybe you could throw dynamic dispatch in there, but there's no reason in principle an OOP language couldn't add dynamic dispatch.

[macintux]

Mutability is a huge differentiator for some languages.

And dynamic dispatch is already part of Smalltalk and Objective-C, I believe.

[mgummelt]

Sure, but mutability is orthogonal to OOP.

[macintux]

As fond as I am of Erlang, I still find it hard to picture an immutable OO language.

[kbp]

> I still find it hard to picture an immutable OO language.

Picture an object-oriented procedural language like Java, and then make everything immutable; for every 'void' method, return an updated copy of 'this'; for every non-void function, return a tuple of the updated copy and the value you were going to return. No change to const methods, obviously. And you're done, and you can still take advantage of encapsulation, polymorphism, and inheritance without any hoops. You can even do it in Java itself as a style thing without too much effort and only a modest amount of boilerplate. Alternatively, it's not that much work to build this same thing out of lambdas and dictionaries, if your language has those but not objects (adding mutation into that object system would then be trivial) (and of course, you can build dictionaries out of lambdas and lambdas out of objects, if need be).

[mgummelt]

Write in scala using only "vals" and there you have it!

[lgas]

Not quite because you can still have a val that points to a mutable object.