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.
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.
> 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.
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.
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.
"until we start programming by natural selection"
We already have reinforcement and other types of machine learning?
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.
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?
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.
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.
> 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.
> 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".)
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.
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.
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
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_Viewpoints_Re...
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.
Actors solves a very different problem. Alan Kay was talking about enabling computing across heterogeneous systems.
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.”
The problem with this is he led teams that built systems that proved his point.
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
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
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.
> 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.
For example ?
(And which point was proved.)
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-...
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.
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.
> 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.
Think about it. A “meaning” in this usage is definitely not a longer name.
"The messaging IS the program"
(Apologies to Marshall McLuhan)
Kay cites McLuhan A LOT in his talks.
He should just have called it microservices instead of objects.
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.
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-...
Or signal, receptor, effector
The more I see how microservices evolve the more I think about J2EE remote objects / ejb. A little personal facepalm moment.
Does anybody have a pointer to a good description of what Alan Kay means by messaging?
See “call-by-meaning”: http://www.vpri.org/pdf/tr2014003_callbymeaning.pdf
In practice it means late binding [1].
Oop is about modeling... Messaging is optional. See yhe beta programmimg language