8 ms·

Alan Kay on Messaging (1998)

136 points by stesch 11y ago

delish 11y ago
Just a little comment: Kay's mentioning various meta-things reminds me that I have The Art of the Metaobject Protocol (which Kay called "the best OOP book in ten years," and I should read it. And another little comment as regards Kay's "complaining" that Smalltalk had become "something to be learned": I very much failed to learn computer science from high school Java, where classes, methods, encapsulation etc were treated as things-to-be-learned. I didn't know that I /could/ care about how they were put in place or why. If I had been taught that everything in a meta-system can be changed when you structure your changes, I would have been a happier camper--motivated by autonomy and purpose.
- agumonkey 11y ago
  I felt the same. People differ in the way they interact with systems and logic. I certainly disliked being fed the Java way rigidly. I actually learned more about basic OOP by simulating it in ADA. Some people like to understand by building. But it's also valuable to understand an abstraction outside of any implementation. In the end it's better to have done both. And I feel strongly that to understand programming, one must write an interpreter and a compiler, so you can reason about the different abstraction levels clearly, without blind spots or dark magic.
- parasubvert 11y ago
  The art of the meta object protocol was good, it basically was a well-written code commentary for how to build an advanced OO meta system (CLOS) for LISP. CLOS was a bit of a dream language, I'd say Scala is perhaps the closest practical language in terms of ideas. Interestingly, this work led Gregor Kiczales & team to create Aspect Oriented Programming - a subset of his metasystem - which became somewhat popular with Java and the Spring framework's use of AspectJ. http://en.m.wikipedia.org/wiki/Aspect-oriented_programming http://en.m.wikipedia.org/wiki/Aspect-oriented_programming As an aside, I found in college (let along high school!) that students have almost anti-philosophical learning objectives. The SICP approach of teaching computer science from the metasystem up with Scheme (and then possibly moving on to CLOS/Lisp) was near-universally hated among my peers (1996-2002) - most wanted a practical language they could "get a job" with. I believe MIT first year CS switched to Python in part to deal with this resistance.
  - mbrock 11y ago
    What makes Scala more "practical" than Common Lisp, other than incidental matters of library support on the JVM?
    - parasubvert 11y ago
      That, and the dearth of people that know CLOS, or are able and WANT to learn CLOS. "Design by resume" surrounds us.
  - DalekBaldwin 11y ago
    AOP also encompasses techniques you can't find in CLOS/MOP. The analogues to before/after/around methods are the easiest concepts to implement and reason about, so those are what popular language extensions tend to emphasize. But if you look at the original AOP papers describing Reverse Graphics, you'll see an AOP system used to liberally restructure the control flow of the entire base program, not just augment its behavior. It was an early version of what you can see now in something like the Halide language. > I believe MIT first year CS switched to Python in part to deal with this resistance. In part. The full story is a bit more depressing: http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python http://www.wisdomandwonder.com/link/2110/why-mit-switched-fr... Most of the other top universities that had used SICP also switched shortly after MIT.
  - xenophonf 11y ago
    > most wanted a practical language they could "get a job" with This was me in college. Especially early on, I kept hounding my professors why they weren't teaching a particular language (e.g., C++) or toolchain (Visual Studio). It wasn't until well after I graduated that I appreciated the distinction between using tools and making tools---and that my professors taught me the latter.
- frik 11y ago
  JavaScript in a browser + DevTools offer a similar environment to Smalltalk + Squeak. http://en.wikipedia.org/wiki/Squeak http://en.wikipedia.org/wiki/Squeak One can change everything, and manipulate even the UI. Even the DevTools in all browsers nowadays are HTML5 iframes. Manipulating the objects and meta/prototype objects are features that both languages allow. Though they are different, and afaik only JS is called a prototype based programming language: http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming
  - vezzy-fnord 11y ago
    JavaScript in a browser + DevTools offer a similar environment to Smalltalk + Squeak. Sure, they're "similar", but at a relatively low approximation. The capabilities of the Smalltalk environments are simply on a different plane. Manipulating the objects and meta/prototype objects are features that both languages allow. This is sort of a bare minimum for all OO languages. Even Java with its rigidity allows for complex tricks with reflection and method body replacements for hot code reloading.
    - mbrock 11y ago
      Can you formulate more precisely (or by example) what you mean by "simply on a different plane"?
      - vezzy-fnord 11y ago
        See the Design Principles Behind Smalltalk article: https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.... Some relevant excerpts: Here are some examples of conventional operating system components that have been naturally incorporated into the Smalltalk language: [...] Display handling -- The display is simply an instance of class Form, which is continually visible, and the graphical manipulation messages defined in that class are used to change the visible image. [...] Debugger -- The state of the Smalltalk processor is accessible as an instance of class Process that owns a chain of stack frames. The debugger is just a Smalltalk subsystem that has access to manipulate the state of a suspended process. It should be noted that nearly the only run-time error that can occur in Smalltalk is for a message not to be recognized by its receiver. Smalltalk has no "operation system" as such. The necessary primitive operations, such as reading a page from the disk, are incorporated as primitive methods in response to otherwise normal Smalltalk messages. This is from 1981, BTW.
