3 ms·
The way I see it, a programming language should... 1) correspond to computer architecture (which excuses the distance from human thinking) 2) correspond to hu
by sublimit 14y ago
The way I see it, a programming language should...
1) correspond to computer architecture (which excuses the distance from human thinking)
2) correspond to human thinking (which excuses the distance from computer architecture)
So what's the excuse for pulling such strange rules out of nowhere? The sort that have no counterpart outside of the language itself? Is it just for the sake of making programming more of a puzzle, or...?
- gordonguthrie 14y agoThese aren't strange rules at all. They are pretty common in functional languages (of which Erlang is one) - less so in procedural, imperative and object-orientated languages. The reason is simple, with immutability you know what the value is, and you can pattern match on it with confidence. Variables that can change value are a mini-version of global state with all the reasoning problems that 'globality' gives: "what is the value at this point in the code?" "when does the value change" "what range of values can this have depending on which code path was executed?" ie sometimes the value is changed and sometimes not... Trust me, once you have gone immutable, you don't want to go back.