> Being OO has nothing to do with mutability/immutability
It does if you are using OO to represent state - which most OO programmers do. For things like UI stateful code is often the simpler solution. However for large, large swaths of a program using stateful objects is a complexity bog.
The real question here is whether programmers will bring their stateful OO habits and recreate them in Scala.
When I was first learning Clojure I started by creating an object system. And then I realized I was entirely missing the point as well as going against the grain of the language- functional programming is palpable in Clojure's design.
If an object maintains state you can't generally view it as an immutable value- that's another benefit to Clojure's approach. You generally design your program around the idea value -> function -> new value (_not_ same object with a different internal state). The transparency of this is quite enlightening.
In anycase, I don't know enough about Scala to make an informed opinion, but whether Scala's decision to meet OO programming sensibilities halfway is a liability remains to be seen.
I do OOP extensively, and I rarely allow methods to mutate the object. Whenever I have an "is => 'rw'" declaration in my code, it is always immediately followed by a comment along the lines of "XXX: hack". I always feel bad, because it is rarely the right solution.
Even when my data structures are completely immutable, I don't consider myself to be doing "functional programming". I consider it "avoiding stupid bugs".
(As an aside, when using an object database, I am a bit more liberal. You shouldn't need to rewrite every object in the system when a user changes his password, after all. This does come at a cost, though; there is no way to "go back in time" and find an old object graph. There is the current one, and that's it; hope you didn't mess it up...)
It does if you are using OO to represent state - which most OO programmers do. For things like UI stateful code is often the simpler solution. However for large, large swaths of a program using stateful objects is a complexity bog.
The real question here is whether programmers will bring their stateful OO habits and recreate them in Scala.
When I was first learning Clojure I started by creating an object system. And then I realized I was entirely missing the point as well as going against the grain of the language- functional programming is palpable in Clojure's design.
If an object maintains state you can't generally view it as an immutable value- that's another benefit to Clojure's approach. You generally design your program around the idea value -> function -> new value (_not_ same object with a different internal state). The transparency of this is quite enlightening.
In anycase, I don't know enough about Scala to make an informed opinion, but whether Scala's decision to meet OO programming sensibilities halfway is a liability remains to be seen.