Taking Alan Kay's vision to the extreme

I’d like to explore here a rebuttal of @natecull’s incredible post about systems thinking, a defense of Alan Kay’s ideas and what computing would look like if those ideas were taken to the extreme.

I have been thinking about the same problem on introspectable, malleable computing and I feel I landed on the same place Alan had been exploring; the object model is starting to make more and more sense, while going the other way, reducing everything into dumb data-streams, is a dead end, and one we’ve been at for 30 years.

Here is my problem: I am writing this to you from a machine which has 20 independent CPUs, and the problem of multicore programming is still very much unsolved unsatisfactorily today. Additionally, my machine like most others is permanently connected to billions of worldwide others and they are only able to communicate at the very low level of dumb bitstream of numbers, so every program reimplements their own communication code.

The thing is, we have cracked computing, but we still reimplement communication, by hand, badly, in every program, and still forget the fact that even computation is useless without a way to communicate its result. A high-performance crunching tool written in C++ (because computation is king, I hear them cry!) has a buggy, incomplete, painfully hand-written communication layer to publish its result on a screen, on a Slack message board, on a web page. Why isn’t communication first class, in the age of the Internet?

Below are some ideas:

Actors

Actors are great at managing the complexity of concurrent/parallel/multicore programming. What are actors though? They are an opaque thing one can send messages to and receive responses from. That’s the exact definition of an object. There is a 1:1 relationship between Hewitt’s actors and Kay’s objects.

Networked objects

Next: why am I interacting with Google through a bag of bytes encoded in HTML? It would be more amenable to explorative programming if I could converse with it. I don’t want to reimplement Chrome from scratch and to talk with Google through bytes of data, I want to be able to do:

> google = new WebObject("https://www.google.com")
> google listMethods
query/1 signIn/2
> google query: "foo"
[
  { position: 1, url: "https://foo.com", title: "Visit foo.com" },
  { position: 2, url: "https://en.wikipedia.org/wiki/Foo", title: "Foo - Wikipedia" },
 ...
]

We shouldn’t have to reinvent communication in every program. It should be as easy as adding two numbers. It should be the base layer for computers, not something tacked on at the end. Not in 2024.

HTML should not even exist. The entire Internet should be a massive RPC layer of heterogenous services that expose behaviour. When you connect to my “website”, you should not get a bytestream of HTML, but as Alan Kay suggested, the interpreter should come with it. In other words, you should receive an object, a piece of program, that you attach an output to, and does whatever it wants with it. Free from the limitation of the protocol, my “website” can do anything (computable) on the set of inputs you have given it—an object representing a Canvas, and an object representing keyboard/mouse input.

Security and sandboxing

Which takes us to the other fantastic idea object give us: the object-capability model. A true, fully object-oriented world and paradigm are objects that can only talk with other objects they have received as input. You don’t need a “sandbox” and “permissions” any more. My computable website example above cannot do anything apart from drawing into a canvas and reading input, because those are the only thing you have given it access to. The “what does this piece of code have access to?” problem of computer security becomes “this piece of code has only access to the objects it knows about”.

Network transparency

Kubernetes should not exist either. I should be able to take a running object and “move” it transparently to another node over the Internet. Why is computation still local and we have massive infrastructures to be able to transparently run computation on more than one machine? This goes on a deeper layer than Alan Kay’s objects, but it is a natural evolution of making computing architecture-independent and easily serialisable so it can be transmitted over the wire and executed remotely.


These are some of the affordances that making objects, and communication, first-class would enable. No, I do not think we need to reduce computing to simple data because it’s what we have now, and it is clear to me that it’s one abstraction layer too low to fully leverage modern hardware and the existence of the Internet.

5 Likes

Speaking of Actors, I have to wonder if the Smalltalk image could be used as a basis for one.

( emph mine)

But isn‘t that what HTML+JS in your Browser does?

Sorry @sph I meant to respond to this thread when first started but totally forgot. It seems to me your initial motivation begs the question a bit. It’s not clear to me why a computer with 20 independent CPUs is a more compelling substrate for Alan Kay’s vision than one with one CPU (assuming it’s plenty fast enough). The fact that we reimplement communication in every program doesn’t suggest to me that the way to get “first-class communication” is by… combining it even more tightly with computation.

It seems to me that the biggest problem in interacting with Google is that it lies to us. Replacing data with objects doesn’t address this fundamental issue. It seems at best a side-show. Really I think it’s plausible that lying with code would magnify Google’s lies (e.g. pretending ads are content in ways that are harder to block)

Bottom-line: I have a suspicion that data is more amenable to adversarial interoperability than code. And this feels an order of magnitude more important than expanding the capabilities or expressiveness of our computers.

