[erlang-questions] Erlang "object-oriented" after all?
Michael Turner
I ran across a very interesting exchange with Alan Kay, who most likely
coined the term "object-oriented programming."
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
If you'll excuse some (only slightly tendentious) editing of his remarks:
----
"I thought of objects being like biological cells and/or individual
computers on a network, only able to communicate with messages . . . . I
wanted to get rid of data. . . ."
"I realized that the cell/whole-computer metaphor would get rid of data,
and that "<-" [assignment operator in smalltalk] would be just another
message token . . . ."
"I didn't like the way Simula I or Simula 67 did inheritance . . . . So
I decided to leave out inheritance as a built-in feature until I
understood it better . . . .
"My original experiments with this architecture were done using a model
I adapted from . . . rather LISP-like [languages] but with a more
conventional readable syntax. . . ."
"Another big influence at this time was Carl Hewitt's PLANNER (which
has never gotten the recognition it deserves, given how well and how
earlier it was able to anticipate Prolog) . . . ."
"I'm not against types, but I don't know of any type systems that
aren't a complete pain, so I still like dynamic typing.) . . . ."
"The people who liked objects as non-data were smaller in number, and .
. . pretty much all of this group were . . . . were involved in one
way or another with the design of ARPAnet->Internet in which the basic
unit of computation was a whole computer. But just to show how
stubbornly an idea can hang on, all through the seventies and eighties,
there were many people who tried to get by with "Remote Procedure
Call" instead of thinking about objects and messages. . . ."
"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things . . . ."
----
So perhaps it would be forgiveable to describe Erlang as not just
concurrent, functional, fault-tolerant, soft-real-time, and strongly
influenced by both academic logic programming and real-world networking
problems, but also as "object-oriented in the original (and perhaps
best) sense of the term." At least on the theory that any major
buzzword pile-up should be salvaged with a rhetorically graceful
crescendo.
Besides, what's that old saying again? "Those who don't learn from
history are condemned to be repeatedly over-awed by those who can fake
it"?
;-)
-michael turner
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Joe Armstrong
It's difficult to say if Erlang is OO - since there is no widely
accepted definition of what OO is or means.
When we wrote the first Erlang book we looked up many definitions of
OO but there was a wide
variation in what different languages regarded as comprising OO'ness.
I now believe the following to be central to the notion of OO.
- Isolated concurrent things
- Communication through message passing
- Polymorphism
All the other stuff (inheritance, private/public methods, ....) has
nothing to do with OO.
isolation is essential - if my set of objects can be damaged by your
set of objects then we just can't build
reliable systems.
Isolation implies pure (copying) message passing and concurrency.
Things must be concurrent - otherwise
how could we make a "clock" object.
Polymorphism is essential in the messaging interface to abstracting
out the internal details of an object. Pid ! printYouself cold tell
any objects to print itself. All I/O objects should respond to
read/write/... messages
etc.
By these criteria there are actually no OO languages (nobody can do
*complete* isolation) though Erlang
is nearer to being OO than many other languages. And most so-called OO
languages are not OO.
One problem with saying "everything is an object" is that it doesn't
allow us to talk about things which are not
objects. So ask questions like "is time an object?" is "code
replacement an object?" is "is scalability an object?"
you won't get a sensible reply.
The erlang answers are easier:
"Q: What is code replacement?"
"A: A protocol - Pid ! {newCode, F} tells the process Pid to start
executing new code F"
and so on....
For convenience things like code replacement are built into the OTP
behaviours - which basically just enforce several low-level protocols.
/joe
Vlad Dumitrescu
> It's difficult to say if Erlang is OO - since there is no widely
> accepted definition of what OO is or means.
>
>
> - Isolated concurrent things
> - Communication through message passing
> - Polymorphism
>
> All the other stuff (inheritance, private/public methods, ....) has
> nothing to do with OO.
Hi,
True.
I feel though that there is something missing before this OO-ness
really becomes useful. And that is a way to specify the contract that
one expects a certain object to fulfill. An interface or a protocol
has to be possible to be referred to by name. Today that name would be
the name of a module, but it feels like module names get a too
overloaded meaning. I don't have an alternative suggestion yet,
though.
best regards,
Vlad
Raoul Duke
> the name of a module, but it feels like module names get a too
> overloaded meaning. I don't have an alternative suggestion yet,
> though.
perhaps take a look at Clojure
http://blog.higher-order.net/2009/11/23/clojure-circuit-breaker/
(requires javascript on to see the code samples)
Tony Arcieri
> "I thought of objects being like biological cells and/or individual
> computers on a network, only able to communicate with messages . . . . I
> wanted to get rid of data. . . ."
You'll find this quote in my presentations on Reia:
http://www.unlimitednovelty.com/2009/05/reia-presentations.html
In this regard, I think Erlang is closer to Alan Kay's conception of an OO
language than most "OO" languages today. Such is the legacy of C++. The
"only able to communicate with messages" concept is not upheld in many of
these languages, as objects can "communicate" through destructive mutations
of shared state rather than messages.
--
Tony Arcieri
Medioh/Nagravision
Raoul Duke
> "only able to communicate with messages" concept is not upheld in many of
seems like Objective-C is a little more really OOish. not surprising
given its history.
Richard O'Keefe
On Nov 24, 2009, at 10:06 PM, Joe Armstrong wrote:
> One problem with saying "everything is an object" is that it doesn't
> allow us to talk about things which are not
> objects. So ask questions like "is time an object?" is "code
> replacement an object?" is "is scalability an object?"
> you won't get a sensible reply.
But "everything is an object" doesn't mean that.
It means that "whatever can be the value of a variable is an object".
If "time" or "code replacement" or "scalability" could be the value
of a variable in some language, then it would make sense, in that
language, to ask if they were objects, but not otherwise.
In Smalltalk, for example, when you look at
2 squared
+ 2 is an object
+ #squared is an object
+ "tell somebody to square itself" is an object
+ the source code for Integer>>squared is an object
+ the history of changes to that source code is an object
+ the executable code for Integer>>squared is an object
+ the compiler is an object and can be asked to install new code
+ the execution context when the method runs is an object
- but "execution" per se cannot be the value of a variable
and is not an object and "compiling" and "installing" are not
objects. They are processes in time that take place when
certain objects are asked to do certain things.
>
>
> The erlang answers are easier:
>
> "Q: What is code replacement?"
> "A: A protocol - Pid ! {newCode, F} tells the process Pid to start
> executing new code F"
>
> and so on....
That "A" is the wrong category to be an answer to that "Q".
"A" answers
Q': How do I make code replacement happen?
A : A protocol - Pid ! {newCode, F} tells the process Pid to
start executing new code F
% but almost no processes understand that protocol
Jachym Holecek
>
> I ran across a very interesting exchange with Alan Kay, who most likely
> coined the term "object-oriented programming."
>
> http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
>
> If you'll excuse some (only slightly tendentious) editing of his remarks:
>
> ----
> "I thought of objects being like biological cells and/or individual
> computers on a network, only able to communicate with messages . . . .
No, you didn't. If you did, you would certainly have noticed that individual
cells/computers live concurrently and communicate asynchronously, which is not
how your objects behave.
:-)
SCNR, I still remember the disappointment of discovering (ages back) that
Objective-C objects didn't really fulfill the "they behave like real-world
objects" promise given by the (otherwise pretty good) NeXT book because
you couldn't "run objects in parallel" which sounded like something that
should obviously be possible.
Regards,
-- Jachym
Olivier Boudeville
This is surely a shameless plug, but, in terms of OOP with Erlang, one
might give WOOPER a try
(http://ceylan.sourceforge.net/main/documentation/wooper/), as it
basically provides most OOP constructs in order to rely on concurrent
instances in pure Erlang.
Best regards,
Olivier.
Jachym Holecek a écrit :