[HN Gopher] Alan Kay on Messaging (1998)
___________________________________________________________________
Alan Kay on Messaging (1998)
Author : mpweiher
Score : 109 points
Date : 2024-09-29 08:35 UTC (14 hours ago)
(HTM) web link (wiki.c2.com)
(TXT) w3m dump (wiki.c2.com)
| bazoom42 wrote:
| He should just have called it microservices instead of objects.
| mpweiher wrote:
| Well...his original vision _was_ communicating computers, and
| then scaling that down.
|
| Except that Microservices _tend_ to use REST (or something
| roughly like it) and not CORBA.
|
| https://blog.metaobject.com/2019/11/what-alan-kay-got-wrong-...
| ape4 wrote:
| Or signal, receptor, effector
|
| https://en.wikipedia.org/wiki/Cell_signaling
| agumonkey wrote:
| The more I see how microservices evolve the more I think about
| J2EE remote objects / ejb. A little personal facepalm moment.
| thom wrote:
| Microservices today have all the same problems as OOP, but
| vastly amplified. My kingdom for some more functional approach
| to architecture, with services as more or less pure functional
| transforms, and some sort of extremely well-typed data mesh
| underneath.
| smallstepforman wrote:
| Clear as mud. No matter how good Alan Kay is, he failed to
| properly describe messaging, as used in an Actor environment. He
| missed the Actor Programming model. Also the late Carl Hewitt
| failed to properly explain and implement a working Actor model. A
| shame, since there are many working Actor implementations in many
| languages.
| mpweiher wrote:
| It thought the final paragraph was very clear:
|
| _I would suggest that more progress could be made if the smart
| and talented Squeak list would think more about what the next
| step in metaprogramming should be - how can we get great power,
| parsimony, AND security of meaning?_
|
| Did you mean that he _should_ have described actors, but did
| not?
|
| To me at least, "ma" goes beyond just the actor model.
| nabla9 wrote:
| He is not describing Actor Programming model. He describe his
| own model.
|
| Message passing in Smalltalk predates Hewitts Actor Model and
| was used as inspiration. The messaging in Smalltalk is little
| different and IMHO better in many cases.
| mpweiher wrote:
| But he's not describing Smalltalk. He is describing what he
| wanted Smalltalk to evolve into. Which he didn't know how to
| do, because otherwise we would have it by now.
|
| This quip by him from OOPSLA '97 is well-known:
|
| _I made up the term object oriented. And I can tell you I
| did not have C++ in mind._.
|
| A little less well-known are the words that immediately
| follow:
|
| _So, the important thing here is: I have many of the same
| feelings about Smalltalk_
|
| https://youtu.be/oKg1hTOQXoY?t=634
| Phiwise_ wrote:
| Why would you a hypothetical quote of Kay for cutting off
| the full context that he also has criticisms of Smalltalk,
| and then cut yourself before he specifies that what he's
| not committed to is the syntax and library system, while
| the message-passing execution model is the important thing
| he's trying to promote? That just muddies the waters more.
| This email was sent a year after OOPSLA 97, so clearly he
| can't have been talking about messaging as Smalltalk's
| problem.
|
| As for where he wants Smalltalk to go, that's what Squeak
| was for. He talked about it on plenty of occasions, at
| least one of which was also before OOPSLA, and actually did
| get a research team together to develop it out in the late
| 2000s: https://tinlizzie.org/IA/index.php/Papers_from_Viewp
| oints_Re...
| layer8 wrote:
| Most of Alan Kay's writings on that topic can be reduced to
| something along the lines of "I want things to be nice and
| problem-free. I have a vague feeling that there is a
| methodology called 'OOP' and 'messaging' that would achieve
| that. All systems that claim to be OOP that are not nice and
| problem-free are obviously missing the point."
| fidotron wrote:
| The problem with this is he led teams that built systems that
| proved his point.
| layer8 wrote:
| They built systems, but I disagree that those proved his
| point. It's not even clear what precisely his point is and
| how you would evaluate success or failure for it.
|
| Regarding Smalltalk, there are conceptual reasons why it
| failed, some of which are mentioned in this thread:
| https://news.ycombinator.com/item?id=10071681
| kragen wrote:
| it failed? today's most popular programming languages are
| about half smalltalk derivatives (python, js, java, c#,
| and vb.net, but not c++, c, golang, sql, and fortran),
| apple is the world's most important computer
| manufacturer, wimp guis still dominate on computers that
| have keyboards, every web browser includes an ide with an
| object inspector, and virtually all programming is done
| in ides
|
| that doesn't sound like failure to me
| bitwize wrote:
| The royalties on the laser printer alone earned Xerox
| back PARC's entire expenses 200 times over but PaRc
| FaIlEd BeCaUsE xErOx DiDn'T kNoW hOw To mOnEtIzE tHeIr
| InVeNtIoNs.
| igouy wrote:
| > some of which are mentioned in this thread
|
| Tell us which three you regard as most important; and
| which of the 61 comments in that thread demonstrate most
| clearly that they are important failings.
| igouy wrote:
| For example ?
|
| (And which point was proved.)
| emmanueloga_ wrote:
| Kay's ideas are definitely interesting, but they can feel
| pretty vague. For example, what are these "fences" or
| "metaboundaries" he keeps mentioning? They probably aren't
| anything like type checking since he seems to love dynamic
| typing and late binding. Did either Smalltalk or Squeak
| implement any of these "metaboundaries" at any point after this
| 1998 message?
|
| When it comes to "messaging," it usually just boils down to
| method dispatch or large switch statements. It doesn't seem
| like some magical concept we haven't figured out yet; it's more
| like something we already know. When I see Kay's complaining
| about messaging, I imagine he also complaining about other
| things: "WE NEED BETTER WHEELS", or "WE NEED BETTER
| ELECTRICITY" (?). What do you actually want, Alan? :-p
|
| From my experience with large Ruby codebases and
| publish/subscribe systems, debugging can become quite messy
| when there's too much flexibility. I think this is what Kay is
| getting at, even if he maintains the idea that a dynamic system
| like Smalltalk will somehow evolve to fix these issues.
| mpweiher wrote:
| > Kay's ideas are definitely interesting, but they can feel
| pretty vague
|
| They seem vague because they are research questions. _Tough_
| research questions.
|
| > [messaging] usually just boils down to method dispatch or
| large switch statements.
|
| And that's the problem.
|
| > [not something] we haven't figured out yet;
|
| Well, we obviously haven't figured it out yet, because it
| ain't large switch statements or (just) method dispatch.
|
| > debugging can become quite messy when there's too much
| flexibility.
|
| Exactly what he's talking about! Languages like Ruby have the
| metaprogramming flexibility, but they are lacking in the
| security of meaning department.
|
| Languages like Go are pretty good in the security of meaning
| department, but lacking in the flexibility/expressiveness
| department.
|
| So far, we have achieved either/or. He is saying what we need
| is _both_.
|
| It's a tough problem.
| cxr wrote:
| > Kay's ideas are definitely interesting, but they can feel
| pretty vague.
|
| I agree on the whole, but I think he followed through this
| time. He gave pretty a set of cogent examples that doesn't
| leave the whole thing coming across as incoherent (like a
| mystic we're supposed to revere and take their words as some
| form of high wisdom that would make sense if only we could
| attain the requisite form of enlightenment). Viz:
|
| > _I would say that a system that allowed other metathings to
| be done in the ordinary course of programming (like changing
| what inheritance means, or what is an instance) is a bad
| design._
|
| (There are two things being communicated here--what sorts of
| things he means when talking about transgressing the
| metaboundaries, and a position about whether it's a good idea
| to do it willy nilly--with his position on the latter being:
| No. The former seems clear enough and his take on the latter
| is definitely reasonable and might even qualify as "wise".)
| fidotron wrote:
| If you want his view on Actors then the conversation with Joe
| Armstrong is enlightening.
|
| The main common ground they share is that CSP becomes too
| synchronized and particular, making it too difficult to use for
| systems in the large.
| pakl wrote:
| Actors solves a very different problem. Alan Kay was talking
| about enabling computing across heterogeneous systems.
| raintrees wrote:
| "The messaging IS the program"
|
| (Apologies to Marshall McLuhan)
| bitwize wrote:
| Kay cites McLuhan A LOT in his talks.
| abdellah123 wrote:
| Oop is about modeling... Messaging is optional. See yhe beta
| programmimg language
| recursivecaveat wrote:
| I always thought that the Alan Kay model is fundamentally
| misguided, in that it is explicitly inspired by cell biology and
| distributed computer systems, ie extremely hard problems.
| Basically all the hardest things to model, predict design, and
| debug are these kind of bottom up systems where all interesting
| behavior comes from the emergent runtime interaction of tons of
| tiny components. This works okay for cells because there is no
| programmer floating above the system trying to understand it and
| make specific changes, but until we start programming by natural
| selection I wouldn't describe it as a good paradigm for
| organizing behavior.
|
| I much prefer my programs to have a sort of top down structure,
| more like a military instead of an economy. Obviously late-
| binding and dynamic behavior is many times necessary, but I would
| not lean in to it, in the same way I would not say, make all my
| variables global just because sometimes you need it.
| bmitc wrote:
| But many times, such top-down structure cannot work, especially
| if your program interacts with external systems, such as
| hardware. In such systems, you need a model in your program
| that is very similar to biological systems. For example, a
| module that interacts with hardware needs to be self-sufficient
| and asynchronous, interacting with the rest of the system
| through messaging. Even if there is a top-down structure at the
| higher-level, such structure cannot fully dictate how the
| hardware behaves or performs. For example, someone outside of
| your program could go off and change settings on the front
| panel.
| pakl wrote:
| IMHO (from the viewpoint of a neuroscientist) the biological
| inspiration is quite measured and restrained in his work...
|
| The problem he was proposing we solve is computing with
| heterogenous "machines". This doesn't preclude the regimented
| organization you are favoring, above.
|
| Please see my other comment on call-by-meaning.
| cxr wrote:
| This is also why the "computer science" label (until now) never
| really made sense for traditional programming; you start from
| an intention to reach a goal, and contrive a system that can
| achieve it, generally understanding the means by which it is
| accomplished from end to end--or at least you have the option
| of zooming in from a given level of abstraction to a lower one
| to work out how the pieces fit together there and play their
| part in getting us where we're aiming at the highest level.
| Science isn't that. Science is what humanity has to resort to
| when a thing is not knowable by other means--the preferred from
| for modification is not at hand. Generally, when someone is
| doing something akin to _science_ where traditional software
| development is concerned, it 's regarded as sloppy--that you
| need to stop goofing around and actually do the work of
| understanding and reasoning about what you're dealing with
| instead of poking at it and making observations and inferences.
|
| This is different now with black box systems like LLMs and
| other neural networks (transformer-based or not) that we don't
| understand because they were never actually designed from a
| blueprint that lends itself to an understanding by others that
| approaches the understanding of the originator(s).
|
| There's an argument to be made that our avoidance of systems
| that call for actual science and our attraction to focusing on
| the smaller subset consisting of grokkable systems, out of a
| larger set of possible ones, is an indication of immaturity.
| It's parochial and blinkered. We are big fish in a small pond.
| threatofrain wrote:
| > Science isn't that. Science is what humanity has to resort
| to when a thing is not knowable by other means--the preferred
| from for modification is not at hand.
|
| Science is description and explanation on top of empiricism.
| It is the first means by which people understand things, not
| the last, as formal methods came way late.
|
| This drive to properly name things also gets into the
| somewhat similar debate of whether math is discovered or
| invented. And somewhere someone is trying to determine
| whether it's appropriate to call math as science, art, or
| engineering.
| panarchy wrote:
| "until we start programming by natural selection"
|
| We already have reinforcement and other types of machine
| learning?
| armitron wrote:
| Top down architecture doesn't scale and puts a hard limit on
| the problems one can tackle before complexity explodes. The
| Internet, the largest distributed system we have, is based on
| bottom-up cell-like biologically inspired models. Kay was
| prescient and decades ahead of his time.
| alexashka wrote:
| What is your argument, besides personal taste?
|
| Something being hard is not an argument for or against
| anything.
|
| Alan Kay is misguided because he prefers a hard thing and you
| prefer a simpler thing?
| why-el wrote:
| To be inspired by something really has no bearing on how the
| _inspired_ thing is built. I think you place much emphasis on
| that but really it does not bring much to the argument. One can
| say that a plane was inspired by a bird (and it is, since we
| wouldn't to build one if we didn't see birds flying), but a
| plane is not designed like a bird.
|
| I also somewhat contest that "interesting behavior comes from
| the emergent runtime interaction of tons of tiny components".
| There can be very tight, hierarchical structures to programs
| designed in the way Alan Kay talks about. He is promoting
| clear, manageable interactions, not emergent unpredictability,
| which is something I am sure you came across (we all did), but
| I would not go so far as describe the whole model of Kay as
| "fundamentally misguided". He talks of "clear fences", which
| can be understood to refer to things like "actor-based" models,
| with controlled, clear messages, as done in languages such as
| Erlang.
| atomicnature wrote:
| What do you think of the Internet? Has it worked? Has it
| scaled? Is it reliable?
|
| Remember that Alan Kay, his team and his colleagues had a lot
| to do with this thing you are using to rant here :)
| lcuff wrote:
| Does anybody have a pointer to a good description of what Alan
| Kay means by messaging?
| hgs3 wrote:
| In practice it means late binding [1].
|
| [1] https://en.wikipedia.org/wiki/Late_binding
| pakl wrote:
| See "call-by-meaning":
| http://www.vpri.org/pdf/tr2014003_callbymeaning.pdf
| pakl wrote:
| At Alan Kay's Viewpoints Research Institute, the problem was
| phrased in a more concrete form and a solution was provided --
| "Call by Meaning"[0].
|
| The most succinct way I have found to state the problem is: "For
| example, getting the length of a string object varies
| significantly from one language to another... size(), count,
| strlen(), len(), .length, .length(), etc. How can one communicate
| with a computer -- or how can two computers communicate with each
| other -- at scale, without a common language?" [1]
|
| The call-by-meaning solution is to refer to functions (processes,
| etc) not by their name, but by what they do. VPRI provided an
| example implementation in JavaScript[0]. I re-implemented this --
| a bit more cleanly, IMHO -- in Objective C[1].
|
| [0] http://www.vpri.org/pdf/tr2014003_callbymeaning.pdf
|
| [1] https://github.com/plaurent/call-by-meaning-
| objc?tab=readme-...
| toast0 wrote:
| > The call-by-meaning solution is to refer to functions
| (processes, etc) not by their name, but by what they do.
|
| This seems like call by an even longer, more difficult to use
| name.
|
| And it would seem to rely on a common language to describe
| functions/methods, which clearly we don't have or everyone
| would use the same names for things that do the same thing
| already.
| pakl wrote:
| Think about it. A "meaning" in this usage is _definitely_ not
| a longer name.
| toast0 wrote:
| From the doc you linked we have var clock
| = K . find ( "(and (variableRepresents that
| thing) (typeBehaviorCapable-DeviceUsed thing
| (MeasuringFn Time-Quantity)))")
|
| So if I want a clock instead of using the name
| system.timer, now I need to know the much longer name.
| Maaaybe you think I can reason about the parts of this
| name, but it's just a longer string with funny syntax. And
| it's only really useful if we all agree on the language of
| description, which if we had a common language of
| description, we wouldn't have the problem this is trying to
| address.
|
| If you've got an example of a real system using this where
| it's actually better than searching docs, or learning what
| the language of today uses to measure the size in bytes and
| the size in codepoints and the size in glyphs, please link
| to that. But this feels like yet another thing where if
| everyone agrees about the ontology, everything would be
| easier, but there's no way everyone would agree, and
| there's not even an example ontology.
| pilgrim0 wrote:
| I find this super interesting! The first thing that comes to
| mind reading the demo code is, perhaps against the purpose, to
| canonicalize the lookup examples, which in turns evokes that
| the examples could be expressed by type expressions alone.
| Which makes me think of a type system that embeds a generalized
| set of algebraic operations, so that the adder function is one
| that simply returns the type Number + Number. Those could be
| semantic operations, beyond the basic mathematical ones, of
| course. Anyways, just thinking out loud.
| gandalfgeek wrote:
| Thanks for the pointer!
|
| "Call by meaning" sounds exactly like LLMs with tool-calling.
| The LLM is the component that has "common-sense understanding"
| of which tool to invoke when, based purely on natural language
| understanding of each tool's description and signature.
| Animats wrote:
| Kay's ideas about "messaging" were never communicated well.
|
| He seemed to be arguing for a pure imperative style. You send a
| message to make something happen. This is the opposite extreme
| from pure functional programming. A style of programming where
| everything is an imperative statement with no return value might
| be possible.
|
| GPU programming is kind of like that. Neural nets are like that.
| There's an analogy to biology, which doesn't seem to do function
| calls but does push information around. That apparently appealed
| to Kay.
|
| Functional programming makes things local. Pure imperative
| programming makes things global. This is hard on human
| programmers. It takes more short-term memory than most humans
| have to work in pure imperative mode.
|
| Kay was heavily into discrete-event simulation. That's what
| Simula had objects for, and that's where Smalltalk got objects.
| All those objects are sending messages to each other, driving the
| simulation forward. The original Smalltalk paper has discrete-
| event simulation examples. It's possible to build a GUI as a
| discrete-event simulator, with all the widgets sending one-way
| messages to each other, but that's seldom done. Discrete-event
| simulation became a tiny niche in computing. Kay thought of it as
| a central organizing concept for computing. That's not where the
| field went.
| ninetyninenine wrote:
| > Neural nets are like that.
|
| No neural nets are functional in nature. Each neuron is a
| combinator which is the fundamental and most modular unit of
| abstract computation. The net is simply a composition of these
| combinators.
|
| Training the neuron though is imperative because data is
| discrete. You have to train one piece of data after another.
|
| >GPU programming is kind of like that.
|
| Not true. See futhark. What's going on here is that the high
| level language is imperative. Why is the high level language
| usually imperative? Because the implementation of computing is
| usually imperative. Assembly whether it's for the CPU or GPU is
| imperative by implementation.
|
| But the high level abstraction on top of these things don't
| necessarily need to be imperative.
|
| >Functional programming makes things local. Pure imperative
| programming makes things global.
|
| What do you mean by this?
| dang wrote:
| Related. Others?
|
| _Alan Kay on Messaging (1998)_ -
| https://news.ycombinator.com/item?id=9481074 - May 2015 (61
| comments)
___________________________________________________________________
(page generated 2024-09-29 23:00 UTC)