One internally-consistent argument is that dumb data streams are what has been tried so it might be worth trying alternatives. I’m just not convinced this would be the top thing I try to change about today’s computers.

5 Likes

Thank you very much for this, sph. This is a very good summary of the upside of Alan Kay’s object vision, just as your other thread is a very good summary of the downside of objects and the upside of “dumb data”.

And the most confusing part is that I heartily agree with both points of view!

Kubernetes should not exist either.

Oh definitely. The existence of “containers” and “VMs” when the idea of Objects is literally right there and is all we actually need really, really bugs me. I mean seriously bugs me. Something has gone massively wrong in our Object Oriented toolsets for “simulate an entire imaginary x86 machine with gigabytes of RAM running an entire Unix” to be our standard unit of encapsulation for, essentially, a function.

Next: why am I interacting with Google through a bag of bytes encoded in HTML? It would be more amenable to explorative programming if I could converse with it.

The Microsoft Powershell API to Amazon AWS / Azure is about the closest I have come to this. With a few lines in an interactive shell I can “new” an object - and that object might actually just be a local shim around an entire virtual PCs or virtual LAN that just got spun up in a data center on the other side of the planet.

Being able to do this, with one abstraction (“object”) that can express both “an integer” and “a literal entire VM or virtual network in a warehouse thousands of miles away” is an intoxicating feeling of power. And that sense of power does seem to be Kay’s “systems thinking” at its finest.

But. I’m also deeply uneasy about all the hidden parts that get left out of that picture. Yes, I’m wielding deeply magical spells in a few lines which cause an army of invisible workers (some of whom might even be human workers!) to do stuff for me. That’s awesome. Exponential scaling. One abstraction to rule them all. An object is a system. Little virtual computers all the way down to that integer. Bring it on. The object vision is the cybernetic future of Earth.

But at the same time: do I trust all those invisible workers? Are Amazon and Microsoft actually sympathetic angels toiling for me, or are they cunning demons eavesdropping on all my communications and training an AI on them which they will, one day, unleash to wreak havoc on my life? Do I really have a totally private connection to “my own computer” in a warehouse far away, or just a very clever illusion of having my own computer, and I’m actually deeply, fatally, compromised? I’m sending messages, and getting responses back, but… what about that middle part? The Eve sitting between Alice and Bob, who owns all the warehouses and the fleets of trucks and the comms lines between them?

The power of Objects is that I don’t have to think about “what happens in the middle” - just as is the power of Outsourcing All My Factories To China/India. The power of Efficient Market Theory / the Metaobject Protocol compels you! Execute my instructions! Take my CAD file and 3D print it in steel! I don’t care how many (CPU cycles, peasant girls, kilograms of CO2) it costs, just do it!

But shouldn’t I perhaps be thinking, quite a lot more than I currently am, about that middle part, and just who and what is doing all the outsourcing, and what the side effects (security, privacy, CPU pegged at 100%, occasional genocides) might be?

As I said: I’m very conflicted on this.

Despite my misgivings, and my belief that at some point, all the messages between objects have to bottom out at clearly-defined data standards, it might well be that Alan Kay is correct and objects are the way to go for unified desktop-to-planetary-scale computing, and just haven’t been implemented correctly so far (ie, with object capability security and a standardised serialization protocol).

2 Likes

Sorry, I don’t see how this is OOP’s problem to solve. My goal (and I bet Kay’s goal as well) is to understand the future of coding, not to solve all of humanity’s problems.

You don’t need Amazon or Microsoft if your platform and programming language are designed for the fact that 99% of humans today are running on a networked machine with at least half a dozen independent CPUs, and have one or more of these machines.

If we don’t need Kubernetes, we don’t need AWS either.

Here’s my conundrum: I want to write a stupid application, say a counter that ticks up every second. And with the same ease, I want to transfer it, state and code, from my x86 Linux desktop to my ARM Raspberry PI, so it continues to run there. Imagine how long it would take to implement something like that, in any language.

For me, until this takes more than two clicks, we are still in the stone age of computing.

Dumb data won’t save us from this problem, nor dumb programming languages that focus on 60s problems, i.e. performance and compile-time error checking. Erlang/Elixir is the first step towards solving it, as actor systems make running networked compute much easier than any other dumb language, but it’s still an island running on 60s technology called UNIX.

I think Alan-Kay-objects would be more popular if we programmers stopped focusing so much on efficiency and performance. I don’t claim these are unimportant, but we spend so much thinking about writing low-level performant language, and in reality, text editors take half a gigabyte of memory to run and operating systems cost billions of dollars to develop.

2 Likes

I think I said it before. The meaning of what an actor is, is précise, it a piece of code that receives msgs and responds to them.

On the other hand the meaning of an object is not. An object contains references to other objects but those references need not be unique.

