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

[Edwin Fine]

Alain,

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.

Perhaps the real issue is thinking procedurally in a functional language.

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.

On Sat, Jul 26, 2008 at 6:54 PM, Alain O'Dea <alain.odea@REDACTED> 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. 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?
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
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.
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080726/6bae25bf/attachment.htm>