I agree there's much confusion about Erlang concurrency being related to it being a functional programming language, when in fact it's due to pure message passing. I think this misconception is because some functional programming features are good for concurrency, and Erlang is functional and is good at concurrency - so one would expected it to use the features of the former to achieve the latter.
I write the following to clarify my own concepts, and seek confirmation/criticism:
Single assignment and debugging: In Armstrong's book, he says an advantage of single assignment is that you know what value a variable has (that it hasn't changed). However, each level of recursion has a different set of instances of the same variables, with different values. I don't think these two cases - rebinding a variable vs. creating a new instance of a variable with a different value - are really that different, except that it is easier to track the path of execution with recursion. In this sense, iteration is somewhat similar to Dijkstra's goto.
Single assignment is mathematical: In my high school, an excellent English teacher questioned a programming statement of mine, that "x = x +1", saying "I don't know much mathematics, but I know that's wrong". For me, this highlights the difference between programming vs. mathematics. Functional programming is more like mathematics in this way, and I feel that people who love functional programming also love mathematics (in the sense of proving theorems etc), and also have a solid education in the fundamentals. It seems to me that "single assignment" in mathematics has deep consequences for proving things - which I am yet to grasp properly.
BTW: Armstrong is definitely a mathematician-type - who else, when asked to design a phone control system, formulates an algebra ?
"I agree there's much confusion about Erlang concurrency being related to it being a functional programming language,"
While the term "functional programming language" is sometimes abused to mean different things, isn't the canonical meaning "functional" == "no mutable state"?
If I've understood his rebuttal correctly, he's not adding mutable state, he's allowing a variable to be rebound to different (immutable) values. i.e. his multiple-assignement language is still functional in the sense above.
The difference is that if you have two bindings to the same value, mutable state means that both bindings see an update to that value.
This wouldn't happen with "multiple assignement and immutable values" (if you reassign the binding of one of the two, the other is still bound to the old value).
I consider the values of a program's variables to be part of its state.
It's somewhat odd (read "probably a mistake") if a variable can be visible before it is bound in a functional language. If the execution model does anything other than block until a variable's binding is available, its bind state is mutable state, with all of the problems that entails.
The reason this does not work in mathematics is because the programming use `=' and mathematical use of `=' are completely different. In programing, `=' implies set which really has no meaning in mathematics as mathematics is only concerned about declaring facts which is what the mathematical `=' does. It declares a fact that the indeterminate "x" is equivalent to some value "y."
so, assuming the declared fact "x = y", whenever you see "x" you could substitute "y" (and vice versa), and it would make no difference whatsoever?
You don't have to worry about whether it is defined yet, or if it has been changed, or if it is really a copy (not a reference/pointer). I intuitively think in terms of an execution model, so this is hard for me (even though it's actually less complex with less to worry about).
Thinking of it as "declarative" seems helpful, thanks...
Good article. This article demonstrates why at some point in a CS course, people need to write their own compiler. So that the points made in the article are largely obvious.
I write the following to clarify my own concepts, and seek confirmation/criticism:
Single assignment and debugging: In Armstrong's book, he says an advantage of single assignment is that you know what value a variable has (that it hasn't changed). However, each level of recursion has a different set of instances of the same variables, with different values. I don't think these two cases - rebinding a variable vs. creating a new instance of a variable with a different value - are really that different, except that it is easier to track the path of execution with recursion. In this sense, iteration is somewhat similar to Dijkstra's goto.
Single assignment is mathematical: In my high school, an excellent English teacher questioned a programming statement of mine, that "x = x +1", saying "I don't know much mathematics, but I know that's wrong". For me, this highlights the difference between programming vs. mathematics. Functional programming is more like mathematics in this way, and I feel that people who love functional programming also love mathematics (in the sense of proving theorems etc), and also have a solid education in the fundamentals. It seems to me that "single assignment" in mathematics has deep consequences for proving things - which I am yet to grasp properly.
BTW: Armstrong is definitely a mathematician-type - who else, when asked to design a phone control system, formulates an algebra ?