19 ms·

Alan Kay on the misunderstanding of OOP (1998)

240 points by mmphosis 10y ago

Glench 10y ago
More from Alan Kay: http://alan-kay.wikia.com/wiki/Alan_Kay_Wiki http://alan-kay.wikia.com/wiki/Alan_Kay_Wiki
mej10 10y ago
Are there any examples of Kay's ideal other than The Internet? Especially systems that I could actually inspect and learn about in detail, rather than read short stories about.
- blihp 10y ago
  Squeak[1]/Smalltalk? (i.e. have you worked with what he would consider a 'real' message-oriented OO language?) [1] http://squeak.org/downloads/ http://squeak.org/downloads/
  - mej10 10y ago
    I played around with Squeak many years ago, but might appreciate it more now. What recently spurred more confusion on this topic was Alan Kay's discussion with Rich Hickey during the AMA the other day. https://news.ycombinator.com/item?id=11945722 https://news.ycombinator.com/item?id=11945722 I found it really hard to understand what Alan Kay is actually talking about. Saying things like > This is why "the objects of the future" have to be ambassadors that can negotiate with other objects they've never seen. This seems like something that (based on my limited knowledge) isn't possible with Smalltalk (in any but the most trivial of cases), and so I don't really consider it an example of what he is talking about. Or, at least, all of the things that I know of that you can do with this you could just as easily implement in languages without the same dynamism as Smalltalk. My conclusion after reading all of that is that Kay is talking about a system so completely unlike anything we have that there aren't even really examples of what it would look like. I am really trying to understand what Kay is talking about, so any pointers would be interesting!
    - blihp 10y ago
      You are correct, Smalltalk as-is can't currently do that. I believe he was referring to a future language / evolution / system that he would like to see, not something that currently exists. These are the sorts of things I think he's expressing his frustration about when he says things like Smalltalk getting long in the tooth etc. in that it was never intended to the be-all, end-all of languages... just one stop along a path. But don't let this discourage you from looking into Squeak. I played around with Squeak in the 90's but couldn't see past things like the weird mouse button mappings and color scheme. Fortunately I came back to it again and found some of the glaring UI issues (by modern standards) had been smoothed over. It also probably didn't hurt that I was a little older and better able to stick with it until I could finally see better the second go at it what the original vision was. Also, there is the work from his STEPS project which used Squeak as a platform that was used to prototype some of the next-generation ideas he talks about. If you want to understand better the next generation concepts, definitely look at the VPRI writings (esp. the STEPS annual reports) linked to in a previous post. To bridge the gap from here to there (i.e. to get to a tangible system that you can actually use that does any of this) I think you're probably going to want to learn Smalltalk as a starting point.
    - panic 10y ago
      Here's my understanding of the general idea (let me know if I got something wrong!). Say you have a bunch of computers with different software and hardware. You come up with a cool new image format called "PJEG". To get the images to show up on all the computers, you typically do the following: * Publish a PJEG spec * Define a .pjeg extension and let everyone know that means it's a PJEG file * Write a PJEG encoder/viewer for each kind of computer * Distribute these programs to the computers * Configure the computers to open .pjeg files using the programs you distributed * Modify other programs (image editors, web browsers) so they can recognize, encode and view PJEG files as well * etc... This approach doesn't scale very well. I think the alternative Alan is suggesting is that you'd include an interpretable description of the file format in the file itself in a sort of meta-format. Once you have an interpreter for these meta-format descriptions, all you'd have to do is: * Include an interpretable PJEG encoder/viewer with every PJEG file And that's all! Any program able to read the meta-format could use this file without any extra software. This obviates file type metadata and reduces the amount of distribution you need to do, making the whole thing way more scalable. The practical problems with this solution (larger file size, slow encoding and decoding) can be solved in various ways: * The larger file size can be mitigated by format negotiation (if I already know about the format, you don't have to tell me about it) * Optimized encoders and decoders can be written to replace the slower interpreted ones included with the file Having the interpreted format description makes it easier to validate the optimized version, too (you can generate a bunch of random examples and make sure they decode/encode the same way). And this doesn't have to just be for files, you can use the same technique for arbitrary "data types" in your program as well.
- minskyway 10y ago
  Writings: http://vpri.org/html/writings.php http://vpri.org/html/writings.php Software: http://www.vpri.org/vp_wiki/index.php?title=Main_Page http://www.vpri.org/vp_wiki/index.php?title=Main_Page
- z1mm32m4n 10y ago
  Hearing the way Alan Kay talks about "messaging" always reminds me of two technologies: the Flux/Redux architecture and Apache Samza & Kafka. > The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. With React and Flux, this is exactly what's going on! You're defining view components, and when someone interacts with them, there's a very structured, discrete set of actions that can be fired. These actions are then dispatched and handled elsewhere, but somewhere at the core, there's a single source of truth for what happens upon any given message. And for Apache Samza, I think this video[1] does a nice job of talking about stream processing as a programming architecture. There's a connection to be made between processing streams of information and processing messages between modules, and that video goes a good way towards exposing it. [1]: https://www.youtube.com/watch?v=fU9hR3kiOK0 https://www.youtube.com/watch?v=fU9hR3kiOK0 "Turning the database inside out with Apache Samza"
  - michaelscott 10y ago
    Redux is definitely a step in that direction. Elm, which it's inspired by, is even further along that road in that its design is better handled (but then it doesn't require handling in JavaScript so I suppose that is why)
- panic 10y ago
  Biological cells: I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful). (from http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en)
  - sixo 10y ago
    I wonder: what is that last sentence referring to? What got it right first? (Or gets it right now?)
- mietek 10y ago
  Erlang.
  - Sharlin 10y ago
    And actor-based systems in general. Akka is a good modern example of one that's not Erlang.
- jacquesm 10y ago
  Any complex system based on QnX would probably qualify.
deleted 10y ago
[deleted]
elchief 10y ago
How is messaging different than calling a method?
- achamayou 10y ago
  It implies more flexibility, like generically accepting messages, passing them on without knowing anything about them etc.
