Hacker News Reader

> 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.

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....

> 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.

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

> 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?

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

> 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.

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.