[erlang-questions] how to break the problem. the erlang way?

[Essien Essien]

Hi Ovidiu,

On Fri, Jul 31, 2009 at 3:47 PM, Ovidiu Deac<ovidiudeac@REDACTED> wrote:
> I'm doing some evaluation of erlang so I came with the following problem:
>
> "The application has to subscribe to a multicast address and receive
> binary packets. One packet per datagram. Each packet has a lenght, a
> sequence number and a number of messages inside. Packets have to be
> processed in their sequence number order. The messages have to be
> extracted from the packets and written in a file."
>
> I come with C++/Python experience and in OO approach I would have the
> following components:
> 1. A Receiver who connects to the multicast and receives the packets
> 2. An Orderer who's responsability is to order the packets by their
> sequence number and detect the missing ones.
> 3. An Unpacker who's responsability is to unpack the incomming packets
> and extract the messages.
> 4. A Decoder who does the deserialization of the messages
> 5. A Writer who puts the messages in the file.
>
> Now if I move all this to Erlang I would map the objects to processes.
> Instead of having objects with methods being called I have processes
> which receive messages. So the 5 components would run as separate
> processes. Each one does a little job and passes the result to the
> next one.

>From my own limited experience, the OO thought process can not be
matched 1 to 1 to functional programming languages or even a process
centric approach like erlang. My own personal rule of thumbs since
after getting over the rush that is spawn(), and spawn_link() in
erlang, is to remember that nothing has changed, we just have a
"cheaper" way of creating "threads" (this is not 100% true, but its
one way to look at it).

A question to ask yourself above is, would any of the classes you
would create in Python/C++ benefit from being threads, or seperate os
level processes? if yes, then I think you've found a candidate
component to be an erlang process, no... then... still no in erlang...
if well... maybe but not so sure... i suggest you leave it till you
realize it will work better as a process. There's nothing wrong with
just making function calls in erlang... everything does not have to be
a process for it to be the Erlang way.

>
> Is this the Erlang way? Or is it just too much message passing overhead?

I'm definitely not qualified to be telling you of "The Erlang Way
(tm)" ;) so this is my own personal reasoning after writing a decent
bit of erlang in a space of  nearly a year.

Hey... but what do I know... I just started learning last year, so
take it with a grain of salt... heck... swallow a bag of salt while at
that :)


>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>