<div dir="ltr">Alain,<br><br>I am fairly new to Erlang but have considerable experience in other languages. I agree with you. In every case where I have struggled with this issue in Erlang, it has come down to poor code structure, and refactoring solved the problem. Erlang code that I have read which was written by other, more experienced "Erlangistas", generally doesn't seem to have this problem. On the other hand, perhaps using a functional language to express procedural algorithms is not always a good fit. I am thinking of code, of which there seems to be more than a little, which has functions named something like possibly_do_this(), or do_this() followed by really_do_this(). Although the code is understandable, and I am guilty of doing the same thing, it feels a bit unnatural at times.<br>
<br>Perhaps the real issue is thinking procedurally in a functional language.<br><br>Then again, due to my relative lack of  experience with Erlang (and functional languages in general), maybe I have just not seen or written enough Erlang code to warrant giving an opinion on this.<br>
<br><div class="gmail_quote">On Sat, Jul 26, 2008 at 6:54 PM, Alain O'Dea <span dir="ltr"><<a href="mailto:alain.odea@gmail.com">alain.odea@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On 26-Jul-08, at 6:47 PM, James Hague wrote:<br>
<br>
>> Imagine this:<br>
>><br>
>> X = tl(L),<br>
>> ... many messy lines ...<br>
>> *X = tl(X),<br>
>> ... another many lines ...<br>
>> *X = tl(X),<br>
>> ... another many almost unreadable messy lines ...<br>
>> sensitive_usage(X), % <--- buggy X value observed here<br>
>><br>
>> And my question is, where Value of X came from? It goes from L, but<br>
>> how long<br>
>> it take and how many errors you can do when you will investigate?<br>
><br>
> It's just as bad when there's code like this:<br>
><br>
> T2 = something(T),<br>
> T3 = something(T2),<br>
> T4 = something(T3),<br>
> T5 = something(T4),<br>
> T6 = something(T5)<br>
><br>
> You may laugh at that code, but it's hardly uncommon, even in code<br>
> written by experienced programmers.  It's very easy to accidentally<br>
> use T4 in a spot when you meant T3, or to have to renumber things and<br>
> make a mistake.<br>
><br>
> Please note that I am not arguing for changes in Erlang.  I truly am<br>
> not.  But I can understand why this request comes up regularly.<br>
><br>
> James<br>
<br>
<br>
</div></div>Erlang should not introduce mutable variables because they make it<br>
easy to disguise a variety of code smells as clean code.<br>
<br>
Code like James' example is code that does not express its intentions<br>
clearly. The fact that it is common demonstrates a common problem with<br>
code quality, not a need to modify Erlang. Poor expression of<br>
intentions complicates analysis for someone reading the code, even the<br>
original author.<br>
<br>
Numeric increments of a variable name is a code smell that indicates a<br>
need for refactoring, not a need to modify Erlang to disguise code<br>
smells.<br>
<br>
If you give semantic names to each transformation applied to the data,<br>
then the code will express its intentions clearly. When you express<br>
your intentions clearly you avoid a lot of bugs. Subsequent<br>
refactoring work is also made easier, especially when the original<br>
author is unavailable.<br>
<br>
Mutable variables make it easy to disguise a variety of code smells as<br>
clean code. For that reason alone, Erlang should not introduce mutable<br>
variables.<br>
<br>
There is a lot of history behind Erlang not having mutable variables.<br>
There are fundamental reasons scientific reasons not to have<br>
mutability in a programming language. The most intuitive of these is<br>
that (to quote Joe Armstrong) single assignment is like algebra. X = X<br>
+ 1 makes no sense. Allowing it in a programming language makes it<br>
easy to unintentionally hide intentions. More importantly it makes<br>
reasoning about your program more difficult and severely complicates<br>
concurrency and closures.<br>
<br>
Does anyone here still think that Erlang should add mutable variables?<br>
<div><div></div><div class="Wj3C7c">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)<br>
</div>