Parsing an incoming Shoutcast request

[Andrew Lentvorski]

Thanks for the longer explanation.  It's fairly hard to understand the 
idioms and architectural tradeoffs without a large body of code to work 
from.

Joe Armstrong (AL/EAB) wrote:

> The OTP behaviours are not magic bullets, they are just libraries of
> erlang code for performing repetitious tasks in a consistent manner.
> 
> The main benefit of using (say) gen_servers is organisational - if you
> have
> a large team of programmers (say a few hundred) and they are all writing
> 
> client-servers, then it might be a good idea if they all go about this 
> the same way.

Surprisingly, I find gen_server, at least, useful in a one-man project.

The reason is that I am not an expert Erlang programmer.  The OTP 
gen_server framework gives structure while I struggle to climb the 
learning curve.  While I understand the mechanics of the basic commands 
by themselves, I don't yet automatically see the patterns of how they go 
together.

In fact, I would argue that one of the easiest ways to explain 
gen_server modules is that they are akin to a "Class" from a more 
traditional Object Oriented language.  They encapsulate "state" (which 
would be the member variables) and provide an API (which would be the 
member functions).

As a bonus, they are "active" instead of passive.  This gives me a whole 
host of behaviors that I cannot replicate in a more traditional OO language.

I know that I have just horrified 99% of the readers on this list. 
Please pardon my ignorance until I shake off the shackles of thinking in 
other languages and start thinking in Erlang.

It is entirely possible I will find gen_server to be complete overkill 
as I get better.  That's fine.  At that point, I can make an active 
informed choice because I will know what I am doing.

> Another source of information might be to look in the examples
> I wrote years ago
> 
> http://www.erlang.org/examples/examples-2.0.html

I will dig through those.

Thanks,
-a