- dang 10y ago
  Alan commented on this several times in the AMA he did here a couple days ago: https://news.ycombinator.com/item?id=11957001 https://news.ycombinator.com/item?id=11957001 https://news.ycombinator.com/item?id=11945986 https://news.ycombinator.com/item?id=11945986 https://news.ycombinator.com/item?id=11945123 https://news.ycombinator.com/item?id=11945123
  - stinos 10y ago
    I have to admit I still have basically no idea what he's talking about when he says 'messaging'. A practical example would be useful for us non-CS-degree programmers who don't speak any of the CS lingo.
    - pdkl95 10y ago
      The idea is to replace "calling a function" with "sending a message". Traditionally a function call is fixed at compile time (with some exceptions such as function pointers). In C a function is just an address; if we want to call foo(), we must have that function available at address &foo. C++ added flexibility by allowing there to be multiple functions called foo() with and a set of vtables[1] that store the actual (C-style) address. Other variations exist, but all of these traditional styles map function calls to specific code that runs every time the function is called. Message change all of that. Instead of vtables (or similar) obj = create_foo() # instead of calling foo's bar() function directly, e.g. foo_bar(obj) # or perhaps obj.bar() ... we send a message by name of the function we want to call to the object itself obj = create_foo() obj.send_message("bar") # if function args are needed, include them as an array obj.send_message("baz", [42, "quux"]) The idea is that while the message can be effectively the same as a function call, it doesn't have to be. In a proper OO language, this message sending is handled automagically by the syntax. # instead of handling the messages directly, e.g. obj.send_message("bar") # the language does that for you when you call obj.bar() # in some languages, these are equivalent In many cases the "foo" class above will handle the message "bar" by running the appropriate function, but that isn't required. For example, in ruby when no function exists for a given message, the raw message is send to the #method_missing function. class Foo def method_missing(name, *args, &block) puts "#{self.inspect} I was sent message #{name.inspect} with args #{args.inspect}" end end >> obj = Foo.new => #<Foo> >> obj.bar() #<Foo> I was sent message :bar with args [] => nil >> obj.any_name_we_want() #<Foo> I was sent message :any_name_we_want with args [] => nil >> obj.any_name_we_want("args", "are", "optional") #<Foo> I was sent message :any_name_we_want with args ["args", "are", "optional"] Thinking of "obj.method()" as a message instead of only a function is much more flexible. [1] https://en.wikipedia.org/wiki/Virtual_method_table https://en.wikipedia.org/wiki/Virtual_method_table
lacker 10y ago
IMO the problem with object-oriented programming is that it turned into the standard curriculum for peoples' first semester of computer science, rather than being yet another interesting concept that advanced programmers would ponder. And the way we handle "the standard CS curriculum" sucks. (In the USA at least.) For example, AP Computer Science requires Java and tries to teach stuff like designing inheritance hierarchies to people in their first two months of programming education. And then tests it mostly using multiple-choice quizzes. It's totally inappropriate - most of these students would fail fizzbuzz. OOP should be something you only get into after you have written some practical programs, rather than something where you can't program, but you memorize the difference between "is-a" and "has-a" inheritance so that you can pass multiple choice tests.
- stevedonovan 10y ago
  OOP made sense to people who already knew structured programming and understood functional decomposition (what we now call 'refactoring'). Perhaps education should start with that and then justify OOP? I remember reading about the original LOGO experiments; one thing kids do not spontaneously do is break up their monolithic actions into sensible functions.
  - lacker 10y ago
    Yeah "breaking up a complex function into simpler functions" is a great example of something that isn't taught well today, yet is simpler and more critical than what we try to teach people in intro courses. I think of it in analogy to math. OOP is like topology - it's definitely useful in some cases, it's not too hard for an experienced mathematician to get the basics, and yet in a lot of situations it's irrelevant and it doesn't really belong in the first class you take. Being able to solve fizzbuzz is like doing arithmetic. If you can't solve fizzbuzz then you aren't going to be able to really get any advanced concepts. It's like you can't be a good mathematician if you can't figure out whether 351 is an odd number - you need to learn the basics first, even if "real math isn't about arithmetic". Sadly, you can tell if you do a lot of phone screens that many people who graduate with CS degrees still can't code fizzbuzz. Our CS education is busted right at the beginning. It needs to get the basics right, like, can you write loops, can you write functions. Today it is failing at that.
damienkatz 10y ago
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." What he's describing is the essence of Erlang.
- jacquesm 10y ago
  Yes, there are a lot of parallels there.
hackits 10y ago
I find it interesting that everyone gets so up-beat about the ideology or philosophical debate about objects sending each object messages, hell even not relying to a message one object send you until a later date. Without even thinking about concurrency, state, and hell even the basics such as cyclic loops within a event based system! Though I keep hearing from Alan and other prominent language designers that we still are holding onto this old 1960 mental model of command and control, or structured design concepts. Even some well spoken people suggest that the whole notion of object's are worthless to programmers because it takes place within the notion of classes and constraints of the machine. This whole philosophical debate about understanding/miss-understanding/correct usage of OOP is just a complete waste of time. For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace. If the category requires state then consider it as a object otherwise its considered a module. I've seen too many project's that have drunken the cool aid and has resulted in 5-10 level deep inheritance tree's with their own branching logic trying to fit behavior to a specific taxonomy.
- optforfon 10y ago
  "For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace.“ I mean you're just using different words to talk about the same thing. In your terminology inheritance is just extending a namespace and overloading names. How does that discredit or put into question the "mental model of command and control, or structured design concepts" If anything I feel the failure of OO languages is that they have been afraid of baking in proven design patterns/principles that reoccur over and over (ie. Gang of Four and a few more since then). Yesterday i was staring at some undocumented OpenCV code trying to figure out why there was some pointer that kept showing up in random places. After a very confusing 30 minutes i figured out it was actually the pImpl idiom. Now why do we have to have to reimplement the pImpl idiom each time? why can't this be a keyword?. The amount of code bloat and confusion that a visitor introduces is the prime reason I never use them. (There was an interesting proposal at CppCon 2 years ago that addressed this, but as far as I know it's not gone anywhere) The problem is that the most OO language trace back to C　which　IS a half-assed language from the perspective of "concurrency, state, and hell even the basics such as cyclic loops within a event based system" and most languages that do OO have been half baked on top of that foundation.
