Parsing an incoming Shoutcast request
Tue May 30 11:43:12 CEST 2006
Thanks for the longer explanation. It's fairly hard to understand the
idioms and architectural tradeoffs without a large body of code to work
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
> 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
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
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
I will dig through those.
More information about the erlang-questions