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

[attila.rajmund.nohl@REDACTED]

On Sun, 27 Jul 2008, Alain O'Dea wrote:

> On 27-Jul-08, at 6:26 AM, attila.rajmund.nohl@REDACTED wrote:
>
>> 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.
>
> What is the actual intention behind updating the state? I would refuse to 
> approve a colleague's code if they argued that its intent was to update the 
> state. I think this is another counter-example that indicates a lack of code 
> quality rather than a real Erlang problem. It is equivalent to saying that 
> the intention of "i++" is to increment "i".

What the above example lacks is meaningful function names, because I
didn't bother to invent some, thinking that people would get it as is.
Imagine that the updateState* have meaningful names and quite possibly
some side effects as well. But they do update the state too.

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