4 ms·

It's more of a problem with OOP language because the function call might hide a side-effect. So now the reader has to go and read the function definition to mak

It's more of a problem with OOP language because the function call might hide a side-effect. So now the reader has to go and read the function definition to make sure no side-effect is happening in there. With functional languages the mutable data is available in the reader's context. The implementation might still be mysterious but hopefully the function name is good enough to give a clue about that.

mikekchar 7y ago
I'm just being a bit grumpy, but there are non-pure languages that aren't OOP, and there is no reason why you can't write OO code that is where all objects are immutable. However, it is a good point that mutability is a major problem. It's just not correct that this has anything to do with OOP.
- zimbatm 7y ago
  Fore sure. I was painting a large brush and you can find instances of mutability in functional languages and subsets of OOP that are immutable. Things like value objects, the builder pattern, dependency injection, ...
  - mikekchar 7y ago
    Possibly you aren't aware, but both FP and OOP are orthogonal to mutability. There are lots of mutable FP languages (for example, the first one ;-) ). These days it is popular to make pure FP languages, but that was not the case 40 years or more ago. Similarly, Alan Kay had quite a lot to say about mutability in Smalltalk. I'm not aware of any pure OO languages, but very few people knew how to deal with persistent data structures until Chris Okazaki's PhD thesis on the topic ~1996, if I remember correctly. Mutability is really up to the programmer. Even in C++ you can have const data structures and even const functions -- which are guaranteed to be pure. C++'s mistake was that it didn't make const the default; a mistake that Rust corrected. Back in the 90's all of my C++ code had const strewn all over it -- it was on practically every line. It was really clear to those of us doing it that you had to separate your "const" code from your "non-const" code because if you ever decided to omit that "const", it would rot your entire code base in a very short time frame -- mutability is really contagious. I know it's popular to hand-wave and say, "Well most OO programmers don't write immutable code and lots of design patterns depend on mutability so therefore OOP is defacto-mutable while FP is defacto immutable", but this really obfuscates the true nature of the issue. There are programmers who prefer to write mutable code (in any paradigm) and those who prefer to write immutable code. It's quite easy to write OO code in an immutable way and most statically typed OOP languages even give you tools to help you do it. The reality is that many programmers just don't care. Of course, those programmers never reach for a pure FP language, but there are still heaps of old school FP programmers who would never write immutable code (I know several personally). Perhaps you knew all that as well, but if so, I would ask a favour that you don't say "OOP is mutable" because it is highly misleading for people who don't understand the issue well (and frustrating for programmers like me who enjoy writing immutable OO code).
- ChrisSD 7y ago
  Yep. And it's not necessary for a language to be pure to get that benefit on a per method basis. Rust is OOP but you define in the method signature whether or not that method mutates state. So if a method has the signature that includes `&self`, you know it doesn't mutate. Whereas `&mut self` indicates that it does (or at least could).

mikekchar 7y ago

I'm just being a bit grumpy, but there are non-pure languages that aren't OOP, and there is no reason why you can't write OO code that is where all objects are immutable. However, it is a good point that mutability is a major problem. It's just not correct that this has anything to do with OOP.

zimbatm 7y ago
Fore sure. I was painting a large brush and you can find instances of mutability in functional languages and subsets of OOP that are immutable. Things like value objects, the builder pattern, dependency injection, ...
- mikekchar 7y ago
  Possibly you aren't aware, but both FP and OOP are orthogonal to mutability. There are lots of mutable FP languages (for example, the first one ;-) ). These days it is popular to make pure FP languages, but that was not the case 40 years or more ago. Similarly, Alan Kay had quite a lot to say about mutability in Smalltalk. I'm not aware of any pure OO languages, but very few people knew how to deal with persistent data structures until Chris Okazaki's PhD thesis on the topic ~1996, if I remember correctly. Mutability is really up to the programmer. Even in C++ you can have const data structures and even const functions -- which are guaranteed to be pure. C++'s mistake was that it didn't make const the default; a mistake that Rust corrected. Back in the 90's all of my C++ code had const strewn all over it -- it was on practically every line. It was really clear to those of us doing it that you had to separate your "const" code from your "non-const" code because if you ever decided to omit that "const", it would rot your entire code base in a very short time frame -- mutability is really contagious. I know it's popular to hand-wave and say, "Well most OO programmers don't write immutable code and lots of design patterns depend on mutability so therefore OOP is defacto-mutable while FP is defacto immutable", but this really obfuscates the true nature of the issue. There are programmers who prefer to write mutable code (in any paradigm) and those who prefer to write immutable code. It's quite easy to write OO code in an immutable way and most statically typed OOP languages even give you tools to help you do it. The reality is that many programmers just don't care. Of course, those programmers never reach for a pure FP language, but there are still heaps of old school FP programmers who would never write immutable code (I know several personally). Perhaps you knew all that as well, but if so, I would ask a favour that you don't say "OOP is mutable" because it is highly misleading for people who don't understand the issue well (and frustrating for programmers like me who enjoy writing immutable OO code).
ChrisSD 7y ago
Yep. And it's not necessary for a language to be pure to get that benefit on a per method basis. Rust is OOP but you define in the method signature whether or not that method mutates state. So if a method has the signature that includes `&self`, you know it doesn't mutate. Whereas `&mut self` indicates that it does (or at least could).