hackits 10y ago
I find it interesting that everyone gets so up-beat about the ideology or philosophical debate about objects sending each object messages, hell even not relying to a message one object send you until a later date. Without even thinking about concurrency, state, and hell even the basics such as cyclic loops within a event based system! Though I keep hearing from Alan and other prominent language designers that we still are holding onto this old 1960 mental model of command and control, or structured design concepts. Even some well spoken people suggest that the whole notion of object's are worthless to programmers because it takes place within the notion of classes and constraints of the machine. This whole philosophical debate about understanding/miss-understanding/correct usage of OOP is just a complete waste of time. For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace. If the category requires state then consider it as a object otherwise its considered a module. I've seen too many project's that have drunken the cool aid and has resulted in 5-10 level deep inheritance tree's with their own branching logic trying to fit behavior to a specific taxonomy.
unabst 10y ago
His distinction reminded me of what I wrote in a comment regarding Dissipative Adaptation and its relationship with language [1]. If Alan Kay is right, and Wittgenstein is right, and Prof. England is right, then we should be focusing on the language that emerges from the necessary transactions between functions, and let those transactions define the objects. That would make the modern popular understanding of OOP completely backwards -- as backwards as our understanding of the role of language prior to Wittgenstein and the role of thermodynamics in biology prior to England. Meaning, objects should not define (infer or induce or implement) the communication, nor the expression. Rather, all transactions (interactions, communications) should define (infer or induce or implement) the objects. And, given names, the objects will find a way to sort themselves based on rate of utility (the chosen objects, just as we choose the right words, from which refined definitions sort themselves). (Sorry for all the parentheses.) -- [1] https://news.ycombinator.com/item?id=11341397 https://news.ycombinator.com/item?id=11341397 Before Wittgenstein philosophers were obsessed with the factual nature of words and tried mapping everything correctly (logically) with the natural world. Except, they were failing. Wittgenstein came in and basically said language was never designed to represent reality, but rather is what emerges from the use cases between people. Communication is a transaction ("game" in his words), and not some mathematical or logical construct. It may have such properties, and the people and the context are all real, so reality is involved, but language is not a direct output, nor does it need to directly correlate to resist contradiction or paradox -- which are abound in philosophy. Except, for those who speak it, language is their reality. Those who cannot overcome their own immersion can never see past their own words, which sums up much of his opposition. They are all correct in their world and in their words... except Wittgenstein was talking about how words and worlds worked. In short, words can be arbitrary, and are constrained by the goal to communicate and transact. This exact phenomenon which Wittgenstein described as what we are doing is the phenomena England is describing as what biological systems are doing. It's all Dissipative Adaptation, with language being the unique construct for every such system that emerges and sustains it all.
markokrajnc 10y ago
This was the time when Java-magnet pulled people, money and momentum from the Smalltalk community...
- pjmlp 10y ago
  The year before Java was announced I was doing a SmaltalkWorks project at the university and it was part of our curriculum.
  - markokrajnc 10y ago
    You mean VisualWorks Smalltalk...
    - pjmlp 10y ago
      I guess, I didn't bother to search for how it used to be exactly called.
huuu 10y ago
I might be wrong, but I think people like Alan Kay and Christopher Alexander have in common that they: * see that things can be done better (not as in upgrade but best); * have a global idea/feeling of how this could be done; * take a lot of ideas from nature. And somehow I think they have a lot of trouble expressing the 'how'. My take: we should take a good look at nature because this is closest to what we are. For example the communication between objects could be learned from cells.
- gagege 10y ago
  > communication between objects could be learned from cells So, message queues? I completely agree.
  - huuu 10y ago
    Does queuing occur when cells communicate?
    - gagege 10y ago
      Sort of. AFAIK, cells basically just send out signals and the nearest available cell with a compatible protein that can "read" the signal picks it up.
      - huuu 10y ago
        Well I asked because lets say queuing does not occur, then you might want to design a system that can send and receive messages in without queue.
        gagege 10y ago
        Definitely. Designing a system where the order of procedures is not certain would be a very interesting challenge and could be very useful.
        TickleSteve 10y ago
k__ 10y ago
Why didn't he call it Message Oriented Programming then? Would have been a much clearer name. But now we have all these clunky OO-systems, that focus on objects and classes and still use functions/methods instead of messages...
- danbruc 10y ago
  Calling a method on an object is a kind of message passing - please take those arguments here, do your thing with them and send me back whatever return value you calculated. This really is just a synchronous exchange of two messages between the caller and the callee (plus you also give your processor to the callee to do his work because while you are waiting for the response you don't need it anyway).
- DougMerritt 10y ago
  > Why didn't he call it Message Oriented Programming then? He eventually said much the same thing (many people remember him as using your exact phrase, but I'm less sure about that): > [Kay:] 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"... [ Alan Kay, Usenet, 1998 ] http://c2.com/cgi/wiki?AlanKayOnMessaging http://c2.com/cgi/wiki?AlanKayOnMessaging Somewhere I read him saying that a key moment was when he was looking at (IIRC) Sussman's highly optimized Lisp dispatch of continuations, and realized that it was essentially the same thing as what Kay had in mind for Smalltalk. Something roughly like that. It may have been the first "X is a poor man's Y" observation.
norswap 10y ago
I've used Smalltalk, I've used Java. They are not not different in terms of the object mechanism. The only difference one could imagine is that you can treat messages as data through doesNotUnderstand in Smalltalk (the analog to method_missing in Ruby). That is by far not the predominant use case though. Otherwise, what makes method calls "messages" in Smalltalk, but not in Java? This mailing list entry has always sound like bogus philosophistry trying to defend an imaginary high ground.
mmczaplinski 10y ago
Does anyone know what Alan means by "assignments are a metalevel change from functions, and therefore should not be dealt with at the same level"? In what way are assignments a metalevel change from functions?
- frankenbagel 10y ago
  I believe he means that variable and their assignments are at a lower level. Objects interfaces should be defined in terms of the messages they can send and receive. No exposed variables: Variables should always be private/protected and are just used by the objects to maintain their internal state.
