←back to thread

498 points azhenley | 1 comments | | HN request time: 0.208s | source
Show context
hyperhello ◴[] No.45767863[source]
> I wish it was the default, and mutable was a keyword.

I wish the IDE would simply provide a small clue, visible but graphically unobtrusive, that it was mutated.

In fact, I end up wishing this about almost every language feature that passes my mind. For example, I don't need to choose whether I can or can't append to a list; just make it unappendable if you can prove I don't append. I don't care if it's a map, list, set, listOf, array, vector, arrayOf, Array.of(), etc unless it's going to get in my way because I have ten CPU cores and I'll optimize the loop when I need to.

replies(8): >>45768027 #>>45768166 #>>45768207 #>>45768240 #>>45768356 #>>45769342 #>>45769717 #>>45770340 #
NathanaelRea ◴[] No.45768240[source]
I don't think this is the best option, there could be very hard bugs or performance cliffs. I think I'd rather have an explicit opt-in, rather than the abstraction changing underneath me. Have my IDE scream at me and make me consider if I really need the opt-in, or if I should restructure.

Although I do agree with the sentiment of choosing a construct and having it optimize if it can. Reminds me of a Rich Hickey talk about sets being unordered and lists being ordered, where if you want to specify a bag of non-duplicate unordered items you should always use a set to convey the meaning.

It's interesting that small hash sets are slower than small arrays, so it would be cool if the compiler could notice size or access patterns and optimize in those scenarios.

replies(1): >>45768282 #
1. bbminner ◴[] No.45768282[source]
Right, sql optimizers are a good example - in theory it should "just know" what is the optimal way of doing things, but because these decisions are made at runtime based on query analysis, small changes to logic might cause huge changes in performance.