[erlang-questions] Simple Erlang Recommendation (last returned value)

Alain O'Dea <>
Sun Jul 27 00:54:55 CEST 2008


On 26-Jul-08, at 6:47 PM, James Hague wrote:

>> Imagine this:
>>
>> X = tl(L),
>> ... many messy lines ...
>> *X = tl(X),
>> ... another many lines ...
>> *X = tl(X),
>> ... another many almost unreadable messy lines ...
>> sensitive_usage(X), % <--- buggy X value observed here
>>
>> And my question is, where Value of X came from? It goes from L, but  
>> how long
>> it take and how many errors you can do when you will investigate?
>
> It's just as bad when there's code like this:
>
> T2 = something(T),
> T3 = something(T2),
> T4 = something(T3),
> T5 = something(T4),
> T6 = something(T5)
>
> You may laugh at that code, but it's hardly uncommon, even in code
> written by experienced programmers.  It's very easy to accidentally
> use T4 in a spot when you meant T3, or to have to renumber things and
> make a mistake.
>
> Please note that I am not arguing for changes in Erlang.  I truly am
> not.  But I can understand why this request comes up regularly.
>
> James


Erlang should not introduce mutable variables because they make it  
easy to disguise a variety of code smells as clean code.

Code like James' example is code that does not express its intentions  
clearly. The fact that it is common demonstrates a common problem with  
code quality, not a need to modify Erlang. Poor expression of  
intentions complicates analysis for someone reading the code, even the  
original author.

Numeric increments of a variable name is a code smell that indicates a  
need for refactoring, not a need to modify Erlang to disguise code  
smells.

If you give semantic names to each transformation applied to the data,  
then the code will express its intentions clearly. When you express  
your intentions clearly you avoid a lot of bugs. Subsequent  
refactoring work is also made easier, especially when the original  
author is unavailable.

Mutable variables make it easy to disguise a variety of code smells as  
clean code. For that reason alone, Erlang should not introduce mutable  
variables.

There is a lot of history behind Erlang not having mutable variables.  
There are fundamental reasons scientific reasons not to have  
mutability in a programming language. The most intuitive of these is  
that (to quote Joe Armstrong) single assignment is like algebra. X = X  
+ 1 makes no sense. Allowing it in a programming language makes it  
easy to unintentionally hide intentions. More importantly it makes  
reasoning about your program more difficult and severely complicates  
concurrency and closures.

Does anyone here still think that Erlang should add mutable variables?



More information about the erlang-questions mailing list