parasubvert 11y ago
I remember this being posted in 1998, as people were debating the surge of Java relative to C++ or Smalltalk. These were the twilight days where C and assembly were the only language Real Programmers used, Perl and Tcl or any scripting/interpreted language were considered toys for sysops and never meant for production, OO was treated with deep suspicion, and functional languages were considered crazy talk. I remember people in my company saying a particular C++ replacement program my colleague wrote was "too OO" and would execute 10x slower than required (when it was 2x faster than the legacy). Point is, a lot of what Kay says is obvious now, but it wasn't in the 90s, and it REALLY wasn't in the 70s. One sees new things every time one reads this. For example, Kay comes out as a supporter (of sorts) to functional programming principles by calling assignments (mutable state) a metalevel change.
- mikro2nd 11y ago
  1998?... More like the twilight days when Cobol still ruled the land and we thought (feared) that it would never die. Fortunes were being made consulting on the Y2K bug and patching the dodgy Cobol systems responsible. I do agree, though that OO was treated with suspicion and hostility. Only a tiny number of (us) mavericks were brave enough (or foolish enough) to propose using what our management saw as a "newfangled and risky" proposition. Let's not even mention mucking about with Extreme Programming. ;)
  - parasubvert 11y ago
    Oh yes, COBOL was C's evil twin in that regard. It depended what circles you travelled in - engineering depts or IT depts. I remember posting the c2 wiki pages for XP on my cube wall when XP first came out, and had a Gantt-chart oriented systems engineer tear them down as dangerous nonsense.
- zak_mc_kracken 11y ago
  > Point is, a lot of what Kay says is obvious now It's obvious because he's not saying much, besides trying to redefine "function call" with "message passing" so that it makes Smalltalk look better.
lazydon 11y ago
If the big idea was messaging and not objects, I'm curious to know how did we end up in this primarily object oriented world. Especially, when its founding father didn't had that intention as he says: ""I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind". I have a guess from following quote: "This was why I complained at the last OOPSLA that - whereas at PARC we changed Smalltalk constantly, treating it always as a work in progress - when ST hit the larger world, it was pretty much taken as "something just to be learned", as though it were Pascal or Algol." - There were people in hurry to make something with whatever theoretical basis there was instead of further refining the original concept. Probably, that's where it took the wrong turn.
- parasubvert 11y ago
  Refining a language or programming paradigm requires a philosophical or scientific bent. Not much money in that. Most people just want to get a job done and go home at 5pm. Edit: Bright side, I think polyglot programming is more popular now than ever in history. In the past you learned one language and that was 20 years of your career before you went into management. Your identity was wrapped up in being a "VB person", "C", "COBOL", or "Java/C# person" or "Rubyist" . There still is language identity politics but I think Ruby might have been the last of the One True Religions, now the frontier is all over the place between Python, Ruby, Node, Java, Golang, c#, etc.
  - coliveira 11y ago
    I think it is a perversion of computer science that we think ourselves as users of languages, instead of creators of languages. Especially because it is not hard to create a language these days -- we know much more and have better tools than people 30 years ago. Many of the problems that we consider uber-complicated could be relatively easily solved by creating appropriate problem-specific languages: consider web programming, data mining, etc.
    - parasubvert 11y ago
      I'm with you. But it becomes a skills and NIH-attitude issue at scale, where the evolution of science is less of a concern than treating the science as constant for an engineering project. I've seen lovely crafted DSLs that were deemed unmaintainable when the creator moved on, and management cursed the use of them if they weren't already a popular OSS project.
pacala 11y ago
> The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word - ma - for "that which is in between" - perhaps the nearest English equivalent is "interstitial". 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. Think of the internet - to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. What is the difference between "messaging" and "function call"? "messaging" data into a module = call a function with the data as arguments. "messaging" data out of a module = package the data as the return of the function.
- contingencies 11y ago
  Think of the internet... Great quote along these lines is: Upgrade cost of network complexity: The Internet has smart edges ... and a simple core. Adding an new Internet service is just a matter of distributing an application ... Compare this to voice, where one has to upgrade the entire core. - RFC3439 (2002) ... from my fortune clone @ https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
