[erlang-questions] Please help me relate a past project to Erlang, I'm trying to understand...

[Steve Davis]

This may or may not help, but I do feel the pain you are facing.

Without previous experience in functional programming, the issue you
face is perhaps the biggest conceptual barrier to even getting started
with Erlang.

Remember that OO took a while to grasp? Well, the good news is that FP
is easier but will also take a little bit of time. Write some small
programs that do a small part of what you wish to do then build on
those. Building on your foundations is far easier in Erlang than say
Java or C++.

The reason it's easier, as I'm sure you'll appreciate by writing some
code, is that it's more logical and brings you closer to both the
problem you face and to the metal you are working with.

Passing data around in Erlang does take more planning than it does
with an imperative language, but you gain enormously when you realize
that you don't have to deal with side-effects that dominate imperative/
OO code. This enormously reduces the amount of code you have to write
and does clarify your thinking about the "business logic" problem.

If you think of your application as a big black box with inputs and
outputs, split those out into which inputs and outputs you need so you
end up with a bunch of smaller black boxes that you can approach. Each
will have an input and and output (f(x) -> x'). This will clarify and
you will find that it correlate to your use cases.

The conceptual leap looks impossible perhaps, but I strongly encourage
you to try a small part of the problem to experience the clarity and
conciseness that Erlang can bring. The rewards you will receive will
far outweigh the effort you put in, but it won't happen overnight.

Best,
/sd
On Mar 12, 6:26 pm, bill robertson <billrobertson42+erl...@REDACTED>
wrote:
> So I've been thinking more about Erlang lately, and I still haven't
> gotten over a conceptual hurdle.  Where do you keep state?
>
> So I'd like to explain a previous project that I did, that would be a
> natural fit for Erlang, and then discuss how one might approach it in
> Erlang.  I'm not trying to advocate for the way the project worked in
> the past, and I'm not trying to get free advice for working on it now.
>  I no longer work at that company and haven't touch it in a long time.
>
> The project was a controller for a conference calling server.  In the
> setup there was a server running on another box that took simple
> commands, e.g. dial a number (it used PRI), play a wav file to one or
> more lines, answer, and bridge multiple lines together, disconnect
> lines etc...  The whole thing was pretty small potatoes, so there was
> no need to distribute the controller logic.  It was a lot of fun to
> do.  I have to say that its a great experence when you hit "go" in the
> debugger and your phone rings.  :)
>
> The controller piece, which I implemented was in (please don't stop
> reading) Java.  It would take commands from a web applicaiton, handle
> events from the telephony server and report on and manage the state of
> the conference calls.  When it was dealing with messages from the
> telephony server it would first lock the conference call object and
> then forward the message to an object that represented the participant
> on the call.  The participant object would interpret the message,
> update its internal state, and under some circumstances notify the
> conference call object of a major state change (e.g. the line hung
> up).  Upon update from a participant, the conference call object might
> change its state e.g. the last person hung up, so call over.
>
> Once the call stack unwound, the conference call object became
> unlocked automatically (language mechanisms).  Overall it worked
> pretty well.  The locking wasn't automatic, so it was possble to
> forget to lock, which of course would cause havoc (it happened -- bad
> decision on my part to leave it to fallible human memory).  The only
> possible bottleneck it presented was when 30 or so people were trying
> to jump on the call at the same time, although we never measured if
> the bottleneck was in the controller or in the telephony server.
>
> In the Erlang world, I can easily see how you would want a process for
> the conference call, and possible a process for each participant.  I
> also understand that you don't want to use a process local map for
> storage.  So would you use an ets or a dets table?  Or would you track
> it in a completely different fashion.
>
> I would really appreciate your help.
>
> Thank you.
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@REDACTED://www.erlang.org/mailman/listinfo/erlang-questions