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

[attila.rajmund.nohl@REDACTED]

On Sat, 26 Jul 2008, Alain O'Dea wrote:

> 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.

I disagree. Code like this:
State1 = updateStateSomehow1(State, SomeVariable),
State2 = updateStateSomehow2(State1, SomeOtherVariable),
State3 = updateStateSomehow3(State2, SomeReallyOtherVariable),

quite clearly expresses the intention: update the state.

[...]
> 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.

The problem with detailed semantic names is that they tend to be long.
Given the ugliness of the erlang record syntax you'd soon end up with
experssions like this:
StateUpdatedWithSomeVariable#stateRecord.some_field

instead of the intuitive
State.some_field

which is actually readable and fits on the terminal nicely, unlike the
erlang variant.

 				Bye,NAR
-- 
"Beware of bugs in the above code; I have only proved it correct, not
  tried it."