I'd not heard of this before, but apparently some people don't like Erlang's "single assignment" semantics. What this means is a "variable" actually isn't. A variable becomes "bound" to a value via pattern matching. Once bound to a value, that same variable in that same lexical scope cannot be re-bound to some other value. Within that scope that variable must subsequently match successfully against the value it currently has.
What appears to be an "assignment" in Erlang is really just the simplest kind of pattern match. Below
X10 is matched against
foo(X) and since
X10 is not yet bound, it becomes bound to the value of the function.
Some people are concerned this could lead to uncomfortably renumbering variables, say, when the function
f(X) -> X10 = foo(X), X15 = fab(X10), X20 = bar(X15), baz(X20).
fabshould be added in the function above.
I dunno. This seems contrived, or at least rare, or maybe machine-generated. If you just have to "re-number" a few variables, no big deal. If you have to renumber too many variables then you'd be better served by decomposing an overly long function that also suffers from inexpressive variable names.
The author of the post is apparently writing a ruby-ish language for the Erlang runtime. More power to you.
But there is a lot to be said for a simple, mostly functional language that wants you to keep functions short. When I am writing in an imperative, even object-oriented, language, I want my procedures to be short. And I want one variable to have one value. The code is more "tractable" when short, and variables don't vary.
Then the name becomes essentially a mnemonic for the value.
The overwhelming majority of programmers have only used languages with multiple assignment.The overwhelming majority of programmers over my 25+ years of programming experience write procedures that are much too long, even when they are otherwise well-written. That's the first bad habit people seem to adopt, or never learned to avoid. I've worked with long, run-on procedures in every language I've encountered.
Lisp? Yes. Smalltalk? Yes. Pascal? Yes. Even these languages with their gifts for brevity cannot overpower the usual programmer's inaesthetics.
Understanding what many, small procedures do is always better than understanding what one or a few long, run-on procedures do. The payoff is there because you learn what you can put aside, and what you should pay attention to. On the other hand, long, run-on, convoluted noise is always with you. You never can put any of it aside - you have to revisit, remember, and ultimately revolt and/or refactor.
In an imperative language a variable should take multiple values only as part of an iterative statement. In the statement "
for i = ..." the variable
i should only be updated by this statement. Or in "
while someCondition ..." the variable
someCondition should be assigned an initial value before the
while and it should be updated immediately before the
while re-evaluates its decision to iterate again.
Write short functions. Use the shortest name that yet conveys the meaning or purpose of its value. Assign them once even if your language is imperative. Generally this will keep your stress level low, as well as the levels of those who pick up your code later.