[erlang-questions] OO programming style in Erlang?

[Sean Hinde]

Nice and well written article.

I've been thinking about making a blog post with the title

"Erlang is objects done right"

But given the amount of free time I have these days I might as well  
summarise it here:

Two events from the past came together in my mind recently. For many
years before becoming an Erlang addict I tried half heartedly to learn
"programming". My job did not require it, but it seemed like a useful
skill.

I recall becoming very frustrated with the concept that calling a
method of an object was referred to as sending the object a
message. How can it be sending a message I thought - messages are
things that can only be passed between things with their own parallel
existence.

That attempt to learn that language (possibly C++, I don't recall)
soon ended in distraction.

The second event 8 or 9 years later was a conversation with possibly the
world's greatest C++ zealot.

One argument used to persuade me to give up on Erlang for C++  
included the
phrase "But Sean, you are the most object oriented guy I know. Erlang
is all about sending messages between objects".

I could only agree.

So, I conclude Erlang is objects done right.

This should not be taken as any kind of contradiction to my statement
quoted below :-)

Sean


On 23 Jan 2007, at 15:13, Adam Lindberg wrote:

> As a side topic regarding OO and Erlang ways of thinking, here's a
> good article about Erlang and concurrency. It touches object
> orientation and comparisons with Java for example, and is somewhat of
> a mind opener. :-)
>
> http://www.defmacro.org/ramblings/concurrency.html
>
> On 1/22/07, Sean Hinde <sean.hinde@REDACTED> wrote:
>>
>> On 22 Jan 2007, at 11:39, Ulf Wiger wrote:
>>
>> > Den 2007-01-22 11:52:35 skrev Ladislav Lenart <lenartlad@REDACTED>:
>> >
>> >> *Question:* Is there a way such polymorphism can be
>> >> achieved in Erlang without actually merging (see above)
>> >> the modules that should behave polymorphically?
>> >
>> > No universally agreed upon common method, no,
>> > if I understood your question correctly.
>> >
>> > Xmerl, for example, introduced a notion of module
>> > inheritance, with which one were supposed to extend
>> > the functionality of export callbacks. See e.g.
>> > http://jungerl.cvs.sourceforge.net/jungerl/jungerl/lib/xmerl/src/
>> > xmerl.erl?revision=1.2&view=markup
>> > mainly lines 267-313.
>> > (or the OTP source tree for a more current version.)
>> >
>> > I don't know if anyone has actually made use of it.
>>
>> I suspect not.
>>
>> IMO the most important thing to take away from this discussion is
>> that OO style is not the normal or best way to program in Erlang.
>>
>> Try not to think of erlang processes as simply repositories of state
>> - they are so much more than that.. Model each real world activity as
>> an erlang process, and have each process maintain as much state as it
>> needs to function as that real world process.
>>
>> The API into the process would not typically be get/set operations,
>> but real world calls like make_sale() or purchase(). It can all be at
>> a much higher level using Erlang.
>>
>> If you also follow the other advice in Ulf's post you will be getting
>> there :-)
>>
>> Sean
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> -- 
> Adam Lindberg
> Mobile: +46734228920