4 ms·

I think this article is quite old, so I can forgive the author for being out of touch with modern OO language practices. Nonetheless, I find myself disagreeing

by ganonm 7y ago

I think this article is quite old, so I can forgive the author for being out of touch with modern OO language practices. Nonetheless, I find myself disagreeing with almost all of his arguments. When he talks about state for example, I assume he means mutable state. Everyone knows this is best avoided if possible. The vast majority of OO languages provide mechanisms to avoid mutability e.g. data classes or keywords to make references constant. He also rails against private state specifically. I assume again that he means private mutable state. This is generally a bad idea and is accepted pretty uncontroversially as a bad idea. The principle of data hiding in general however is definitely not a bad idea. Being able to enforce scoping rules on classes/functions/members is not meant to facilitate creating 'black box' entities whose internal mutations are difficult to reason about, but is instead meant to provide guarantees about dependencies between different parts of a system, i.e. Separation of Concerns. Regarding 'everything is an object', in many cases this is perfectly acceptable as it guarantees some sort of basic interface that all entities conform to e.g. being able to ask an entity to provide a hash code, or to carry out a comparison check with some other entity. Some modern languages like Kotlin even eschew the concept of primitives altogether and just make everything an object. Finally, regarding his point about OO languages having data type definitions all over the place, I must be misunderstanding something here... Why on Earth would you want all your data type definitions in one place? Anyway, just wanted to give my $0.02 lest anyone get the impression that these are 'knockout punches' against any and all OO languages.

anyfoo 7y ago
> provide mechanisms to avoid mutability e.g. data classes or keywords to make references constant. So, functional programming? > guarantees some sort of basic interface that all entities conform to e.g. being able to ask an entity to provide a hash code, or to carry out a comparison check with some other entity. Isn't that terrible? You want to provide a generic interface to calculate a hash or perform comparison: Now the thing has to be an object! If it's a primitive type, you better wrap it in an object now. If it's an existing class, you have to extend it. It becomes an object of a different class. Or, instead, you could just have type classes to let the same apply to anything whatsoever, as long as it's a type, without the need for it to be an object. Heck, in some cases, the type could be a function instead.
- ganonm 7y ago
  You can represent 'primitives' as objects at compile time and treat them as primitives at runtime. Kotlin does this for example.
macintux 7y ago
> Everyone knows this is best avoided if possible. The vast majority of OO languages provide mechanisms to avoid mutability e.g. data classes or keywords to make references constant. Well, clearly not everyone knows it. My biggest complaint about languages that incorporate functional features is that immutability is most useful when it’s the 99% use case. When it’s a special tag that may or may not be used within the library/code base you’re using, you don’t get the cognitive advantage of feeling confident you can judge the output of a function by reasoning about its input. My brain is small. I need all the crutches I can get, and referential transparency is a huge advantage.
- ganonm 7y ago
  Yes, I agree, I don't understand why modern languages don't make references immutable by default. The best I've seen is symmetry between val and var. Talking about safe defaults, I remember being very disappointed when Jetbrains changed the default scope in Kotlin to be public....
deleted 7y ago
[deleted]
thedufer 7y ago
> basic interface that all entities conform to e.g. being able to ask an entity to provide a hash code, or to carry out a comparison check with some other entity What do you do with values that can't be meaningfully hashed/compared? Java is the only place I've come across this odd idea that everything is hashable, and I've never thought of it as a positive thing.
- ganonm 7y ago
  Well, the problem with a value not having a corresponding hash is that it can't be used in any code that relies upon it having a hash. E.g. in Java, there are many hash based data structures that work for any object as they all have hashes. Even if there is no meaningful hash, by default the memory address can be used. This may mean you don't gain the performance benefits of a hash based data structure, but at least it is compatible with the type system.
AnimalMuppet 7y ago
> He also rails against private state specifically. I assume again that he means private mutable state. This is generally a bad idea and is accepted pretty uncontroversially as a bad idea. Here's a program that has some mutable state. Do you want that mutable state to be private or public? Do you want anybody to be able to change it, or do you want all changes to have to go through public methods? Given that there are programs that necessarily have mutable state, why in the world would you not want that state to be private?
- ganonm 7y ago
  Sorry, I realise on reading that that my response makes it sound like I'm an opponent of making mutable state private. I totally agree with you, what I was trying to say was that mutable state in general is considered as something to be avoided if possible, however, if it is necessary it should be hidden i.e. made private

by ganonm 7y ago

anyfoo 7y ago

> provide mechanisms to avoid mutability e.g. data classes or keywords to make references constant. So, functional programming? > guarantees some sort of basic interface that all entities conform to e.g. being able to ask an entity to provide a hash code, or to carry out a comparison check with some other entity. Isn't that terrible? You want to provide a generic interface to calculate a hash or perform comparison: Now the thing has to be an object! If it's a primitive type, you better wrap it in an object now. If it's an existing class, you have to extend it. It becomes an object of a different class. Or, instead, you could just have type classes to let the same apply to anything whatsoever, as long as it's a type, without the need for it to be an object. Heck, in some cases, the type could be a function instead.

ganonm 7y ago
You can represent 'primitives' as objects at compile time and treat them as primitives at runtime. Kotlin does this for example.

macintux 7y ago

> Everyone knows this is best avoided if possible. The vast majority of OO languages provide mechanisms to avoid mutability e.g. data classes or keywords to make references constant. Well, clearly not everyone knows it. My biggest complaint about languages that incorporate functional features is that immutability is most useful when it’s the 99% use case. When it’s a special tag that may or may not be used within the library/code base you’re using, you don’t get the cognitive advantage of feeling confident you can judge the output of a function by reasoning about its input. My brain is small. I need all the crutches I can get, and referential transparency is a huge advantage.

ganonm 7y ago
Yes, I agree, I don't understand why modern languages don't make references immutable by default. The best I've seen is symmetry between val and var. Talking about safe defaults, I remember being very disappointed when Jetbrains changed the default scope in Kotlin to be public....

deleted 7y ago

[deleted]

thedufer 7y ago

> basic interface that all entities conform to e.g. being able to ask an entity to provide a hash code, or to carry out a comparison check with some other entity What do you do with values that can't be meaningfully hashed/compared? Java is the only place I've come across this odd idea that everything is hashable, and I've never thought of it as a positive thing.

ganonm 7y ago
Well, the problem with a value not having a corresponding hash is that it can't be used in any code that relies upon it having a hash. E.g. in Java, there are many hash based data structures that work for any object as they all have hashes. Even if there is no meaningful hash, by default the memory address can be used. This may mean you don't gain the performance benefits of a hash based data structure, but at least it is compatible with the type system.

AnimalMuppet 7y ago

> He also rails against private state specifically. I assume again that he means private mutable state. This is generally a bad idea and is accepted pretty uncontroversially as a bad idea. Here's a program that has some mutable state. Do you want that mutable state to be private or public? Do you want anybody to be able to change it, or do you want all changes to have to go through public methods? Given that there are programs that necessarily have mutable state, why in the world would you not want that state to be private?

ganonm 7y ago
Sorry, I realise on reading that that my response makes it sound like I'm an opponent of making mutable state private. I totally agree with you, what I was trying to say was that mutable state in general is considered as something to be avoided if possible, however, if it is necessary it should be hidden i.e. made private