Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, but it certainly was not what it became. I'm less impressed by one guy's stated goals forty years ago than what it actually became.

That's not a criticism of Alan Kay. It's an observation that his saying a thing a long time ago didn't and doesn't change what actually was created, and what OO is today is not message passing.

The very, very core of what we call OO today, the feature without which you can not call yourself OO, is the binding together of a structure with associated "methods" for operating on it into a single unit. It's a way of structuring programs (note I do not say "language"; C can be programmed in OO, for instance) that chooses the OO answer to the Expression Problem: http://c2.com/cgi/wiki?ExpressionProblem There's other frippery... there's a LOT of other frippery, actually, tons and tons and tons... but that's the core.

It is not message passing. And the attempt to map one to the other is pretty klunky and generally lossy in both directions, another sign they really aren't the same thing. Alan Kay's description of message passing, when read in English rather than Smalltalk, always sounded a lot more like Erlang than Smalltalk to me, but I observe that Smalltalk is what he in fact created as the manifestation of his ideas, not Erlang. I think we can't ignore that fact.



Yikes! The expression problem is a small deal and has been solved many different ways (I wrote a paper on this in 2001, I debated this point with Wadler in 2002, this is so old news). My favorite way today is to use traits and type members in Scala, but any language that supports open classes would be even more elegant. Also, its a non-issue in dynamically typed languages.

We are only arguing pedantically about what OOP "means," and everyone has their own definition. Useless. My own definition associates OOP with object thinking, the deconstruction of your problem into interacting objects, and then the use of plumbing in your language that help you realize this deconstruction in a solution. What that plumbing is can vary greatly and involves some combination of methods, messaging, classes, interfaces traits, prototypes, constraints, behaviors, reactions, reflexes, patterns (beta style), state encapsulation, etc...

I like the idea of MOP, its like focusing on one aspect of the plumbing and fixating around it; I could never write a program using messages alone in my domain (like I couldn't really write a compiler using actors!). MOP and OOP are not orthogonal, they are describe completely different granularity.


Yes, I know the expression problem is old news. So is OO. There are plenty of things coming out that move beyond it or beside it or incorporate it as a thing in the language rather than the thing the language is bent around, but that is still the core idea in OO.

And if you carefully read my post again, you'll see I didn't give a definition. I talked about the one element that I've seen that is common across all of them. I can name OO languages with no first-class support for inheritance, no classes, no interfaces, or any of the other things you name, but I can not name an OO language that does not have some first-class binding of a structure to the methods to operate on it, nor can I show you an OO program in a non-OO language that is missing that, because that's essentially a logical contradiction. That's the single core idea that is what OO is.

This dodges the "everybody has their own definition" problem entirely.

Message passing as a primary means of structuring your program and OO are incompatible. One's going to have to be meshed within the other. One's this fundamentally asynchronous, distributed way of programming, and one is an elaboration on structured programming. Someone's on top. You get the same thing between FP and OO; you can put OO in FP or you can put FP in OO (quite popular, Python/Ruby/etc. fit here), but one is going to have to be on top. They can't be peers, they have fundamentally different ideas about what is most important.


You just aren't trying hard enough. The first OO language (SketchPad '62) was constraint based (visual and based on prototypes). Then there was ThingLab (Borning, 78?). And for my own work, check out SuperGlue (ECOOP 2006, OOPSLA Onward! 2007). No methods to be seen...and still very OO.

Incompatible or orthogonal? Message passing is primarily an issue of software architecture (using Garland's definition) while OOP is more of an issue of linguistic abstraction.

OOFP is definitely possible, like say Moby or OCAML. The distinction between OOP and FP is hardly as black and white as you think.


With all due respect, I think you need to stop glancing over my posts and looking for things to pick at with all possible speed, and maybe spend a bit of time actually reading them, before you go jumping all over them any more. Your last paragraph in particular is pretty much proof positive you did not actually read the post you are replying to.


I did read your post, I was disagreeing with this:

> They can't be peers, they have fundamentally different ideas about what is most important.


For what it's worth, Sketchpad is described by wikipedia as a program and not a language, and moreso it "pointed the way forward" to OOP, in that Sketchpad included the concept of "master drawings" (read: classes) which could be instantiated into duplicates, such that when the master drawing changed, any previously instantiated duplicates would be changed accordingly.

ThingLab is described by wikipedia as a programming environment implemented in SmallTalk. In both cases, I think you are describing environments to play around with user-created objects moreso than languages.

Do Sketchpad or ThingLab have grammars?


Well, what is a language then? My opinion is that any abstraction layer that shapes thought and allows for the expression of new abstractions is a language in its own right. If it has a textual syntax, great! But this isn't necessary. It might be a programming environment that exposes new or different metaphors from its underlying host. An object system in Scheme is defining a new language, an enhancement of Scheme, that happens to be OOP.

SketchPad is a language, just a very inexpressive one that is not targeted at traditional programmers. ThingLab defines new metaphors and such, programming in ThingLab is a distinct programming experience from Smalltalk. Heck, even Bad Piggies is defining an inexpressive language in the context of a game, or think scripting in LittleBigPlanet.


I agree that you can "program" in these environments. But I disagree that they are languages. Perhaps I'm not thinking hard enough.


This is probably because what makes a "language" is fairly fuzzy. There is probably no hard line where a abstraction layer goes from just being a user interface/environment/library/notation to a language.


>but I observe that Smalltalk is what he in fact created as the manifestation of his ideas

Actually no. Dan Ingalls made Smalltalk-80, which is probably the one you know. Kay never liked ST-80, but I'm not convinced Kay ever had a clear vision of what OO should be, only what it shouldn't. He knows enough to say he doesn't like anything that's available but why hasn't he just made a manifestation of his ideas? It's much easier to deal with "no, not like that, like this" then someone who just constantly says "no, that's not it either".

There were several previous versions of Smalltalk. Maybe he actually did make some of those. But they were dropped because they weren't powerful enough...


He has. This post https://news.ycombinator.com/item?id=4789877 has more details.

But I think it was clear before this. Message-passing between non-shared state actors is a fundamentally different animal than "traditional" shared-state programing, whereas what is commonly thought of as OOP (special method-call syntax, class-based coding) is just sugar on any other language without changing the way things work under the hood.

Certainly, using the word "object" was unfortunate because it distracted people whereas "message-passing" is more to the point, but if you see what it was supposed to achieve there really is only one thing it could mean.


No argument. My comment was meant more as a lament- "oh, Object Orientation, what you could have been!" - than as a claim that we don't need something else.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: