[erlang-questions] Re: OOP in Erlang

[Joe Armstrong]

Interesting discussion....

The term OO seems to mean different things to different people.

Since Alan Kay invented the term I think what he said should bear some
weight. On several occasions Alan said that OOP was all about messaging
not "all that other stuff". Let me give you a few quotes:

Quote 1:

    OOP to me means only messaging, local retention and protection and
    hiding of state-process, and extreme late-binding of all things. It
    can be done in Smalltalk and in LISP. There are possibly other
    systems in which this is possible, but I'm not aware of them.

    Ref: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Quote 2:

Folks --

Just a gentle reminder that I took some pains at the last OOPSLA to try to
remind everyone that Smalltalk is not only NOT its syntax or the class
library, it is not even about classes. I'm sorry that I long ago coined the
term "objects" for this topic because it gets many people to focus on the
lesser idea.

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
is all about

    Ref: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

Quote 3:

     ...

     In other words, always having real objects always retains the
     ability to simulate anything you want, and to send it around the
     planet. If you send data 1000 miles you have to send a manual
     and/or a programmer to make use of it. If you send the needed
     programs that can deal with the data, then you are sending an
     object (even if the design is poor).

     And RCATWD also provides perfect protection in both
     directions. We can see this in the hardware model of the Internet
     (possibly the only real object-oriented system in working order).

     You get language extensibility almost for free by simply agreeing on
     conventions for the message forms.

     My thought in the 70s was that the Internet we were all working on
     alongside personal computing was a really good scalable design,
     and that we should make a virtual internet of virtual machines
     that could be cached by the hardware machines. It’s really too
     bad that this didn’t happen.

     Ref: http://www.computerworld.com.au/article/352182/z_programming_languages_smalltalk-80

--- this last quote is from an interview in computer world in Australia.
(read the full article it is full of wisdom

   It is pretty clean that when Alan dreamt up the idea of OO it was
   "all about messaging" - he says this time and time again. I talked
   to Dan Ingalls about this and he was in complete agreement. He (Dan) said
   in a lecture (paraphrased) "the great thing about messaging is that
is decouples
   the sender from the receiver"

   In a sense the receiver of a message does not care who sent the
message, and the
   sins of the sender are not visited on the receiver of the message.

   This is the key point. If your program can crash my program they we are
   totally screwed. This should never ever happen. never ever ever
ever ever ever ...
   (repeat zillions of times).

   This is the property of isolation. The mechanism of isolation is
message passing.
   (note: asynchronous MP - synchronous MP breaks isolation since the
    receiver could block the caller by refusing to read a message)

   Note also that communication though messaging is the easiest way possible to
   glue things together - think Unix pipes.

   (aside: read this: http://cm.bell-labs.com/cm/cs/who/dmr/mdmpipe.html
    this is Doug McLlroys memo to Dennis Richie and Ken Thompson

    quote: Summary--what's most important.

     To put my strongest concerns into a nutshell:

     1. We should have some ways of connecting programs like garden
     hose--screw in another segment when it becomes when it becomes
     necessary to massage data in another way. This is the way of IO
     also.
     ...


     )

     Wonderful stuff - "like a garden hose" ... "screw in another
     segment" ...

     This is *precisely* what Alan Kay was talking about. There is a
stong conceptual link between Alan's ideas on messaaging and isolation
and McIlroys pipes - they are the same idea in a different guise -
Unix processes connected though pipes and sockets *are* communiction
objects (by Kay's definitions)

     So we have the pipes (garden hoses) that pass messages - that is
     the big idea.

     Polymorphism - (all objects respond to a asString message) is
there so make programming easy - so we can guess the names of things.

     All the rest - organisation into classes and objects has zilch do
do with the central concept of OOP. As Alan Kay said, this was " the
less idea " (his words).  This is "just" how you organise code (this
is not to belittle the point - but remember the *big* idea is
messaging )

     To me the Erlang angle has always been that of making things
fault tolerant.  "my stuff should not crash your stuff" - this
necessitates message passing passing systems. (ie you must have two or
more machines).

     In conclusion Erlang is very much an OOPL - since deep down, very
deep down, it tries to make makes a passable job of getting message
passing and isolation right.  In this sense it is far more OO than
languages like Java (etc.) that have no notion of isolation and thus
cannot be considered OOPLs :-)

     /Cheers

    Joe