- frik 11y ago
  > What is the difference between "messaging" and "function call"? If the object supports the message, then it will execute some code. Otherwise it will just ignore it. This is a more dynamic approach than an explicit function/method call where the object must support that function. You can think of e.g. Javascript events plus function calls (callbacks) that pass an object ("message") and a typeof/switch check as an equivalent.
- sitkack 11y ago
  Messaging is a protocol level abstraction, communication between entities [1]. A function call is a much lower level abstraction that does a <verb> to/with the data. One could have an entity that executes one function or many, or it could manage a whole sequence of events. The Kay Object (KO) is more of an encapsulated microservice, like an Erlang process. How would mail (SMTP) look if it was implemented via RPC? [1] I specifically didn't use the word object because the Kay Object and the Java/C++ object are not comparable.
Pharoer_ 11y ago
Messages are inherently decoupled from the methods they invoke, unlike function calls or function pointers. For example, in Smalltalk you can rewrite this: dictionary at: aKey put: aValue to: dictionary perform: #at:put: with: aKey with: aValue where #at:put: is just a Lisp-style symbol object, an identifier, and perform:with:with: sends a message to the receiver with the first argument as the selector and second and third as its arguments. As one example, this allows you to have a button object that you configure to send some message selector to some object when clicked. Obviously, you can accomplish this equally well with anonymous functions, and since Smalltalk has probably the most concise syntax for anonymous functions (just pairs of "[" and "]"), they are often used instead. Speaking of anonymous functions and OO, it's bizarre to see FP zealots cite their gradual introduction into mainstream OO languages as proof of some move away from OOP and towards FP, when Smalltalk has had them since 1972 and uses them much more extensively than many "pure" functional languages do (though admittedly in part due to currying and partial application as in Haskell subsuming many of their use cases).
stretchwithme 11y ago
In case anyone is looking for the video of the keynote Kay gave before this post. There's a dead link to it at the bottom of the page. https://www.youtube.com/watch?v=oKg1hTOQXoY

136 points by stesch 11y ago

Just a little comment: Kay's mentioning various meta-things reminds me that I have The Art of the Metaobject Protocol (which Kay called "the best OOP book in ten years," and I should read it. And another little comment as regards Kay's "complaining" that Smalltalk had become "something to be learned": I very much failed to learn computer science from high school Java, where classes, methods, encapsulation etc were treated as things-to-be-learned. I didn't know that I /could/ care about how they were put in place or why. If I had been taught that everything in a meta-system can be changed when you structure your changes, I would have been a happier camper--motivated by autonomy and purpose.

agumonkey 11y ago
I felt the same. People differ in the way they interact with systems and logic. I certainly disliked being fed the Java way rigidly. I actually learned more about basic OOP by simulating it in ADA. Some people like to understand by building. But it's also valuable to understand an abstraction outside of any implementation. In the end it's better to have done both. And I feel strongly that to understand programming, one must write an interpreter and a compiler, so you can reason about the different abstraction levels clearly, without blind spots or dark magic.
parasubvert 11y ago
The art of the meta object protocol was good, it basically was a well-written code commentary for how to build an advanced OO meta system (CLOS) for LISP. CLOS was a bit of a dream language, I'd say Scala is perhaps the closest practical language in terms of ideas. Interestingly, this work led Gregor Kiczales & team to create Aspect Oriented Programming - a subset of his metasystem - which became somewhat popular with Java and the Spring framework's use of AspectJ. http://en.m.wikipedia.org/wiki/Aspect-oriented_programming http://en.m.wikipedia.org/wiki/Aspect-oriented_programming As an aside, I found in college (let along high school!) that students have almost anti-philosophical learning objectives. The SICP approach of teaching computer science from the metasystem up with Scheme (and then possibly moving on to CLOS/Lisp) was near-universally hated among my peers (1996-2002) - most wanted a practical language they could "get a job" with. I believe MIT first year CS switched to Python in part to deal with this resistance.
- mbrock 11y ago
  What makes Scala more "practical" than Common Lisp, other than incidental matters of library support on the JVM?
  - parasubvert 11y ago
    That, and the dearth of people that know CLOS, or are able and WANT to learn CLOS. "Design by resume" surrounds us.
