[erlang-questions] The Beauty of Erlang Syntax

[Zvi]

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. Simple is better.
Shorter is better.



Ulf Wiger-3 wrote:
> 
> OTP is Erlang-based middleware - how could there not be? 
> 
I would not call OTP middleware, even if according to Wikipedia [1], you can
call it that way.
Erlang/OTP is "marketed" as a single platform, the same way as Java or .NET
platform. It's not like, for example, CORBA which is not part of any
particular language or platform. If somebody can call RMI in Java or
Remoting in .NET - middleware, then I'll call OTP too.


Ulf Wiger-3 wrote:
> 
>  I gather you think reia is great, but for the rest of us, please 
> expand on how reia solves the plain_fsm problem better 
> (not having studied reia, I really have no idea.) 
> 
I do not think, that Reia is better than Erlang or vice versa. Some design
decisions in Reia are better, some worse. For example, no single assignment
is bad. I would rather have ADTs as first-class citizens, instead of
classes. Anyway Reia *is* based on Erlang.



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. 
Not directly related: why Erlang processes have no builtin FSM. It would be
logical, since original problem domain was Complex Soft Realtime Control
Systems. And process anyway have system state (i.e. created, suspended,
died, etc.)


Ulf Wiger-3 wrote:
> 
> is simply an apples and oranges comparison. You know 
> very well (since you love Erlang) that the convention 
> is to hide gen_server specifics behind a module API, 
> so the honest comparison would be 
> 
> MyMod:MyFun(Args) 
> 
> vs 
> 
> MyClass.MyMethod(Args) 
> 
> 
> I fail to see how one is very low level, and the 
> other is not. 
> 
First, I see open source code, that do not hide gen_server specifics behind
a module API. Look at disco project, for example. This is bad software
engineering , but I think the reason behind this is: unneccesary boilerplate
needed for gen_server API definitions. To be fair in your comparison, you
need to write:

-module(my_mod).
...
-export([my_fun/2]).
...
my_fun(Pid, Args) ->
         gen_server:call(Pid, {my_fun, Args}). 
...

% user code
my_mod:my_fun(Pid, Args) 

vs 

MyObj.MyMethod(Args) 


my mistake, maybe it's not low level, but too much clutter/boilerplate for
sure.


Ulf Wiger-3 wrote:
> 
> Congratulations on getting paid to do this,
> 
Just to clarify: I'm not getting paid to bash Erlang. Sorry if somewhat
misunderstood it that way. I was getting paid to be a devil's advocate in
the design and implementation stage of other products (not related to Erlang
whatsoever) - think brainstrorming (as someone told me - "so what I say
stupid things - it's allowed in brainstroming" :)
Actually I think it will be a great accomplishment for Erlang, if there will
be paid Erlang bashers, funded by Microsoft or Sun :)


Ulf Wiger-3 wrote:
> 
>  but apart, from that, what do you hope to accomplish?
> 
I was just responding to the Steve's original message, who unconditionaly
loves Erlang, that's all.
I'm a little bit critical on everything :)

For my little problem of doing everything from the shell. I guess maybe,
it's possible to write some generic Y-combinator. There was some suggestion
on the list before - need to find it.

To summarize: since I'm nowhere as smart or capable as Erlang/OTP creators,
and I'm unable to create something better. I have no other choice, than
contunue to use it.
I'll monitor Reia progress and maybe will use it for prototyping and
embedded scripting for Erlang.


[1] http://en.wikipedia.org/wiki/Middleware

-- 
View this message in context: http://www.nabble.com/The-Beauty-of-Erlang-Syntax-tp22179816p22244249.html
Sent from the Erlang Questions mailing list archive at Nabble.com.