kmiroslav 10y ago
I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot of people still have this weird idea that message passing magically solves the problem of data integrity in parallelism. It doesn't. It does nothing to solve it. You can still have deadlocks and you can still have data corruption. The only approach that has provably improved our problems in this area is immutability, but even that paradigm comes at a cost that sometimes doesn't make it worth the trouble
- _asummers 10y ago
  What about e.g. HTTP? The dynamics of server to server communication are all about message passing (REST is just a message conveying state, if you ignore the other rules). Look at things like Erlang and Elixir processes. Akka and the actor model. Map/Reduce to a certain extent. These are all founded on the idea of giving a task out with enough information that the worker can reasonably go and work on the task without having to look around for state. Also look at things like FRP and more event driven architectures. While not ThingA sends message to ThingB, ThingA still broadcasts a message, possibly containing the relevant state. Also almost forgot. Look at the wealth of message queues that exist (RabbitMQ, ActiveMQ, SQS, Kafka, ... the list goes on).
  - ivan_gammel 10y ago
    HTTP is closer to RPC. You always know the address of the routine to call, so it's not actually a message (except in HATEOAS, in which you first need to learn the next address from last API call). Closest analogy is the message queue (e.g. ESB) like Active MQ or Rabbit MQ (and the whole JMS tech), in which you do actually send a message and infrastructure does actually figure out who will receive and process it.
    - specialist 10y ago