Imagine if you had two cars that shares the same engine. Do normal objects have the ability to share parts? They do not.

Object is such a bad name because no one agrees with what it means.

To me, object and actor are pretty much the same thing. An independent black-box you can send messages to and it responds to them.

The only thing the actor model defines is that you don’t “own” an actor, but instead query it through a “mailing address”, but this is just semantics. A memory pointer works as address as well.

In short, the Alan Kay model of objects is undistinguishable from actors. This is the only model of objects worth discussing, IMO, not the half-baked ideas seen in C++ or Java or other mainstream languages.

1 Like

Here’s my conundrum: I want to write a stupid application, say a counter that ticks up every second. And with the same ease, I want to transfer it, state and code, from my x86 Linux desktop to my ARM Raspberry PI, so it continues to run there. Imagine how long it would take to implement something like that, in any language.

For me, until this takes more than two clicks, we are still in the stone age of computing.

I definitely agree with this. Transferring state and code of an object was what I thought Java was about in 1996; was super disappointed to discover that transferring objects wasn’t anywhere near the list of Java priorities. Java objects remained stuck in one process’s RAM and vanished when that process stopped. That’s probably the part that makes C++/Java objects “not objects” to me: lack of automatic persistence. (Which I think is very closely linked to lack of automatic serialization, and also to having a “stop the world and recompile everything” approach to changes, rather than incremental at-runtime recompilation of single methods.)

I just rediscovered David Ahl’s “Best of Creative Computing Vol 1” from 1978 - a book I have fond memories of as a kid in the 1980s - and was delighted to find that it contains a high school kids’s account of using Smalltalk-72 in 1973! It is hard to see how the experience of having kids writing a graphical Flash-like program as described could have been done in anything other than an object style.

Although, Logo came very close to capturing this “teaching computing” experience - and it got into far more schools than Smalltalk did, because it could run on much lower-specced machines - and it was basically a Forthy Lisp with a verb-based structure. But, the sheer approachability of being able to create your own “little worlds” that are state machines that have a language of their own, and where you know you can’t accidentally “break the whole computer” by runnng the wrong command, because all your commands are context-linked to that little world you created… that’s the upside of the Object vision, I think.

The downside of the object vision, I think is also linked to that lack of automatic persistence: the problem of “yes, I’ve created a neat graphical interactive thing here on this one computer… but how do I get it out of there, how do I share it?” And while it’s not a pretty answer, “dumb data” is an answer of a kind: you can generally share a text file across multiple computers and across decades of time. But, we should have been able to share more useful things than text files (and screenshots of our desktops) by now.

This was still a problem in the 1990s, when object fever was still a thing. We could create Visual Basic components (the closest we got to actual objects on Windows) or Microsoft Office VBA macros (the next best thing)… but sharing them (and safely!) was a huge problem, and remains a huge problem, because everyone you shared your component/script/macro with had to have all of the dependencies it referred to. You were fine if you just used what was in the big monolithic platform - Windows and Office itself. But if you actually tried to use objects as objects, and your component referred to some other cool third-party component you had… well many of those were copyrighted and not allowed to be shared, and others were… well, toxic malware.

I’m not entirely convinced that Office macro viruses became a nightmare because Office wasn’t written using Smalltalk: I think in the fork of the multiverse where we did get an Internet based on Smalltalk objects, they probably have a similarly sized malware problem as we had in the 2000s. Because of everyone in the 1990s being far too open and over-sharey with all their system APIs, and Microsoft Office was the poster child for that. But maybe not quite so many of the i386/C++ raw RAM exploits, which are just embarassing now.

2 Likes

I think Java was ahead of its time with the whole networked object model — developed when CPUs had one core and Internet was not as widespread as today.

Also the Office macro virus thing is just because of a leaky abstraction: COM/CORBA etc. might have offered an object view of the world (I never had the misfortune to program them, so it’s all based on hearsay), but they were an island running on an imperative, insecure C-based operating system.

The question is what would it look like if the entire system were to be designed this way.

Re: “how do I share code across the network?” can be solved with a layer of abstraction: make code architecture independent. Another thing where Java (and later .NET) were ahead of their time. You lose on performance, but performance is overrated anyway :slight_smile:

This is good. We’re starting from problems now instead of solutions. And we likely have different problems in mind.

I think our disagreement here is an indirect sign of agreement with a different statement you made: people implicitly focusing on different problems is an additional sign that we’re in the stone age of computing.

For me the summary of this conversation so far is:

  • You argue for the world to accelerate adoption of solution S because it solves problem P.
  • I point out it exacerbates problem Q which to me seems more important.

