[erlang-questions] The Beauty of Erlang Syntax

[Ulf Wiger]

Zvi wrote:
> 
> Ulf Wiger-3 wrote:
>> The point, if there was one, of plain_fsm, was rather that the
>> Erlang language has expressive power that you partially have to
>> give up in order to reap the benefits of behaviours.
>> 
> exactly my point. If there is single OTP-like programming model as a 
> first-class citizen - you don't need to give up anything.

So as I understand it, reia makes a similar simplification
to gen_server (sans some of the boilerplate, perhaps), but
semantically, it will be limited in for complex fsm
programming the same way gen_server and gen_fsm are limited,
which was exactly the reason plain_fsm. Erlang gives you
some goodness while forcing you to add other things yourself.
OTP automates some of that, but also limits your freedom
(which can sometimes be just the right thing, and sometimes
disastrous).

 > Simple is better. Shorter is better.

For multiway FSMs, it's not the boilerplate that's the issue,
it's the semantics. Gen_fsm and gen_server (and by extension,
I would then assume, also reia) offer the wrong semantics.
Gen_server is a great abstraction, but for some things, it's
the *wrong* abstraction. Plain_fsm gives you a different kind
of abstraction, and different tradeoffs.


> 
> Ulf Wiger-3 wrote:
>> please expand on how reia solves the plain_fsm problem better (not
>> having studied reia, I really have no idea.)
>> 
> Reia do not solve FSM per-say. But it provides more consistent
> programming model. Each Reia object is gen_server, adding FSM state
> should be trivial.

...in the same way as gen_fsm is a trivial extension of gen_server.
The core semantics (since you brought up plain_fsm) is still FIFO
run-to-completion message processing, which works well for many
problems, but hurts like a SOB for others, as I illustrated in
http://www.erlang.se/euc/05/1500Wiger.ppt

> Not directly related: why Erlang processes have no
> builtin FSM. 

They do.
The textbook way of writing state machines is to let the
function name signify the state:

idle(S) ->
    receive
        off_hook ->
           lim:start_tone(dial_tone),
           get_first_digit(S);
        ...
    end.

This was the original intent. The problem with building
libraries on top was that selective receive is not
easily parameterized.

 > Actually I think it will be a great accomplishment
> for Erlang, if there will be paid Erlang bashers, funded by
 > Microsoft or Sun :)

In the sense of "there are only two kinds of programming
languages: the ones that everyone bitches about, and the
ones that noone uses"? (Stoustrup, from memory)

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com