Comment by mrkeen
3 years ago
> the state could change from one line of code to the next line
> I no longer remember what was so difficult about it
You or (your libraries) probably stopped mutating things. No mutation means you can rely on values you used several lines ago.
This is the perennial HN discussion whenever the word 'functional' comes up. "But x=x+1 is simple to teach to beginners" is the rallying cry. Well, this is why not.
Also, > the need for locks
This goes away if you don't mutate.
I like to philosophize about the universe, how at every state change a new universe is created. Like if the version of you I see is someone else, almost identical, and the version I interacted with have branched off into a new universe.
yet physical hardware has a finite amount of memory, so at some point you either stop your program of you have to modify a cell you already touched.
Mutation isn't confusing. On its own. Multiple references isn't confusing. On its own.
The observation, which I don't think I saw being made twenty years ago (I could be wrong) is that you shouldn't mix these two things. No multiple references with mutation. In theory you can safely do so in serial programs if you were careful enough, in practice you won't be careful enough and we should write fewer serial programs than we do, so why not reject this outright.
Rust is one particular (and notably successful) attempt to make a programming language about this big idea, but it's the idea in Val and several other newer languages. There are a lot of unknowns about the best way to approach this, but "Just pretend it's not important" is not a correct answer.
My point was simply that at some point the buck stops and someone has to write the code to mutate a memory cell.
Regarding your point, shared xor mutable is nice, but databases are an example of a shared mutable (and even concurrent!) yet safe resource, so other models are possible.
1 reply →