Computing doesn’t have to solve all of humanity’s problems. But a foundational belief of mine is that we technologists need to consider the second-order effects of our creations. Particularly when we’re advocating for them to be adopted really widely. If we make one aspect better but a more important aspect significantly worse, that seems like a net negative.

So to go back to your original argument, I think there are 3 possible arguments:

  • Being able to do something in two clicks matters more than making it easier for the powerful to lie. Very difficult argument to make, I think.
  • It doesn’t make it much easier. At that point I’d agree that it doesn’t have to solve all humanity’s problems.
  • Yes, OOP would increase the number of ads everyone is forced to see, and that is terrible. But it lets us attack even more important problems. Maybe we fix hunger. Or it lets us go to the stars, or something.

Whichever way you choose, I don’t think you can convince people of a solution without debating relative merits of problems.

I think Java could have been ahead of its time - but the designers chickened out at the last moment. A system-independent bytecode was pretty much designed for mobile objects travelling across a network, and the “applet” model was pitched as doing half of this (sandboxed, embedded objects in web pages).

But Java itself, in the form it was delivered to the world in 1996 - even with applets - was very surprisingly not about networked objects, but about old-fashioned local programs bound to one machine. The applet might come down the wire but it ran on your machine, in one process, and then was destroyed, just like any other. You couldn’t save an object’s state.

(And then Javascript and the browser API got more capable as Java itself faded, and WASM became the new bytecode, so essentially, we’re in exactly the same world that the success of Java applets would have given us. We still can’t save the state of any objects in our web pages, or detach them from our pages. And since the security model of the browser is entirely based on all objects being tied to “sites” as security zones, it’s not clear how we’d keep ourselves safe if we could detach those objects. But I want to.)

There were some projects built on Java which felt like they were heading in the truly networked objects direction: JINI and JXTA, as I recall. But they were either experimental or not aimed at consumers, and didn’t work out.

Then, there was the very surprising fact that Java even failed at its much less ambitious “sandbox” job in browser applets - which blew my mind, since sandboxing was Java’s “you had one job”. A purely bytecode language, memory managed, how could hostile code possibly access raw RAM? But it turned out that there were weird flaws in the applet implementation itself, or something? They added binary extensions for speed and they didn’t bother to test them? I wish someone could write up a postmortem of what actually went wrong there, because that was NOT the result I was expecting from Java, when I saw it in the 1990s. I figured it was disappointingly conservative in design, but it would at least keep our machines safe, and it didn’t.

On the utter disaster of COM’s design, I agree. (COM/CORBA weren’t so much “objects”, I think as the parallel idea of “reusable software components” - by analogy to integrated circuits in hardware - which comes from a slightly different software engineering heritage, not from SImula or PARC. But 1990s Objects hype led Component systems to describe themselves as object systems, blurring the definition of “object” further.) Probably most of Office’s current macro virus problems come from COM and the x86 memory model. But not all of them: the original macro viruses weren’t smashing RAM and the stack, they were just exploiting the APIs that Microsoft had designed in there, for the user. Helpful convenience functions like “automate writing a document using mail-merge and send it to all the people in my email address book”. Those API failures would still be there given a sane memory-managed design. That’s no excuse for NOT having a sane memory-managed design of course - and that also means we need to not have the Unix approach to one shared filesystem, and storing binaries in it. Or at least we need a strict capability approach to a shared filesystem.

I’m also baffled by / worried about modern Java, and how rapidly it revs its innermost language kernel. Surely the language kernel is something you build once, then leave alone, and everything else is libraries? I feel like modern Java is likely to be making massive “applets” sized security mistakes if they’re changing something so sensitive, so fast, and so constantly.

1 Like

I disagree and find it a bit of a stretch to blame one programming paradigm for a company’s greed. Sorry, it just doesn’t compute for me.

It shouldn’t, because that’s not what I’m doing. I’m not blaming OOP (whatever that means, as we’ve discussed here) for Google. I’m saying your justification for OOP in this thread doesn’t work for me, because it seems in some key ways to lead to an extreme version of the world we already have.

I won’t rehash my arguments, just reiterate that I get there starting from your statements at the top of this post.

We’re likely talking past each other in a way we haven’t been able to see. “Not persuasive” on one side, “stretch” on the other.

A couple more points:

  • I’m actually not opposed to Alan Kay’s vision of objects. So for me this thread really is just about the justifications you’re putting forward for it.

  • Ignoring all the new risks I’m trying to point out, one critique I have for your original statement is that a lot of it boils down to “there oughta be a better way,” but the axis in your mind of what makes something bad or good is often left implicit and unsaid. I might be persuaded more if you filled in missing steps in your reasoning. For starters just get rid of all the statements that just state something is bad. Is there anything left? Perhaps it is more potent if it’s concentrated. Then consider adding back the statements you took out one by one, after adding more justification for each of them.