- DalekBaldwin 11y ago
  AOP also encompasses techniques you can't find in CLOS/MOP. The analogues to before/after/around methods are the easiest concepts to implement and reason about, so those are what popular language extensions tend to emphasize. But if you look at the original AOP papers describing Reverse Graphics, you'll see an AOP system used to liberally restructure the control flow of the entire base program, not just augment its behavior. It was an early version of what you can see now in something like the Halide language. > I believe MIT first year CS switched to Python in part to deal with this resistance. In part. The full story is a bit more depressing: http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python http://www.wisdomandwonder.com/link/2110/why-mit-switched-fr... Most of the other top universities that had used SICP also switched shortly after MIT.
- xenophonf 11y ago
  > most wanted a practical language they could "get a job" with This was me in college. Especially early on, I kept hounding my professors why they weren't teaching a particular language (e.g., C++) or toolchain (Visual Studio). It wasn't until well after I graduated that I appreciated the distinction between using tools and making tools---and that my professors taught me the latter.
frik 11y ago
JavaScript in a browser + DevTools offer a similar environment to Smalltalk + Squeak. http://en.wikipedia.org/wiki/Squeak http://en.wikipedia.org/wiki/Squeak One can change everything, and manipulate even the UI. Even the DevTools in all browsers nowadays are HTML5 iframes. Manipulating the objects and meta/prototype objects are features that both languages allow. Though they are different, and afaik only JS is called a prototype based programming language: http://en.wikipedia.org/wiki/Prototype-based_programming http://en.wikipedia.org/wiki/Prototype-based_programming
- vezzy-fnord 11y ago
  JavaScript in a browser + DevTools offer a similar environment to Smalltalk + Squeak. Sure, they're "similar", but at a relatively low approximation. The capabilities of the Smalltalk environments are simply on a different plane. Manipulating the objects and meta/prototype objects are features that both languages allow. This is sort of a bare minimum for all OO languages. Even Java with its rigidity allows for complex tricks with reflection and method body replacements for hot code reloading.
  - mbrock 11y ago
    Can you formulate more precisely (or by example) what you mean by "simply on a different plane"?
    - vezzy-fnord 11y ago
      See the Design Principles Behind Smalltalk article: https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.... Some relevant excerpts: Here are some examples of conventional operating system components that have been naturally incorporated into the Smalltalk language: [...] Display handling -- The display is simply an instance of class Form, which is continually visible, and the graphical manipulation messages defined in that class are used to change the visible image. [...] Debugger -- The state of the Smalltalk processor is accessible as an instance of class Process that owns a chain of stack frames. The debugger is just a Smalltalk subsystem that has access to manipulate the state of a suspended process. It should be noted that nearly the only run-time error that can occur in Smalltalk is for a message not to be recognized by its receiver. Smalltalk has no "operation system" as such. The necessary primitive operations, such as reading a page from the disk, are incorporated as primitive methods in response to otherwise normal Smalltalk messages. This is from 1981, BTW.

parasubvert 11y ago

I remember this being posted in 1998, as people were debating the surge of Java relative to C++ or Smalltalk. These were the twilight days where C and assembly were the only language Real Programmers used, Perl and Tcl or any scripting/interpreted language were considered toys for sysops and never meant for production, OO was treated with deep suspicion, and functional languages were considered crazy talk. I remember people in my company saying a particular C++ replacement program my colleague wrote was "too OO" and would execute 10x slower than required (when it was 2x faster than the legacy). Point is, a lot of what Kay says is obvious now, but it wasn't in the 90s, and it REALLY wasn't in the 70s. One sees new things every time one reads this. For example, Kay comes out as a supporter (of sorts) to functional programming principles by calling assignments (mutable state) a metalevel change.

mikro2nd 11y ago
1998?... More like the twilight days when Cobol still ruled the land and we thought (feared) that it would never die. Fortunes were being made consulting on the Y2K bug and patching the dodgy Cobol systems responsible. I do agree, though that OO was treated with suspicion and hostility. Only a tiny number of (us) mavericks were brave enough (or foolish enough) to propose using what our management saw as a "newfangled and risky" proposition. Let's not even mention mucking about with Extreme Programming. ;)
- parasubvert 11y ago
  Oh yes, COBOL was C's evil twin in that regard. It depended what circles you travelled in - engineering depts or IT depts. I remember posting the c2 wiki pages for XP on my cube wall when XP first came out, and had a Gantt-chart oriented systems engineer tear them down as dangerous nonsense.