nix0n 10y ago
This sounds a little bit like microservices, which are at the very least a heavy-handed way to enforce separation of concerns. (I know they can't possibly be what Alan Kay was talking about in 1998.)
Dangeranger 10y ago
Here is another important clarification email from Alan regarding the meaning of OOP that I found to also be helpful: http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
- Dangeranger 10y ago
  Note this email and conclusion are from 2003-07-23: > 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.
  - dfox 10y ago
    The original article gives some important context to this sentence, as otherwise it is slightly weird, as both ST-80 (at least in comparison to earlier Smalltalks) and CLOS does not have that much explicit concept of messaging and in both cases it's essentially late bound function call.
    - gnaritas 10y ago
      What? Smalltalk80 has #doesNotUnderstand: which allows explicit handling of messages directly so no, it's not a late bound function call.
skybrian 10y ago
I'm thinking the closest mainstream thing to real messages is probably event handling. Events are nearly always represented as objects of some sort (rather than something simpler like a function call) and event routing is the heart of any UI framework. So maybe the question is whether we should be using events (and streams of events) more? But this doesn't seem like a neglected area - publish/subscribe is pretty common and there's plenty of recent discussion of reactive systems and event-handling architectures.
- grandalf 10y ago
  > But this doesn't seem like a neglected area It is generally considered a suited for a different class of problems. I think Kay's point is that decoupling the messages from an object's internal state is a smart approach to system design. Many of the other "features" of OOP get in the way of this design principle.
- Joeri 10y ago
  It is much broader than events. Anything where you sit and wait for some piece of data to happen and trigger code can be viewed as receiving messages. An object that sits in memory and has its methods called is receiving messages. A piece of code that calls methods on objects is sending messages. A variable containing data is a message at rest, and once passed to a method becomes a message in transit. If you then start thinking about things like generators, you see that this is just another way of sending messages. You can take any program and view it entirely as a collection of messages, with the objects and procedures being the glue between the messages. The issue that languages have, is that the syntax obscures this fact instead of highlighting it. There are many different ways of sending a message between objects, and none of them are labeled as such. But essentially, there are just two different models that matter: synchronous send + receive (receive the replied message, the method's return value, before moving on), and asynchronous send + receive (where the receive remembers the context of what was sent that is being replied to). A really simple OO language would just implement those two operations between objects, and would need nothing else.
jonahx 10y ago
I'd love clarification on a few points, from anyone who understands everything Alan says here: Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles? If you focus on just messaging -- and realize that a good metasystem can late bind the various 2nd level architectures used in objects What is a metasystem? Can you provide an example? Similarly, what are 2nd level architectures? the realization that assignments are a metalevel change from functions, and therefore should not be dealt with at the same level what does he mean here? what are the two "metalevels" of assignments vs functions? what are examples of other "metalevels"? i've just never heard these terminology in this context, so don't know where to start in understanding it...
- endlessvoid94 10y ago
  > Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles? My interpretation is that the design of TCP/IP (and maybe HTTP?) focuses on the behavior of the components from the perspective of how they communicate with one another, not how they behave internally. They follow the Robustness Principle: Be conservative in what you do, and liberal in what you accept from others. > What is a metasystem? Can you provide an example? Similarly, what are 2nd level architectures? It took me a long time to understand what this means. Basically, a metasystem is a blurring of the language and the code you write within that language. Smalltalk is an example of such a system because you can change the language itself from within the language and the environment. There are downsides to such a system, though, including the proliferation of many fragmented, inconsistent environments. To take a deliberately ridiculous example, let's imagine Ruby was a metasystem. You write some code in your rails app that allows a third method privacy mechanism beyond public, private, and protected. Or, that you decide you want multiple inheritance in ruby. That's powerful -- and dizzying for many people not accustomed to thinking about their languages at that level. So, what Alan is suggesting is that we erect "fences" of some kind to both allow this power in our languages but in a protected manner, so that we mitigate the risk of the fragmented world that could result. (Since you've essentially created a new "flavor" of ruby by changing its behavior.) There is a fantastic book on this topic called "The Art of the Metaobject Protocol" that I highly recommend. It guides you through building an object oriented language construct from within Common Lisp. I don't know what he means by 2nd-level architectures, nor what he's saying about assignments being meta-level change from functions.
ninjakeyboard 10y ago
Poor Alan Kay. "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97
stcredzero 10y ago
Isn't a lack of direct hardware/ISA support for message passing becoming apparent in today's world of multicore architectures? The Disruptor library used by HFT shops and much of Erlang seem to suggest a need for this.
- astrange 10y ago
  Generally speaking anything that's essentially pointer chasing can't be moved to hardware, because they'd make it with microcode and that's just hard-to-update software. http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html
matchagaucho 10y ago
Passing objects as method parameters and returning objects are sadly underutilized. The look on Developers faces when I suggest this refactoring pattern seems to say "but that class doesn't do anything but encapsulate message data."

240 points by mmphosis 10y ago

More from Alan Kay: http://alan-kay.wikia.com/wiki/Alan_Kay_Wiki http://alan-kay.wikia.com/wiki/Alan_Kay_Wiki

mej10 10y ago

Are there any examples of Kay's ideal other than The Internet? Especially systems that I could actually inspect and learn about in detail, rather than read short stories about.

blihp 10y ago
Squeak[1]/Smalltalk? (i.e. have you worked with what he would consider a 'real' message-oriented OO language?) [1] http://squeak.org/downloads/ http://squeak.org/downloads/
- mej10 10y ago
  I played around with Squeak many years ago, but might appreciate it more now. What recently spurred more confusion on this topic was Alan Kay's discussion with Rich Hickey during the AMA the other day. https://news.ycombinator.com/item?id=11945722 https://news.ycombinator.com/item?id=11945722 I found it really hard to understand what Alan Kay is actually talking about. Saying things like > This is why "the objects of the future" have to be ambassadors that can negotiate with other objects they've never seen. This seems like something that (based on my limited knowledge) isn't possible with Smalltalk (in any but the most trivial of cases), and so I don't really consider it an example of what he is talking about. Or, at least, all of the things that I know of that you can do with this you could just as easily implement in languages without the same dynamism as Smalltalk. My conclusion after reading all of that is that Kay is talking about a system so completely unlike anything we have that there aren't even really examples of what it would look like. I am really trying to understand what Kay is talking about, so any pointers would be interesting!
  - blihp 10y ago
    You are correct, Smalltalk as-is can't currently do that. I believe he was referring to a future language / evolution / system that he would like to see, not something that currently exists. These are the sorts of things I think he's expressing his frustration about when he says things like Smalltalk getting long in the tooth etc. in that it was never intended to the be-all, end-all of languages... just one stop along a path. But don't let this discourage you from looking into Squeak. I played around with Squeak in the 90's but couldn't see past things like the weird mouse button mappings and color scheme. Fortunately I came back to it again and found some of the glaring UI issues (by modern standards) had been smoothed over. It also probably didn't hurt that I was a little older and better able to stick with it until I could finally see better the second go at it what the original vision was. Also, there is the work from his STEPS project which used Squeak as a platform that was used to prototype some of the next-generation ideas he talks about. If you want to understand better the next generation concepts, definitely look at the VPRI writings (esp. the STEPS annual reports) linked to in a previous post. To bridge the gap from here to there (i.e. to get to a tangible system that you can actually use that does any of this) I think you're probably going to want to learn Smalltalk as a starting point.
  - panic 10y ago
    Here's my understanding of the general idea (let me know if I got something wrong!). Say you have a bunch of computers with different software and hardware. You come up with a cool new image format called "PJEG". To get the images to show up on all the computers, you typically do the following: * Publish a PJEG spec * Define a .pjeg extension and let everyone know that means it's a PJEG file * Write a PJEG encoder/viewer for each kind of computer * Distribute these programs to the computers * Configure the computers to open .pjeg files using the programs you distributed * Modify other programs (image editors, web browsers) so they can recognize, encode and view PJEG files as well * etc... This approach doesn't scale very well. I think the alternative Alan is suggesting is that you'd include an interpretable description of the file format in the file itself in a sort of meta-format. Once you have an interpreter for these meta-format descriptions, all you'd have to do is: * Include an interpretable PJEG encoder/viewer with every PJEG file And that's all! Any program able to read the meta-format could use this file without any extra software. This obviates file type metadata and reduces the amount of distribution you need to do, making the whole thing way more scalable. The practical problems with this solution (larger file size, slow encoding and decoding) can be solved in various ways: * The larger file size can be mitigated by format negotiation (if I already know about the format, you don't have to tell me about it) * Optimized encoders and decoders can be written to replace the slower interpreted ones included with the file Having the interpreted format description makes it easier to validate the optimized version, too (you can generate a bunch of random examples and make sure they decode/encode the same way). And this doesn't have to just be for files, you can use the same technique for arbitrary "data types" in your program as well.
minskyway 10y ago
Writings: http://vpri.org/html/writings.php http://vpri.org/html/writings.php Software: http://www.vpri.org/vp_wiki/index.php?title=Main_Page http://www.vpri.org/vp_wiki/index.php?title=Main_Page
z1mm32m4n 10y ago
Hearing the way Alan Kay talks about "messaging" always reminds me of two technologies: the Flux/Redux architecture and Apache Samza & Kafka. > The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. With React and Flux, this is exactly what's going on! You're defining view components, and when someone interacts with them, there's a very structured, discrete set of actions that can be fired. These actions are then dispatched and handled elsewhere, but somewhere at the core, there's a single source of truth for what happens upon any given message. And for Apache Samza, I think this video[1] does a nice job of talking about stream processing as a programming architecture. There's a connection to be made between processing streams of information and processing messages between modules, and that video goes a good way towards exposing it. [1]: https://www.youtube.com/watch?v=fU9hR3kiOK0 https://www.youtube.com/watch?v=fU9hR3kiOK0 "Turning the database inside out with Apache Samza"
- michaelscott 10y ago
  Redux is definitely a step in that direction. Elm, which it's inspired by, is even further along that road in that its design is better handled (but then it doesn't require handling in JavaScript so I suppose that is why)
panic 10y ago
Biological cells: I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful). (from http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en)
- sixo 10y ago
  I wonder: what is that last sentence referring to? What got it right first? (Or gets it right now?)
mietek 10y ago
Erlang.
- Sharlin 10y ago
  And actor-based systems in general. Akka is a good modern example of one that's not Erlang.
jacquesm 10y ago
Any complex system based on QnX would probably qualify.

deleted 10y ago

[deleted]

elchief 10y ago

How is messaging different than calling a method?

achamayou 10y ago
It implies more flexibility, like generically accepting messages, passing them on without knowing anything about them etc.
dang 10y ago
Alan commented on this several times in the AMA he did here a couple days ago: https://news.ycombinator.com/item?id=11957001 https://news.ycombinator.com/item?id=11957001 https://news.ycombinator.com/item?id=11945986 https://news.ycombinator.com/item?id=11945986 https://news.ycombinator.com/item?id=11945123 https://news.ycombinator.com/item?id=11945123
- stinos 10y ago
  I have to admit I still have basically no idea what he's talking about when he says 'messaging'. A practical example would be useful for us non-CS-degree programmers who don't speak any of the CS lingo.
  - pdkl95 10y ago
    The idea is to replace "calling a function" with "sending a message". Traditionally a function call is fixed at compile time (with some exceptions such as function pointers). In C a function is just an address; if we want to call foo(), we must have that function available at address &foo. C++ added flexibility by allowing there to be multiple functions called foo() with and a set of vtables[1] that store the actual (C-style) address. Other variations exist, but all of these traditional styles map function calls to specific code that runs every time the function is called. Message change all of that. Instead of vtables (or similar) obj = create_foo() # instead of calling foo's bar() function directly, e.g. foo_bar(obj) # or perhaps obj.bar() ... we send a message by name of the function we want to call to the object itself obj = create_foo() obj.send_message("bar") # if function args are needed, include them as an array obj.send_message("baz", [42, "quux"]) The idea is that while the message can be effectively the same as a function call, it doesn't have to be. In a proper OO language, this message sending is handled automagically by the syntax. # instead of handling the messages directly, e.g. obj.send_message("bar") # the language does that for you when you call obj.bar() # in some languages, these are equivalent In many cases the "foo" class above will handle the message "bar" by running the appropriate function, but that isn't required. For example, in ruby when no function exists for a given message, the raw message is send to the #method_missing function. class Foo def method_missing(name, *args, &block) puts "#{self.inspect} I was sent message #{name.inspect} with args #{args.inspect}" end end >> obj = Foo.new => #<Foo> >> obj.bar() #<Foo> I was sent message :bar with args [] => nil >> obj.any_name_we_want() #<Foo> I was sent message :any_name_we_want with args [] => nil >> obj.any_name_we_want("args", "are", "optional") #<Foo> I was sent message :any_name_we_want with args ["args", "are", "optional"] Thinking of "obj.method()" as a message instead of only a function is much more flexible. [1] https://en.wikipedia.org/wiki/Virtual_method_table https://en.wikipedia.org/wiki/Virtual_method_table

lacker 10y ago

IMO the problem with object-oriented programming is that it turned into the standard curriculum for peoples' first semester of computer science, rather than being yet another interesting concept that advanced programmers would ponder. And the way we handle "the standard CS curriculum" sucks. (In the USA at least.) For example, AP Computer Science requires Java and tries to teach stuff like designing inheritance hierarchies to people in their first two months of programming education. And then tests it mostly using multiple-choice quizzes. It's totally inappropriate - most of these students would fail fizzbuzz. OOP should be something you only get into after you have written some practical programs, rather than something where you can't program, but you memorize the difference between "is-a" and "has-a" inheritance so that you can pass multiple choice tests.

stevedonovan 10y ago
OOP made sense to people who already knew structured programming and understood functional decomposition (what we now call 'refactoring'). Perhaps education should start with that and then justify OOP? I remember reading about the original LOGO experiments; one thing kids do not spontaneously do is break up their monolithic actions into sensible functions.
- lacker 10y ago
  Yeah "breaking up a complex function into simpler functions" is a great example of something that isn't taught well today, yet is simpler and more critical than what we try to teach people in intro courses. I think of it in analogy to math. OOP is like topology - it's definitely useful in some cases, it's not too hard for an experienced mathematician to get the basics, and yet in a lot of situations it's irrelevant and it doesn't really belong in the first class you take. Being able to solve fizzbuzz is like doing arithmetic. If you can't solve fizzbuzz then you aren't going to be able to really get any advanced concepts. It's like you can't be a good mathematician if you can't figure out whether 351 is an odd number - you need to learn the basics first, even if "real math isn't about arithmetic". Sadly, you can tell if you do a lot of phone screens that many people who graduate with CS degrees still can't code fizzbuzz. Our CS education is busted right at the beginning. It needs to get the basics right, like, can you write loops, can you write functions. Today it is failing at that.

damienkatz 10y ago

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." What he's describing is the essence of Erlang.

jacquesm 10y ago
Yes, there are a lot of parallels there.

hackits 10y ago

I find it interesting that everyone gets so up-beat about the ideology or philosophical debate about objects sending each object messages, hell even not relying to a message one object send you until a later date. Without even thinking about concurrency, state, and hell even the basics such as cyclic loops within a event based system! Though I keep hearing from Alan and other prominent language designers that we still are holding onto this old 1960 mental model of command and control, or structured design concepts. Even some well spoken people suggest that the whole notion of object's are worthless to programmers because it takes place within the notion of classes and constraints of the machine. This whole philosophical debate about understanding/miss-understanding/correct usage of OOP is just a complete waste of time. For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace. If the category requires state then consider it as a object otherwise its considered a module. I've seen too many project's that have drunken the cool aid and has resulted in 5-10 level deep inheritance tree's with their own branching logic trying to fit behavior to a specific taxonomy.

optforfon 10y ago
"For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace.“ I mean you're just using different words to talk about the same thing. In your terminology inheritance is just extending a namespace and overloading names. How does that discredit or put into question the "mental model of command and control, or structured design concepts" If anything I feel the failure of OO languages is that they have been afraid of baking in proven design patterns/principles that reoccur over and over (ie. Gang of Four and a few more since then). Yesterday i was staring at some undocumented OpenCV code trying to figure out why there was some pointer that kept showing up in random places. After a very confusing 30 minutes i figured out it was actually the pImpl idiom. Now why do we have to have to reimplement the pImpl idiom each time? why can't this be a keyword?. The amount of code bloat and confusion that a visitor introduces is the prime reason I never use them. (There was an interesting proposal at CppCon 2 years ago that addressed this, but as far as I know it's not gone anywhere) The problem is that the most OO language trace back to C　which　IS a half-assed language from the perspective of "concurrency, state, and hell even the basics such as cyclic loops within a event based system" and most languages that do OO have been half baked on top of that foundation.

hackits 10y ago

unabst 10y ago

His distinction reminded me of what I wrote in a comment regarding Dissipative Adaptation and its relationship with language [1]. If Alan Kay is right, and Wittgenstein is right, and Prof. England is right, then we should be focusing on the language that emerges from the necessary transactions between functions, and let those transactions define the objects. That would make the modern popular understanding of OOP completely backwards -- as backwards as our understanding of the role of language prior to Wittgenstein and the role of thermodynamics in biology prior to England. Meaning, objects should not define (infer or induce or implement) the communication, nor the expression. Rather, all transactions (interactions, communications) should define (infer or induce or implement) the objects. And, given names, the objects will find a way to sort themselves based on rate of utility (the chosen objects, just as we choose the right words, from which refined definitions sort themselves). (Sorry for all the parentheses.) -- [1] https://news.ycombinator.com/item?id=11341397 https://news.ycombinator.com/item?id=11341397 Before Wittgenstein philosophers were obsessed with the factual nature of words and tried mapping everything correctly (logically) with the natural world. Except, they were failing. Wittgenstein came in and basically said language was never designed to represent reality, but rather is what emerges from the use cases between people. Communication is a transaction ("game" in his words), and not some mathematical or logical construct. It may have such properties, and the people and the context are all real, so reality is involved, but language is not a direct output, nor does it need to directly correlate to resist contradiction or paradox -- which are abound in philosophy. Except, for those who speak it, language is their reality. Those who cannot overcome their own immersion can never see past their own words, which sums up much of his opposition. They are all correct in their world and in their words... except Wittgenstein was talking about how words and worlds worked. In short, words can be arbitrary, and are constrained by the goal to communicate and transact. This exact phenomenon which Wittgenstein described as what we are doing is the phenomena England is describing as what biological systems are doing. It's all Dissipative Adaptation, with language being the unique construct for every such system that emerges and sustains it all.

markokrajnc 10y ago

This was the time when Java-magnet pulled people, money and momentum from the Smalltalk community...

pjmlp 10y ago
The year before Java was announced I was doing a SmaltalkWorks project at the university and it was part of our curriculum.
- markokrajnc 10y ago
  You mean VisualWorks Smalltalk...
  - pjmlp 10y ago
    I guess, I didn't bother to search for how it used to be exactly called.

huuu 10y ago

I might be wrong, but I think people like Alan Kay and Christopher Alexander have in common that they: * see that things can be done better (not as in upgrade but best); * have a global idea/feeling of how this could be done; * take a lot of ideas from nature. And somehow I think they have a lot of trouble expressing the 'how'. My take: we should take a good look at nature because this is closest to what we are. For example the communication between objects could be learned from cells.

gagege 10y ago
> communication between objects could be learned from cells So, message queues? I completely agree.
- huuu 10y ago
  Does queuing occur when cells communicate?
  - gagege 10y ago
    Sort of. AFAIK, cells basically just send out signals and the nearest available cell with a compatible protein that can "read" the signal picks it up.
    - huuu 10y ago
      Well I asked because lets say queuing does not occur, then you might want to design a system that can send and receive messages in without queue.
      - gagege 10y ago
        Definitely. Designing a system where the order of procedures is not certain would be a very interesting challenge and could be very useful.
      - TickleSteve 10y ago

k__ 10y ago

Why didn't he call it Message Oriented Programming then? Would have been a much clearer name. But now we have all these clunky OO-systems, that focus on objects and classes and still use functions/methods instead of messages...

danbruc 10y ago
Calling a method on an object is a kind of message passing - please take those arguments here, do your thing with them and send me back whatever return value you calculated. This really is just a synchronous exchange of two messages between the caller and the callee (plus you also give your processor to the callee to do his work because while you are waiting for the response you don't need it anyway).
DougMerritt 10y ago
> Why didn't he call it Message Oriented Programming then? He eventually said much the same thing (many people remember him as using your exact phrase, but I'm less sure about that): > [Kay:] 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"... [ Alan Kay, Usenet, 1998 ] http://c2.com/cgi/wiki?AlanKayOnMessaging http://c2.com/cgi/wiki?AlanKayOnMessaging Somewhere I read him saying that a key moment was when he was looking at (IIRC) Sussman's highly optimized Lisp dispatch of continuations, and realized that it was essentially the same thing as what Kay had in mind for Smalltalk. Something roughly like that. It may have been the first "X is a poor man's Y" observation.

norswap 10y ago

I've used Smalltalk, I've used Java. They are not not different in terms of the object mechanism. The only difference one could imagine is that you can treat messages as data through doesNotUnderstand in Smalltalk (the analog to method_missing in Ruby). That is by far not the predominant use case though. Otherwise, what makes method calls "messages" in Smalltalk, but not in Java? This mailing list entry has always sound like bogus philosophistry trying to defend an imaginary high ground.

mmczaplinski 10y ago

Does anyone know what Alan means by "assignments are a metalevel change from functions, and therefore should not be dealt with at the same level"? In what way are assignments a metalevel change from functions?

frankenbagel 10y ago
I believe he means that variable and their assignments are at a lower level. Objects interfaces should be defined in terms of the messages they can send and receive. No exposed variables: Variables should always be private/protected and are just used by the objects to maintain their internal state.

kmiroslav 10y ago

I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot of people still have this weird idea that message passing magically solves the problem of data integrity in parallelism. It doesn't. It does nothing to solve it. You can still have deadlocks and you can still have data corruption. The only approach that has provably improved our problems in this area is immutability, but even that paradigm comes at a cost that sometimes doesn't make it worth the trouble

_asummers 10y ago
What about e.g. HTTP? The dynamics of server to server communication are all about message passing (REST is just a message conveying state, if you ignore the other rules). Look at things like Erlang and Elixir processes. Akka and the actor model. Map/Reduce to a certain extent. These are all founded on the idea of giving a task out with enough information that the worker can reasonably go and work on the task without having to look around for state. Also look at things like FRP and more event driven architectures. While not ThingA sends message to ThingB, ThingA still broadcasts a message, possibly containing the relevant state. Also almost forgot. Look at the wealth of message queues that exist (RabbitMQ, ActiveMQ, SQS, Kafka, ... the list goes on).
- ivan_gammel 10y ago
  HTTP is closer to RPC. You always know the address of the routine to call, so it's not actually a message (except in HATEOAS, in which you first need to learn the next address from last API call). Closest analogy is the message queue (e.g. ESB) like Active MQ or Rabbit MQ (and the whole JMS tech), in which you do actually send a message and infrastructure does actually figure out who will receive and process it.
  - specialist 10y ago

nix0n 10y ago

This sounds a little bit like microservices, which are at the very least a heavy-handed way to enforce separation of concerns. (I know they can't possibly be what Alan Kay was talking about in 1998.)

Dangeranger 10y ago

Here is another important clarification email from Alan regarding the meaning of OOP that I found to also be helpful: http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

Dangeranger 10y ago
Note this email and conclusion are from 2003-07-23: > 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.
- dfox 10y ago
  The original article gives some important context to this sentence, as otherwise it is slightly weird, as both ST-80 (at least in comparison to earlier Smalltalks) and CLOS does not have that much explicit concept of messaging and in both cases it's essentially late bound function call.
  - gnaritas 10y ago
    What? Smalltalk80 has #doesNotUnderstand: which allows explicit handling of messages directly so no, it's not a late bound function call.

skybrian 10y ago

I'm thinking the closest mainstream thing to real messages is probably event handling. Events are nearly always represented as objects of some sort (rather than something simpler like a function call) and event routing is the heart of any UI framework. So maybe the question is whether we should be using events (and streams of events) more? But this doesn't seem like a neglected area - publish/subscribe is pretty common and there's plenty of recent discussion of reactive systems and event-handling architectures.

grandalf 10y ago
> But this doesn't seem like a neglected area It is generally considered a suited for a different class of problems. I think Kay's point is that decoupling the messages from an object's internal state is a smart approach to system design. Many of the other "features" of OOP get in the way of this design principle.
Joeri 10y ago
It is much broader than events. Anything where you sit and wait for some piece of data to happen and trigger code can be viewed as receiving messages. An object that sits in memory and has its methods called is receiving messages. A piece of code that calls methods on objects is sending messages. A variable containing data is a message at rest, and once passed to a method becomes a message in transit. If you then start thinking about things like generators, you see that this is just another way of sending messages. You can take any program and view it entirely as a collection of messages, with the objects and procedures being the glue between the messages. The issue that languages have, is that the syntax obscures this fact instead of highlighting it. There are many different ways of sending a message between objects, and none of them are labeled as such. But essentially, there are just two different models that matter: synchronous send + receive (receive the replied message, the method's return value, before moving on), and asynchronous send + receive (where the receive remembers the context of what was sent that is being replied to). A really simple OO language would just implement those two operations between objects, and would need nothing else.

jonahx 10y ago

I'd love clarification on a few points, from anyone who understands everything Alan says here: Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles? If you focus on just messaging -- and realize that a good metasystem can late bind the various 2nd level architectures used in objects What is a metasystem? Can you provide an example? Similarly, what are 2nd level architectures? the realization that assignments are a metalevel change from functions, and therefore should not be dealt with at the same level what does he mean here? what are the two "metalevels" of assignments vs functions? what are examples of other "metalevels"? i've just never heard these terminology in this context, so don't know where to start in understanding it...

endlessvoid94 10y ago
> Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles? My interpretation is that the design of TCP/IP (and maybe HTTP?) focuses on the behavior of the components from the perspective of how they communicate with one another, not how they behave internally. They follow the Robustness Principle: Be conservative in what you do, and liberal in what you accept from others. > What is a metasystem? Can you provide an example? Similarly, what are 2nd level architectures? It took me a long time to understand what this means. Basically, a metasystem is a blurring of the language and the code you write within that language. Smalltalk is an example of such a system because you can change the language itself from within the language and the environment. There are downsides to such a system, though, including the proliferation of many fragmented, inconsistent environments. To take a deliberately ridiculous example, let's imagine Ruby was a metasystem. You write some code in your rails app that allows a third method privacy mechanism beyond public, private, and protected. Or, that you decide you want multiple inheritance in ruby. That's powerful -- and dizzying for many people not accustomed to thinking about their languages at that level. So, what Alan is suggesting is that we erect "fences" of some kind to both allow this power in our languages but in a protected manner, so that we mitigate the risk of the fragmented world that could result. (Since you've essentially created a new "flavor" of ruby by changing its behavior.) There is a fantastic book on this topic called "The Art of the Metaobject Protocol" that I highly recommend. It guides you through building an object oriented language construct from within Common Lisp. I don't know what he means by 2nd-level architectures, nor what he's saying about assignments being meta-level change from functions.

ninjakeyboard 10y ago

Poor Alan Kay. "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97

stcredzero 10y ago

Isn't a lack of direct hardware/ISA support for message passing becoming apparent in today's world of multicore architectures? The Disruptor library used by HFT shops and much of Erlang seem to suggest a need for this.

astrange 10y ago
Generally speaking anything that's essentially pointer chasing can't be moved to hardware, because they'd make it with microcode and that's just hard-to-update software. http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html

matchagaucho 10y ago

Passing objects as method parameters and returning objects are sadly underutilized. The look on Developers faces when I suggest this refactoring pattern seems to say "but that class doesn't do anything but encapsulate message data."