He always criticizes how everyone got computing wrong (fair enough), but never offers anything but the most vague suggestions of how to do things differently.
Eventually, after distancing themselves from their curmudgeonly creator, his ideas land in the mainstream. I'm convinced, eg, that what's loved about python has been elucidated by AK at some point, but maybe it's even good marketing not to attribute anything to him ;)
He has generally great insights about principles to aim for, which is part of the answer, but no, he does not have the entire answer. His insights are inspiration for others who contribute their own parts to potential answers—that's how open collaboration works.
Others have already mentioned this, but Alan Kay spent his entire career experimenting with approaches to radically simplify computing. The progress reports from vpri give a good overview of a recent project that has since wrapped up, e.g.: https://tinlizzie.org/VPRIPapers/tr2012001_steps.pdf
I'm not confusing anything. OOP is a horribly OOT over-engineering of a problem looking for a solution, from the get go. That it morphed and twisted into a bloated mess when it was taken up by people who didn't get it to begin with is just the inevitable result of starting with a big pile of no need to do all that in the first place.
Yes, that’s what I mean by vague suggestions. How do you actually build and maintain a system of any complexity with that? How do you ensure it will do what it is supposed to do? And Smalltalk wasn’t that, it is mostly just regular method calls and not “message passing”.
He’s not just a proponent of message passing, he’s a proponent of late binding [1]. The idea there is to have a running image of the environment and interact with it in real time, updating code while it’s running (no recompiling or anything like that). The idea is a high level of interactivity with very tight feedback loops.
A whole operating system like this would allow you to hack on the user interface and change things on the fly. All of your software would also work like this, promoting open extensibility by the user. You ought to be able to click on any window or other user interface element and be able to view and modify the running code live, without even restarting the computation it’s running (never mind the whole program or even rebooting the computer).
This sort of ability to do live hacking on the internals of what you’re working with is how computers used to work in those early days. It’s also how machinery has always worked in the past. A mechanic could lock in the timing of an engine by rotating the distributor cap and listening to how smoothly it fires.
I wonder if all of that was in an operating system as described but backed by Nix so we accomplish the NixOS-style reproducibility and configuration time travel, what the developer experience and user experience would be like. Instead of binary blob images, we'd have Nix declaratives and flakes we dissect at will, without fear of wedging the system with the live modifications we make.
Our hardware is sufficiently capable enough these days that I'm curious if we can do this to conventional Smalltalk and Common Lisp system/machine designs to re-imagine them, and bring back a level of tight feedback looped developer experience that has gone underground in the mainstream.
I wonder if all of that was in an operating system as described but backed by Nix so we accomplish the NixOS-style reproducibility and configuration time travel, what the developer experience and user experience would be like. Instead of binary blob images, we'd have Nix declaratives and flakes we dissect at will, without fear of wedging the system with the live modifications we make.
Kay himself does regularly describe the Arpanet as one of the inspurations for OO, and the modern interbet browser as an incomplete implementation of the same ideas: https://youtu.be/1e8VZlPBx_0
Holy crap that'd be amazing for accessibility! Open a menu and look at what the button does, label that button with the screen reader, pass around that label to others, and boom, labeled button.
I disagree, not because methods do not get called, but because the Smalltalk sender is not calling a method, it is sending a message. It says to the runtime, here is an object and I want to send "#collect:" to it using this other object obj as a parameter. The runtime looks in the object's class for a method called "collect:" and, if found, calls the method with the receiver and obj. If not found, it will look in the superclasses until it cannot find it, then it will send "#doesNotUnderstand:" with the context, and go up the class hierarchy again. Because of the message-passing paradigm, the receiver can make behaviors that are unusual, such as proxying and delegation, in a more or less transparent fashion.
If the sender is calling a method, then that is a static arrangement and the result is not different from a function call.
Every single object in smalltalk is free to have its own implementation of handling a message. In javascript, the runtime decides for the object how to locate the code and how to call it.
Does a full free operating system, all the way down to the metal, and hypermedia publishing suite in 936kB count as "a system of any complexity" that "will do what it is supposed to do" to you? If not, what specifically is your standard? https://youtu.be/BUud1gcbS9k
Erlang(and more modernly elixir/Gleam) are an example of this in practice, and were created to make it easier to ensure the working and manage the complexity of large systems.
Fair enough. But Alan Kay doesn’t say “use Erlang”, nor does he go into any depths about what the desirable feature set is and what would make it work or would fail to make it work. He’s always just waxing around nebulous desiderata and complaining about the status quo.
>But Alan Kay doesn’t say “use Erlang”, nor does he go into any depths about what the desirable feature set is and what would make it work or would fail to make it work.
Oh yeah? Then how do you explain this lecture where he says explicitly that Erlang should be the modern programmer's assembly?
In my experience, people who criticize Kay for being too vague or kvetching too pointlessly or lacking practical experience in computer science today almost always have not bothered to familiarize themselves with the vast majority of his work before deciding their opinion on it. It's hard to disagree with him that this makes us more like a pop culture than a profession after seeing it.
If only. Unix would be dead and buried many years ago if it was just a fad. It's far more like the old repeating fertility rituals of many paganistic societies, where your neighbors burn your pagus down to cleanse the village of the spite of the undead grain god if you plowed your heath in a different direction from everyone else.
Just adding here that the understanding of the forces at play in a cultural war makes what you just said even more clear and for a vast spectrum of fields way beyond IT.
It's somewhat of a backhanded compliment though -- calling Erlang a "modern assembly" is like the quip that C is a "portable assembler" -- that is, a tool useful for low-level stuff but which you should mostly use to implement higher level languages on top of.
I don't agree with this in the context of the full video. I'd encourage you to watch it; it's quite good. It's clear Armstrong and Kay have a great deal of respect for each other.
Maybe because there is no one/right/simple answer. You really have to think for yourself and seek out answers instead of expecting them. You're doing that now but with the mistaken impression you were to be handed them.
If he said "use Erlang" then that eliminates the actual message he's trying to convey, which is message passing is good.
I bet if he simply said "use Erlang", 99% of headlines and discussion would be "Alan Kay said Erlang is the greatest language evah!"
I do appreciate that he respects his audience, ie me, enough that he thinks we can read "message passing is good" and go from there to choosing a message passing language that is suitable for our needs, or even using a non message passing language due to other factors, but recognizing that OOP is about message passing and not state encapsulation, which would impact how I code even in Java.
Smalltalk is definitely message passing. There are many ways to intercept the messages and implement different responses. This one mechanism enables: network aware code, object proxies, sub-classing, on-the-fly code generation, and lots of other behavior. Traditional methods were invented later as less robust version of Smalltalk's message passing.
SmallTalk? Even though the language is mainstream, its many ideas, including implementation and design style using message passing, are embedded in many languages and software packages.
> Yes, that’s what I mean by vague suggestions. How do you actually build and maintain a system of any complexity with that?
Reminds me of the RESTful guy, Roy Fielding (though I respect and like Alan Kay way more). If you've read any of his online interactions, apparently nobody does REST like he envisioned. It simply doesn't exist in the wild. When asked about some REST API, he'll claim it's not RESTful, it's wrong, that's not what he meant, etc. "But what would be right?", you ask, and he'll reply "Read my paper! HATEOAS! (Hypermedia as the engine of application state)". "Ok, but what does it mean in practice, how do I go about building an API with HATEOAS?"...
...and there's no answer for that besides "read my dissertation". He can only tell you what you're doing wrong, but nobody has been able to build a "true" RESTful API to Roy Fielding's satisfaction.
I think you're confused about who Fielding is and what REST is about. His writing isn't about building "true" RESTful APIs. It isn't really about APIs per se at all, RESTful or not. (Further, Fielding to my knowledge isn't even known for his use of the word "RESTful".) It sounds like you've probably been misled by a bunch of people who aren't Fielding about what's in his dissertation. Not unreasonable in those circumstances that one be told to actually read the thing instead of guessing at the gestalt of it based on ambient chatter which is by and large very misinformed.
Having said that, Fielding's writing is not something I would exalt for its clarity. I'm partial to jcrites's explanatory powers: "REST describes how the Web works" <https://news.ycombinator.com/item?id=23672561>
It's incredibly easy to build hypermedia as the engine of application state sites. You generate html pages with state in them, and hyperlinks and forms that filter and change the state.
Hateoas didn't invent anything. He literally just described how web 1.0 worked.
You are impressively wrong. He just wrapped up an incredible research program that demonstrated many concrete implementations of great computing ideas.
> After 16 years of continuous research and important contributions toward its mission - "Improve 'powerful ideas education' for the world's children and to advance the state of systems research and personal computing" - Viewpoints Research Institute concluded its operations at the beginning of 2018.
And what exactly is the output, other than talks and some programming learning tools for children? I haven't seen any significant new insights or advances.
> And what exactly is the output, other than talks and some programming learning tools for children?
The papers and demos are the output. They were a research outfit, not a startup. OP claimed that Kay "never offers anything but the most vague suggestions" when he (et. al.) provided several very concrete working demos. It's hardly his fault if no one took him up on them, is it? (FWIW I suspect some of their work had an effect on MS Word & Excel UI but I don't know for sure.)
> I haven't seen any significant new insights or advances.
Where have you looked? Did you read the papers that VPRI published? OMeta has been mentioned else-thread, I like that Nile programming language, the COLA system seems neat.
True message passing is one of the key ideas behind smalltalk which would improve computer security considerably. This is analogous to the design of the internet that he references. The internet scales well. So imagine building entire computing systems this way.
If smalltalk is late binding and message passing, I think it's interesting that modern large scale webapps (say Netflix or Google) do just that just not inside process and server boundaries. I'd guess that Alan Kay would think that's a bastardization, and there are loads of complications but it's a definite improvement over the large php ball of mud monolith you might have seen at say Box or Facebook 10-15 years ago. Because the 'object' boundaries are so coarse you can also better leverage the few people inside an org who know how to design, scale, improve robustness and secure systems. If architecture is the metaphor, it's still pretty much piling mud bricks but at least there are corbeled arches, streets, city walls, public buildings and a rudimentary notion of style.
As for LLMs I think that long form typeahead is the right way to think about it.
I don't think he would think it is a bastardization. HTTP is 100% message passing. You have an object reference (url) and you pass a message to it with POST. State and behavior is encapsulated. In fact, one of the desireable properties of message passing is that it is easy to distribute across process and machine boundaries.
How would it improve it, though? Dynamically-typed languages tend to introduce gradual typing after a while to increase reliability and predictability, and the end game of that (static typing) is the antithesis of late binding. Message passing only improves security by adding a validation layer, but managed languages (JVM, CLR, etc.) effectively do the same.
> The internet scales well. So imagine building entire computing systems this way.
That’s very similar to microservices, and look how messy these tend to get. The internet scales well because it’s a network with flexible capacity and attached processing power, and because its clients are either human users who can deal with failure modes, or software with stable and well-specified point-to-point protocols.
It’d be a big improvement. Rather than call a linked library function you’d send a message to whatever it was you needed the library function for.. this reduces the buffer overflow exploit potential and what not. That alone is a huge win.
That’s “what we would like to have” (so mostly just a criticism that we don’t have it), but without much of a suggestion of how to actually achieve it in practice.
The current industry leaders of the effort want to proclaim that it is impossible to know where the answers come from. If that is the industry norm then I understand how achieving trustability could be mysterious.
My line of thinking is that without an audit trail of thoughts there won't be any trustability. I'm unable to describe in detail what any one specific thing leads to trustability. I can say that being able to demonstrate where answers come from would work for me.
I think I get what parent means, Kay is mostly seen in conference mode, with simplified slides and big ideas, it's frustrating if you never saw who he got taught or worked with.
