[erlang-questions] The Beauty of Erlang Syntax

[Joe Armstrong]

On Thu, Feb 26, 2009 at 4:25 PM, Zvi <exta7@REDACTED> wrote:
>
> Steve,
> you definitely at drinking kool aid stage.
>
> I love Erlang, it's practical language, but it's syntax and semantics can't
> be called beautiful.

yes they can :-)

> The biggest problem is overlap and impedance mismatch between various levels
> of the language/platform:
>
> 1. i.e. sequential/functional Erlang:  MFA
> 2. processes and message passing
> 3. OTP gen_server

It's nit an impedence mismatch - it was designed to be like this


> i.e. I can write:
>
> Res = my_mod:my_fun(Args)
>
> or
>
> Pid = spawn(my_mod, start),
> Pid ! {my_fun,Args},
> Res = receive Res -> Res end.
>
> or
>
> {ok,Pid} = gen_server:start(my_mod,[],[]).
> Res = gen_server:call(Pid, {my_fun, Args}).
>
>
> compare this with Reia:
>
> Res = MyClass.MyMethod(Args)
>

The multitude of ways of doing things in different ways is a good
thing - imagine
you want to write a function call that dispatches seven messages and
waits for at least four replies
and then returns (this might for example, be a fault-tolerent store,
you keep an odd number of copies
and when more than half have replied you continue)

If you only had a synchronous RPC the code to do this would be a mess.

The problem with RPCs is that the reply gets back to the sender - not
somebody else.
How do you do "compute this, but don't tell me the answer, send the
result to somebody else"
with synchronous RPCs - you can't.

How do you handle failures in the middle of an RPC? - the erlang answer is easy

How would you do this in Reia?

At the bottom layer you have ! (send) and recieve

The next layer provided library functions for RPCs

rpc(Pid, Request) ->
      Pid ! {self(), Request},
      receive
             {Pid, Response} -> Response
      end.

(this is all gen_server:call does - ( actually it does a bit more ...))

If you don't like it, you can roll your own mechanisms.

95% of the time standard synchronous RPCs will work - but not all the
time, that's
why it's nice to be able to open up things and muck around at the
message passing level.

"normal RPCs where nothing goes wrong are easy to deal with" add time
and failures then life gets difficult - Erlang was designed to be
*possible* (not easy) to handle time and failure in a not
too painful manner.

In the real world there are only messages - photons etc.

       that's the way the world works
       that's the way Erlang works,
       that's the way .. boom boom .. we like it clap clap

(Can somebody set this to music)

/Joe Armstrong

> Another big problem with Erlang, that, while it makes implementation of hard
> things easy,

Great

> the easy things are sometimes hard to implement in Erlang.

Like what?

>
> Zvi
>

/Joe Armstrong

>
>
> --
> View this message in context: http://www.nabble.com/The-Beauty-of-Erlang-Syntax-tp22179816p22226430.html
> Sent from the Erlang Questions mailing list archive at Nabble.com.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>