Alan Kay was recently quoted as saying that Smalltalk should have been message oriented rather than object oriented. I’m not sure what he meant by that, but it got me thinking.
Smalltalk terminology refers to method invocations as message sends. Message passing is often associated with asynchrony, but it doesn’t have to be. Smalltalk message sends are synchronous. As such, they seem indistinguishable from virtual method invocations. However, the terminology matters. Insisting that objects communicate exclusively via message sends rules out aberrations such as static methods, non-virtual methods, constructors and public fields. More than that:
It means that one cannot access another object’s internals - we have to send the object a message. So when we say that an object encapsulates its data, encapsulation can’t be interpreted as just bundling - it means data abstraction.
it implies that the only thing that matters about an object is how it responds to messages. Two objects that respond the same way to all messages are indistinguishable, regardless of their implementation details. This excludes implementation types for objects, and hence class based encapsulation, as in:
class Foo {
private Integer bar = 101; // my secret code
public Integer baz(Foo f) {return f.bar;}
}
Overall, the message passing terminology precludes the interpretation of objects we see in mainstream languages - the spawn of C. This has great value. However, while saying that all objects communicate via message passing gives a strong notion of object, it doesn’t ban things that aren’t objects, such as values of primitive type like ints and floats. It doesn’t guarantee that a language is purely object oriented, like Smalltalk.
We can nevertheless ask: is Smalltalk a message based programming language? I think not. I would take message-based programming to have an even stronger requirement: all computation is done via message passing. That includes the computation done within a single object as well. Whereas Smalltalk objects can access variables and assign them, message based programming would require that an object use messages internally as well. This is exactly what happens in Self, as I discussed in an earlier post about representation independent code.
The implications of this are quite strong. In particular, this formulation does carry with it the requirement that everything is an object (at least at run time), since the only entities one computes with are those that respond to messages.
I like the term Message-based Programming (MBP). It implies a lot of valuable design decisions I strongly believe in, while leaving many design alternatives open. The term is, I hope, free of the baggage that is associated with object oriented programming, which has too many flawed interpretations.
I believe that future programming languages should be message based, in the sense I’ve defined above. This still leaves language developers with a huge design space to work with: message based programming languages can be imperative or declarative; statically or dynamically typed; class-based or prototype based; reflective or not; eager or lazy; and synchronous or asynchronous, to name a few important design options.
A place to be (re)educated in Newspeak
Saturday, May 12, 2007
Subscribe to:
Post Comments (Atom)
16 comments:
It does, however, rule out multi-methods. Which seems a shame.
hey gilad,
back on the self bandwagon :-) ?
(this is in reference to the email you sent me when you noticed me trying to get the 'for' syntax changed to foreach in java. you said, what 'tired of the self community')
seriously, what too, you so long to figure out that java was the wrong direction?
Alan Kay was recently quoted as saying that Smalltalk should have been message oriented rather than object oriented.
Hasn't he been saying something like that for a good while? There's 10:05-11:34 and 37:24-39:58 of his 1997 OOPSLA talk, and his followup email.
"rules out aberrations such as static methods, non-virtual methods, constructors and public fields"
Don't forget that Smalltalk has many of these things.
There's no conceptual difference between some C++ that looks like this:
int v = object.value;
And this Smalltalk
v := object value.
The Smalltalk is just as likely to blow the encapsulation as the C++.
Non-virtual methods are really just an optimisation.
As for static functions and constructors Smalltalk has a Metaclass instance for each class in the system. The metaclass instances provide the services that statics and constructors do in Java and C++ (think of a factory pattern).
The keyword static is only used because it was considered easier to re-purpose a spare C keyword than make up a new one.
As Alan Kay says, messaging is the concept you need to get your head around. Once you do that you'll see that most of the rest of what we do is just special cases, but you'll also realise that there are all sorts of times when altering the message passing and the binding mechanisms you use can solve all sorts of problems in very neat ways.
I remember a keynote by "Big" Dave Thomas talking about Message-Oriented Progamming a few years ago. A dinner keynote, I remember.
And, I don't think MBP necessarily rules out multidispatch. To quote Craig Chambers, you're just sending a message to more than one object
"Don't forget that Smalltalk has many of these things."
@Kirit, you're wrong, Smalltalk has none of these.
Just because public fields are syntactically similar to accessors doesn't make em the same. Accessors are proper messages.
"Non-virtual methods are really just an optimization."
No they aren't, they prevent a programming from being able to subclass effectively and have no place in an OO language. Everything should be overridable all of the time.
As for static functions and constructors, Smalltalk doesn't have them either. Yes, metaclass methods are used for the same purpose, but that doesn't at all make them the same thing. Metaclasses are just objects, and constructors are just ordinary message sends to them, again, proper OO rather than some bastardized version of it like in C's children.
The blog post has a good point, message sending does rules out aberrations such as static methods, non-virtual methods, constructors and public fields. None of these things belong in an object oriented language.
Dru,
I'm not on the Self "bandwagon". You can't get on something that doesn't exist (I wish there was one though). I'm a great admirer of Self, but I still have issues with it.
As for what took me so long etc. It didn't. If you'd followed some of my academic talks, you'd know that I've said most of these things many times before.
Working for Sun, it was not appropriate to make a big deal of my personal views in public. Academic talks on technical points don't undermine your employer's product. "Mass market" things like talks at industrial shows or blog posts do - partly because they are often misinterpreted.
For a while? Probably a lot longer that that!
This reminds me of a interesting document by Alan Kay, which deserves more exposure:
"The Early History of Smalltalk"
I lost the link a while ago, but found it again using Google and a boatload of keywords, motivated by this post. Thanks.
Also, link to LtU discussion page and PDF version for the "Early History of Smalltalk".
I'd like to see a de-emphasis of shared-memory data structures (including shared types, classes, method dictionaries, etc.) and a new emphasis on shared-nothing message passing.
I'm not sure how that fits Kay's intention, but I think that emphasis is better than, e.g. adding a DLR to a static CLR or adding a few byte codes to the JVM.
Forget shared type systems except for a simple set (JSON-like) of structures and primitives for inter-language messages.
Alan Kay was saying Smalltalk should have been message-oriented even
back in 1982.
How should self be improved?
Hi Gilad,
I'm convinced about the importance of messaging. For me it comes down to two words I picked up long ago: "coupling and cohesion".
The thing is why are these basic ideas not common knowledge? My second question is what do you intend to do about it :^).
Seriously, you've read my blog - and I agree I'm not best equiped to explain these ideas and promote alternatives to the current status quo.
The main body of programmers have expanded enormously from the early days of C++ up until now. These mainstream programmers have grown up on a "vocational" view of programming and have a different idea of the "truth" picked up in books with titles like "Learn Java in 21 days".
Perhaps if "the old school" were a little more vocal, then the main stream would spend less time and energy persuing dead ends.
As for me, I'm tired of learning yet another Java framework, just to pay the bills. Please Gilad tell us you've got something better in the pipeline :^) Otherwise I can see my self looking for a new profession.
Paul.
Hi Paul,
I understand your frustration. We are all familiar with the widespread adoption of inferior technology: PCs vs. Macs can serve as the canonical example.
So let me ask (rhetorically) why should I care?
1) Because, due to network effects, the broad adoption of bad technology can create a situation where I will be under pressure to use it, or at least interact with it.
2) Because the use of bad technology makes everyone less productive.
However, if most people use defective tools, languages etc., I can use good tools and languages as a competitive advantage. In other words, if you can avoid (1), you need not be concerned with (2).
Also remember that the good ideas do win in the long term. It just takes an unbelievably long time. Garbage collection, IDEs, GUIs and GUI builders, Refactoring, Agile coding - these are good things that have gone mainstream. Usually, the mainstream version is not the best version of the idea, but in time, we progress.
Closures and pure OO are very close to winning as well.
All of which is cold comfort if you can't solve problem (1) above. You ask what I'm doing about it? Well, I quit the Java world and am now working on very cool stuff (tm).
I expect I'll be able to publish some of it in the foreseeable future. Regardless, I have no illusions. Taking over the world of software is unlikely, precisely because what I do now is so cool. What I try to do is push the state of the art forward, and hope that it makes a small difference for the better over time.
In short, make sure *you* get to use the best technology. The people who choose otherwise richly deserve to use what they are using.
I have been battling with the implementation details of MBP as I attempt to build a 'framework' of sorts. One of the things I've come to realize is that there is a certain level to which you cannot hope to completely fuzz method calls. You will always need an explicit binding between emitter and receiver.
This might be a topic for neural network type philosophy debate.
Hi,
This blog post is the first one to come up in google when searching for "Message Based Programming", even before wikipedia.
I've been looking at message based programming for a while and I've notice that even though some system are build as message based, they usually expose them-self as OO API, for example Windows OS.
Another area where you will always see MBP is robotics, there is it critical to have characteristic of MBP such as separation between caller and callee, priority of handling, load balancing, async and etc.
It's turn out that Microsoft has been working on such framework since 2004 and it is now a stand alone product called CCR & DSS Tookit 2008
They didn't create a new language, because that will be to hard to handle, instead they build on top of CLR (.NET Framework) and create a message based application model.
In their model everything is a message. "Calling a method" is a message, "protecting resource" is a message, "event" is off-course a message.
One of the great things is that it is very light-weight framework with few building blocks.
The most difficult thing for me is start thinking in term of message (async message to be accurate) and stop think in terms of sync function invocation.
They do work on language based on that framework but as I said, it will take time to do the leap there.
Ido.
Post a Comment