2010/8/13 Ulf Wiger <ulf.wiger@REDACTED>:
> 黃耀賢 (Yau-Hsien Huang) wrote:
>>
>> Recently I read the book
>> "Design Patterns Explained," which hints that OOP/OOD is to treat
>> everything, including primitive datatypes, as object.
>> And he explained how abstraction
>> is different from implementation. Then I thought that Erlang
>> treats everything as function or process, but really?
>
> Yeah, well, I've had some pretty interesting discussions with
> proponents of that view, and I would rather say that it is
> possible to deal with abstractions as wholly separate from
> implementation, but it is wrong to say that it holds in general
> (at least for any useful definition of implementation).
>
> The idea, as I understand it, is that you want to adapt to
> the common pattern that you have separate teams that handle
> requirements, architecture, and programming (oh, and yet
> another team doing testing, usually). I am very well familiar
> with that way of working, and will go as far as saying that
> it can sometimes be extremely difficult to avoid.
>
> The real danger with that setup, and the viewing of abstraction
> as somehow separate from implementation, is that you tend to
> to do "abstraction" for its own sake. The quotation marks are
> there because in many cases, people confuse drawing visual
> symbols with abstraction; while it may be in some dimension,
> it is not abstraction in any useful sense for a programmer.
>
>
> "The purpose of abstraction is not to be vague, but to create a
> new semantic level in which one can be absolutely precise."
> Edsger W. Dijkstra, "The Humble Programmer", October 1972
>
>
> To do abstraction in the way Dijkstra intends, you should have
> a very good intuition about implementation issues. You might
> say that abstraction grows from implementation.
>
> The key here is that you need to *pick* your abstractions
> carefully based on your understanding of the domain *and*
> details, opportunities and limitations of the implementation
> layer. Erlang provides some abstractions that are a bit
> unusual, but have been found in practice to work exceedingly
> well in some domains.
>
> Some of those abstractions tend to be sub-optimal if your
> aim is to write computational code that goes blazingly
> fast. OTOH, some of the abstractions that have traditionally
> fared well in that regard are suffering now, as the
> hardware becomes increasingly parallel - something that
> happens to suit Erlang just fine.
>
> Programming is all about abstraction - layers on top of
> layers of abstraction, reaching all the way deep down into
> the hardware your program runs on.
>
>> Abstraction: it's separated from implementation. Abstraction
>> is done in Erlang by hot code replacement.
>
> No. Abstraction is when you make a model of something by
> hiding underlying details. Abstraction is all over the place
> in programming. Any Erlang data type is an abstraction - as
> Erlang doesn't allow you do address memory directly, you
> cannot control how many bits are assigned, how the data is
> laid out, where it is, whether it is shared, etc. Nor are you
> supposed to care.
>
> "Programming is both a top down activity from requirements and
> overall structure of the system and a bottom up activity based
> on the abstractions provided by the programming language.
> Abstractions such as modules, processes, higher order
> functions, etc. are to the programmer like transistors,
> capacitors, resistors, etc. to the hardware designer.
> It is important that the abstractions be few, simple to
> understand and yet powerful and provide the needed
> functionality. For example, if the application is inherently
> concurrent it would be very dfficult to program without
> some process concept. In that case the application program
> itself would have to include some form of scheduler.
> Distribution, error handling, and hot code loading are
> extremely complicated requirements and the support for them
> provided by Erlang enables the programmer to concentrate on
> the application rather than on the basic programming technology."
>
> (Bjarne Dacker, http://www.erlang.se/publications/bjarnelic.pdf,
> pg 26)
>
> BR,
> Ulf W
> --
> Ulf Wiger
> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
> http://www.erlang-solutions.com
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>