zak_mc_kracken 11y ago
> Point is, a lot of what Kay says is obvious now It's obvious because he's not saying much, besides trying to redefine "function call" with "message passing" so that it makes Smalltalk look better.

lazydon 11y ago

If the big idea was messaging and not objects, I'm curious to know how did we end up in this primarily object oriented world. Especially, when its founding father didn't had that intention as he says: ""I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind". I have a guess from following quote: "This was why I complained at the last OOPSLA that - whereas at PARC we changed Smalltalk constantly, treating it always as a work in progress - when ST hit the larger world, it was pretty much taken as "something just to be learned", as though it were Pascal or Algol." - There were people in hurry to make something with whatever theoretical basis there was instead of further refining the original concept. Probably, that's where it took the wrong turn.

parasubvert 11y ago
Refining a language or programming paradigm requires a philosophical or scientific bent. Not much money in that. Most people just want to get a job done and go home at 5pm. Edit: Bright side, I think polyglot programming is more popular now than ever in history. In the past you learned one language and that was 20 years of your career before you went into management. Your identity was wrapped up in being a "VB person", "C", "COBOL", or "Java/C# person" or "Rubyist" . There still is language identity politics but I think Ruby might have been the last of the One True Religions, now the frontier is all over the place between Python, Ruby, Node, Java, Golang, c#, etc.
- coliveira 11y ago
  I think it is a perversion of computer science that we think ourselves as users of languages, instead of creators of languages. Especially because it is not hard to create a language these days -- we know much more and have better tools than people 30 years ago. Many of the problems that we consider uber-complicated could be relatively easily solved by creating appropriate problem-specific languages: consider web programming, data mining, etc.
  - parasubvert 11y ago
    I'm with you. But it becomes a skills and NIH-attitude issue at scale, where the evolution of science is less of a concern than treating the science as constant for an engineering project. I've seen lovely crafted DSLs that were deemed unmaintainable when the creator moved on, and management cursed the use of them if they weren't already a popular OSS project.

pacala 11y ago

> The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word - ma - for "that which is in between" - perhaps the nearest English equivalent is "interstitial". 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. Think of the internet - to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. What is the difference between "messaging" and "function call"? "messaging" data into a module = call a function with the data as arguments. "messaging" data out of a module = package the data as the return of the function.

contingencies 11y ago
Think of the internet... Great quote along these lines is: Upgrade cost of network complexity: The Internet has smart edges ... and a simple core. Adding an new Internet service is just a matter of distributing an application ... Compare this to voice, where one has to upgrade the entire core. - RFC3439 (2002) ... from my fortune clone @ https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
frik 11y ago
> What is the difference between "messaging" and "function call"? If the object supports the message, then it will execute some code. Otherwise it will just ignore it. This is a more dynamic approach than an explicit function/method call where the object must support that function. You can think of e.g. Javascript events plus function calls (callbacks) that pass an object ("message") and a typeof/switch check as an equivalent.
sitkack 11y ago
Messaging is a protocol level abstraction, communication between entities [1]. A function call is a much lower level abstraction that does a <verb> to/with the data. One could have an entity that executes one function or many, or it could manage a whole sequence of events. The Kay Object (KO) is more of an encapsulated microservice, like an Erlang process. How would mail (SMTP) look if it was implemented via RPC? [1] I specifically didn't use the word object because the Kay Object and the Java/C++ object are not comparable.

Pharoer_ 11y ago

Messages are inherently decoupled from the methods they invoke, unlike function calls or function pointers. For example, in Smalltalk you can rewrite this: dictionary at: aKey put: aValue to: dictionary perform: #at:put: with: aKey with: aValue where #at:put: is just a Lisp-style symbol object, an identifier, and perform:with:with: sends a message to the receiver with the first argument as the selector and second and third as its arguments. As one example, this allows you to have a button object that you configure to send some message selector to some object when clicked. Obviously, you can accomplish this equally well with anonymous functions, and since Smalltalk has probably the most concise syntax for anonymous functions (just pairs of "[" and "]"), they are often used instead. Speaking of anonymous functions and OO, it's bizarre to see FP zealots cite their gradual introduction into mainstream OO languages as proof of some move away from OOP and towards FP, when Smalltalk has had them since 1972 and uses them much more extensively than many "pure" functional languages do (though admittedly in part due to currying and partial application as in Haskell subsuming many of their use cases).

stretchwithme 11y ago

In case anyone is looking for the video of the keynote Kay gave before this post. There's a dead link to it at the bottom of the page. https://www.youtube.com/watch?v=oKg1hTOQXoY