Tony Morris

How does OO factor into "modularity and extensibility" that FP can't do? Functions compose far simpler than interfaces/class inheritance The type system doesn't help when most people do not write total functions and doing so is not enforced.

Object generalizes function: multiple "input" (required) / "output" (provided) members, recursion through `this`. Subtyping simpler than existentials (e.g., heterogenous list). Don't ask "can it do it", but "can it do it as naturally"? Why not play to strengths of both paradigms?

Because in my extremely biased opinion, there is no strength to object orientation whatsoever that isn't solved via well supported function composition + typeclasses + algebraic data types. I do not find a benefit in mixing the two whatsoever.

And before a "just go to eta or haskell" argument pops up, the former is extremely young, and the latter has far less job openings.

Then my advice is to "contribute to eta and help it grow" or "create more Haskell jobs". Both are easier than turning Scala into a Haskell. I hope we are clear on that.

so, you have to be a little object-oriented to write Scala?

Isn’t it a consequence of being on the JVM? More exactly, being on the JVM and using libraries w/o a foreign function interface.

not at all. have been doing pure FP in Scala for years. Only OOness used was sealed trait inheritance, abstracting an algebra of operations that may then be implemented with an ‘FFI’ into library (if necessary)