[erlang-questions] The Beauty of Erlang Syntax

[Christian]

On Tue, Feb 24, 2009 at 11:25, Steve Davis
<steven.charles.davis@REDACTED> wrote:
> - Erlang is easy to write... once you know what you are trying to
> achieve. The challenge is that it asks you to think hard about what
> you actually want to do. Once that part is clear, everything becomes
> extremely simple and straightforward. This quality makes this language
> extremely powerful and "cruft-free".
>
> - There can be no doubt lambda calculus is "ultimate".  A more trivial
> way of saying this is that all computer processing is simply
> transforming one bit pattern into another bit pattern f(X) -> X'
>
> - Elegant programming in Erlang is much more of a challenge than with
> OO languages where "what is right" is fairly easy to understand.
> Erlang feeds the creative soul in a way that's just not evident or
> truly possible "in the kingdom of nouns".

While it is nice that you like Erlang, I don't think your arguments
will work very well to convince somebody to try Erlang. You sound more
like http://www.urbandictionary.com/define.php?term=drink+the+kool-aid.

Believe me, there can be doubt about lambda calculus being "ultimate".
This is the internet, and your argument is WEAK.

Phrases like "elegant", "what is right", "creative soul" do simply not
work. Try a Java guy sometimes, they will dislike that Erlang

* is not Java
* is not running on the JVM
* is not equipped with classes nor the object-dot-metod-arglist syntax
* is just plain different and academic for no practical advantage
* is not doing anything you couldn't do with Java using NIO, blocking
queues, and something called osgi they read about in a trade mag but
haven't used personally yet
* is unimportant now that Scala exists
* is unimportant because Kilim is adding cheap actors to Java

... and then continue with weak reasons. The human being is not
rational. The human being rationalizes its irrational choices though.
Argumenting with emotions wont work since they have strong emotions in
favour of OOP already.


I used to think that I liked erlang programming just because it was
quite academic, and that this was just a personal preference. But I
have come to realize that side-effect free programming is easier to
reason about. Not always easier to write though. Being easier to
reason about means that I can imagine more execution in my head than I
can in languages that rebind variables and mutate values. Because
those destructive changes defines a before-change, and after-change,
sequence, order, and there are only so many steps one can keep the
mind without the brain starting to lie to you, filling out the blanks
without telling you.

I recently read an article published in idg.se where Erik Stenman of
kreditor was quoted saying that (something like) java systems grow
complex over time in a way that Erlang does not as much. This is
something I experience with Java systems. In Java there is no cost in
adding more things that keep state. It is said that you just
encapsulate state it in your object, but that state is not as
encapsulated as you think. Problems are fixed by adding more things
with state, and more. and more. Pretty soon you have behavior that
depends on several hundred mutable variables, and the code-base feels
hard to grasp, difficult to reason back into previous code execution
to see the "big picture". It makes architectural fixes more difficult.
And the problems accelerates, since more quick fixes are added. (I
really need to get better at describing this.)

The funny thing is that the OOP world have found one way to manage the
complexity and the code-bases that grow ugly: They are using unit
tests, and practice the art of writing testable code. ("Testable code"
is something that is simple to write unit tests for. )

* You make it very easy to supply the dependencies to code under test
need. Avoid things that go out and grab values from global state.
* You avoid side-effects, and the side-effects you need (database
updates, writing files etc) you make sure that you perform with a
layer of indirection so that during tests you can replace the real
object with (for example) a do-nothing mock.

What they are doing is that they are making as much of their code as
possible to be side-effect free and placing all that code in one
method so it can be called from a unit test. They are concentrating
side-effects to well-defined places, carefully avoiding mixing
side-effects and testable/test-worthy logic.

What they are doing is that they're reinventing functional programming.

PS
Anyone care to make my argument better or shoot it down?