It would have been kind of great to see an OOP language with Alan's design, but with a better syntax. I dislike smalltalk syntax. Barely anyone uses smalltalk today.
Even then, we'd also have an OOP language to be really really fast. Otherwise people will just use C.
Java itself is too verbose and has a rather boring OOP model.
Self took the path of removing things instead of changing the syntax. It kept Smalltalk's keyword message syntax, made even smaller (no assignment syntax, variables are just slots you send messages to), and took away the classes. Only objects remain, and they inherit directly from other objects. Then Randy Smith and John Maloney gave it a visual syntax: in the Self environment you program by direct manipulation of live objects, opening outliners and editing their slots, so the environment is the syntax and the text is mostly incidental.
Your speed point is answered by the same work. Craig Chambers, David Ungar and Urs Holzle's compiler for Self (customization, inline caches, adaptive recompilation) was so fast that the technology went on to HotSpot and V8, and those ideas are why Java and JavaScript are fast today. Removing the classes made the language simpler, and the simpler language turned out to be easier to make fast.
Then David Ungar, Harold Ossher and Doug Kimelman at IBM took the next thing away. Korz removes the objects and leaves the slots. A program is a flat sea of slots that belong to nothing. Each slot has a guard on named dimensions, and a message is sent in a context of dimension:coordinate bindings, mostly carried implicitly down the call chain the way "this" is in OO languages. The receiver is demoted to one ordinary dimension (rcvr) among any number, dispatch is symmetric over the whole context, the most specific matching slot runs, and a tie is an error.
The syntax is the least interesting part. The prototype was an interpreter written in Self, and the paper's examples look roughly like JavaScript with guards in front:
{rcvr <= stack} pop() { ... }
{rcvr <= stack, assertions <= true} pop() { ... check, then pop ... }
The semantics are the interesting part. The second pop is more specific, so it wins whenever the context says assertions: true. main() turns assertions on, and not one line of code in between mentions them: the binding flows down implicitly to every send underneath. You've added a new dimension of variation to a running program without touching anything between the top and the bottom. No layers, no aspects, no Visitor pattern.If that sounds familiar, it's the same thing as Lisp Machine Flavors' before and after daemons, or CLOS's :before, :after and :around methods, or plain old subclassing: override a method, do some extra stuff first, call super (or call-next-method), then do some more stuff after. The more specific method gets the first crack at it, and decides whether and when the less specific methods run.
Korz just models that as slots with guards. The checking pop does its checks, then re-sends pop with assertions: false, which no longer matches its own guard, so the plain pop runs. Method combination isn't a language feature you need a MOP to change, it's a pattern you write with ordinary dispatch. (What "super" should mean in Korz is still an open question, since there's no class or owner object to be "super" relative to.)
Guards are simple: for each dimension, a slot can ignore it, require it to be bound (binding its value as a parameter), or require its coordinate to be or inherit from a given coordinate, like assertions <= true or rcvr <= stack. Coordinates are objects with parents, so "<=" means "is or inherits from", not numeric less-than, and matching a constant is just the case of a coordinate with no children. No arbitrary predicates, so no Pascal-style ranges like 10 < x < 20, unless you make a coordinate for the range and have its members inherit from it.
And "object" doesn't disappear, it becomes subjective. Group the slots by rcvr and you see ordinary objects. Group them by assertions and you see the checking layer. Group them by user and you see one person's view of the whole system. Same sea of slots, different cuts, and no cut is the privileged one. The name comes from Korzybski: the map is not the territory.
Korz: Simple, Symmetric, Subjective, Context-Oriented Programming (Onward! 2014):
https://dl.acm.org/doi/10.1145/2661136.2661147
Korz is multi-dimensional. Procedural programming is zero-dimensional, and object-oriented programming is one-dimensional (the implicit receiver parameter, usually spelled self, this, or rcvr), so both are the special cases 0 and 1 of Korz. Korz can dispatch on any number of parameters, none of them special like self or this, and the guards on the slots decide which slot is the most specific one to dispatch to.
So a Self program is just a Korz program that happens to use only one dimension, called rcvr. Objects are subjective and assemble dynamically depending on how you're looking at them (the coordinates of the dimensions), and in the special case of single dispatch on rcvr, everything looks like an object.
Call it the faith of our fathers. Kristen Nygaard and Ole-Johan Dahl gave us classes in Simula. Alan Kay gave us objects sending messages in Smalltalk. Claude Shannon had already given us a sender, a channel and a receiver, and object-oriented programming made the receiver the one privileged thing every message is about. David Ungar and Randall Smith took away the classes in Self. Then Ungar, Ossher and Kimelman took away the receiver in Korz.
Which makes it a lot like Philip K. Dick's "Faith of Our Fathers" (Dangerous Visions, 1967). The Party keeps everyone docile with hallucinogens, so everyone sees the same benign human Leader on TV. Tung Chien gets an anti-hallucinogen from a street vendor and sees what the Leader actually is, and it isn't a man. The reversal is that the shared view was the drugged one, and when he meets the underground, it turns out that each of them saw something different.
There's no single true form, just what each viewer brings. Single dispatch is the stuff in the water: it makes everybody see the same objects. Korz is the antidote, and what an object looks like depends on the coordinates you're looking from. In Dick's afterword he quotes John Scotus Erigena, from AD 840: "We do not know what God is. God Himself does not know what He is because He is not anything." A Korz object isn't anything either, until a context gathers its slots.
https://en.wikipedia.org/wiki/Faith_of_Our_Fathers_(short_st...
That's also why you don't need things like the Visitor pattern, which is a kludge for the fact that you can only dispatch on one parameter. Multiple dispatch is something some object systems support, like Common Lisp's CLOS and its MOP, but Korz takes it all the way and has no special case for self/this/rcvr.
https://en.wikipedia.org/wiki/Multiple_dispatch
The Finest Object System You've Never Heard Of: "The Common Lisp Object System is the finest object system in existence, and I bet you've never even heard of it."
https://mendhekar.medium.com/the-finest-object-system-youve-...
Why would you want multiple dispatch? The Margolus neighborhood for block cellular automata is a great example. Rules apply to all four rotations of a block of four cells, so the neighborhood is Center, Clockwise, CounterClockwise, and Opposite, instead of just one self. You can write elegant, concise rules that way, and the compiler can produce efficient code or lookup tables.
https://en.wikipedia.org/wiki/Block_cellular_automaton
I've had success applying the ideas from Self to a file system based object system for LLM orchestrated simulations (moollm). Then David Ungar told me about Korz, which totally blew my mind and made me rethink a lot of things -- but it's beautifully backwards compatible with what I've been doing with Self.
Here are some notes on applying Korz to cellular automata (with neighborhood and time dimensions), and to adventure game parsers and simulators like Zork (with direct object, verb, indirect object, location, and player dimensions). David Ungar assured me Zork is only coincidentally an anagram of Korz, but it's too sweet a coincidence to pass up, because Korz is really useful for elegantly modeling that kind of stuff.
https://github.com/SimHacker/moollm/tree/main/designs/korz
Recently I've been thinking about how to apply Korz to LLM driven simulations, which I'm calling Korz' (Korz-Prime):
https://github.com/SimHacker/moollm/tree/main/designs/korz/k...
Crystal is a fast, compiled OOP language. It has static type inference with Ruby-style syntax. Ruby's OOP model took inspiration from Smalltalk.
How about Elixir and Erlang? They do pretty much exactly what Kay preaches.
Interestingly, the OO model that Wirth and Gutknecht implemented in the Oberon system corresponds better to Kay's message-based vision than Smalltalk-80. Wirth arrived here not by trying to emulate biology, but by trying to avoid the V-Table.
Java implemented the Simula 67 object model, confirmed e.g. by a 2017 Gosling lecture (as did early C++ and Smalltalk-80 to a significant degree).