3 ms·

Immutability was never incompatible with OOP, just the opposite in fact. Even Alan Kay often criticized languages like C++ and Java for encouraging the use of s

Immutability was never incompatible with OOP, just the opposite in fact. Even Alan Kay often criticized languages like C++ and Java for encouraging the use of setters and, thus, “turning objects back into data structures”. C# is still one of my favorite languages (even though I use F# most of the time now), but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; it's too bad that fact was lost on so many programmers. Kudos for sharing the Rich Hickey video; it's one of my favorites of all time.

azth 12y ago
> but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; Out of curiosity, how does it do that? As far as I know, everything in Java is mutable by default.
- noblethrasher 12y ago
  You have to go through the extra ceremony of writing a setter.
  - azth 12y ago
    The same applies to C# though, correct? Plus, I was thinking more of the lines of something like: class Foo { private int x = 0; public void bar() { this.x += 1; // Whoops! } } Foo x = new Foo(); x.bar(); // Mutating call. Which Java does not prevent.
    - noblethrasher 12y ago
      Yes, the same applies to my beloved C#, but that language was much less hostile to immutability. Indeed, the prettier mutator syntax was even positioned as a feature once upon a time. To be clear, I'm the guy that insists on defining classes as either abstract or sealed, and almost always marks fields as readonly. But, I'm okay with the kind bounded mutability that you mentioned; clients of a `Foo` instance have to treat it as immutable. Here is how I do OOP: * I make classes to hide state, and hidden state is the same as being stateless. * As I learn more about the problem, I start subdividing classes into smaller classes (not necessarily via inheritance). * So, as my understanding of the problem increases, the number of class division increases, and by the pigeonhole principle, the amount of state approaches zero.

azth 12y ago

> but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; Out of curiosity, how does it do that? As far as I know, everything in Java is mutable by default.

noblethrasher 12y ago
You have to go through the extra ceremony of writing a setter.
- azth 12y ago
  The same applies to C# though, correct? Plus, I was thinking more of the lines of something like: class Foo { private int x = 0; public void bar() { this.x += 1; // Whoops! } } Foo x = new Foo(); x.bar(); // Mutating call. Which Java does not prevent.
  - noblethrasher 12y ago
    Yes, the same applies to my beloved C#, but that language was much less hostile to immutability. Indeed, the prettier mutator syntax was even positioned as a feature once upon a time. To be clear, I'm the guy that insists on defining classes as either abstract or sealed, and almost always marks fields as readonly. But, I'm okay with the kind bounded mutability that you mentioned; clients of a `Foo` instance have to treat it as immutable. Here is how I do OOP: * I make classes to hide state, and hidden state is the same as being stateless. * As I learn more about the problem, I start subdividing classes into smaller classes (not necessarily via inheritance). * So, as my understanding of the problem increases, the number of class division increases, and by the pigeonhole principle, the amount of state approaches zero.