3 ms·

Oh great. What will you people come up with next? Variableless programming?

gordonguthrie 14y ago
Erlang is mostly IF-less (destructuring pattern matching in function heads) and doesn't have variables. A = 1, A = 2, % fatal error because 1 != 2 So, yeah, variabless programming FTW!
- dragonwriter 14y ago
  Erlang has mutable variables (the process dictionary), it just makes you do more work to get at them instead of immutable ones and prevents them from being directly shared and causing synchronization problems.
  - gordonguthrie 14y ago
    No, the process dictionary is not a mutable variable - there is no natural idiom to use values stored in the process dictionary as variables in code, you have to get them out and put them in via immutable variables. Any given Erlang process has meta-information about itself, how many reductions it has, how big its heap is, which flags are set. These are the global state of the process. The process dictionary allows you to store and manipulate your own global state of the process - and the people (hands up, that includes me) get smart and use it as local state of the programme and then get their bum bitten badly and swear never to dance with the dark side again... :( Not bitter :)
- 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 ago
    These 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.
tikhonj 14y ago
Yep. It's called "functional programming" and it's pretty froody. You should check it out.

Erlang is mostly IF-less (destructuring pattern matching in function heads) and doesn't have variables. A = 1, A = 2, % fatal error because 1 != 2 So, yeah, variabless programming FTW!

dragonwriter 14y ago
Erlang has mutable variables (the process dictionary), it just makes you do more work to get at them instead of immutable ones and prevents them from being directly shared and causing synchronization problems.
- gordonguthrie 14y ago
  No, the process dictionary is not a mutable variable - there is no natural idiom to use values stored in the process dictionary as variables in code, you have to get them out and put them in via immutable variables. Any given Erlang process has meta-information about itself, how many reductions it has, how big its heap is, which flags are set. These are the global state of the process. The process dictionary allows you to store and manipulate your own global state of the process - and the people (hands up, that includes me) get smart and use it as local state of the programme and then get their bum bitten badly and swear never to dance with the dark side again... :( Not bitter :)
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 ago
  These 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.

tikhonj 14y ago

Yep. It's called "functional programming" and it's pretty froody. You should check it out.