Erlang hints from an CO junkie

[Joe Armstrong]

On Thu, 12 Aug 2004, Vlad Balin wrote:

>>> Well, from the design point of view, you're describing OO
>> approach in terms
>>> of Alan Key.
>>> "Objects are the base building blocks, objects has the state, objects
>>> communicate
>>> with each other using messages." See citate below.
>>
>> I don't really understand this kind of statement.
>>
>> 1) In OO design you must identify the different objects involved
>> 2) In CO design you must identify the different concurrency
>> patterns involved
>>
>> 1) in not the same as 2)
>
> On a high level of your design you use processes as a unit of encapsulation.
> Just substitute 'object' with 'process'. What about concurrency, the
> semantic
> of 'objects' according to Key imply concurrent message processing. Key
> even use the 'protocol' term to describe an object interface - very close to
> the things you're saying.

Wait a moment - in my last posting I did not talk about encapsulation at all.

In Erlang there are two ways to encapsulate things.

   - hide the  things in  a process and  access then through  a defined
protocol
   - hide the things in an abstract data type and access through function calls

   again deciding which method to use is part of the design process

>
> Differens is only in terms. Your explanation implies that there's no
> difference
> between object and process.

Uuuggghhh


To illustrate the difference, you could provide
> an example when 'concurrency pattern' is _not_ the unit of encapsulation,
> but
> you clearly stated that it always _is_.

I don't understand this


>>   I also dislike this "everything is an object" way of thinking.
> I also dislike this way of thinking. But this is an ideology of Smalltalk
> only.
> You obviously don't have to make everything an object to use OO paradigm.
>
>>    As for the idea of bundling together data structures and methods into
>> the same unit of abstract and calling this an object is even sillier.
> I can't understand it. Could comment more on this?

Yes - data structure are passive, they just are. You can describe them
declaratively.

Functions are active they do things to data structures.

For a given data structure (say a string) there is a vast (unlimited?)
number of things you could do with it. Trying to isolate a small number
of these things and packing them into a "string object" seems silly to me.

Imagine a library. There are two types of books in a library

   Dictionaries - which define what words mean
   Non-dictionaries - which use the words in the dictionaries

Now suppose the words in the books were all objects. Now would we describe 
the car object.

If we have to include car methods in the definition the definition of a car
would be enormous.

The car object would not only the definition

 	car: "tin box to transport people and things"

   but would have to include all uses of car, in all the other books in
the library.

   IMHO it's much better to have a data dictionary that defines all the
data structures  to be  used - these  should be  describe declaratively
with examples.

   Then there should be sets of functions that work on these data types.



> First, you just suggested to do so when using processes as encapsulation
> units,
> which are accessiblie via the defined protocol only, and implementation
> (with
> underlying data structures) is hidden. Sending message is almost equivalent
> to
> calling a method.

No it's not.

Calling a method is synchronous - you suspend until you get a return value.

Sending a message is asynchronous, you send the message and continue.

>
> Second, you (I guess) consider using of Erlang behaviours as good practice.
> This is another example of abstract data types application.
>

Almost. Behaviours are a lot more than ADTs. ADTs should (IMHO) be
side-effect free, referentially transparent etc. Behaviours
encapsulate a lot more than just functional behaviour.

For example the OTP application behaviour could in no way be considered
an ADT.

   A behaviour should  capture "a behaviour" ie how  the system behaves
when something happens, behaviours are usually chunk of generic code
which are parameterised  with a number of callback  functions. This is
very different to typical ADT type code.


> And third, Erlang standard library contains a lot of examples of binding
> 'methods' and
> 'structures' together. queue, gbtree, sets, etc.
> It's normal to access wierd data structures like Okasaki's queue
> throung the abstract function's interface, cause it'll simplify the things.
> You disagree?

Of course not

>
>>    In my way of thinking we can model things using the following
>> things.
>>
>>     a) Pure data structures (described by types)
>>     b) Pure functions which transform data structures into different
>>        data structures
>>     c) Processes. Processes are little virtual machines. They have state
>>        (state is just some class (a) data). You can send them
>> messages (messages
>>        are class (a) data structures). They might respond with messages.
>>        They are independent - if they crash no other processes should be
>>        affected.
> Ok.
>>     Data structures (a's), functions (b's) and processes (c's) are all
>> fundamentally different types of things - they should not be mangled
>> together and called objects.
> Ok, we'll never call them 'objects' :). Does it change anything?
> An idea behind 'objects' is to hide an implementation details upon an
> abstract
> interface of a set of functions (messaging protocol).
>
> That's exactly what _you_ do when you
> 1) Define interface to Okasaki Queue using (b) class thing (pure functions).
> 2) Create an abstraction of a City using (c) class thing (process). You also
> mentioned that City process can spawn 1000 processes to model houses. Fine,
> you can think of them (I know you'll consider it wierd :), but...) as
> 'aggregated
> objects(processes)', since they are not visible to the user of the City
> process.
> What you did? You created an abstraction for City, with implementation
> details
> hidden; _this_ is called object, or 'abstract data type' instance, or
> whatever you
> like.

   Well I don't use the word object.

   To me  a process is a statefull  thing which has it's  own thread of
control  and which  can communicate  with other  things by  sending and
receiving messages  it also has  complex behaviour in the  presence of
errors.

   Then  there are  data structures  and  functions which  act on  data
structures these can be  conveniently combined into modules to provide
abstract data types.

>
> P. S.: Our messages tends to be quite long, :) so I'm going to answer to the
> second
> part later.
>
> Sincerely yours,
> Vlad Balin.
>

/Joe