Did he though? TMK Shannon did specifically not give a way to deal with noisy channels, no. He invented a way to quantify what could be sent on a noisy channel if you figure out the optimal way to do it. This is very similar to "no matter what you figure out about faster travel, you can't go faster than light in a vacuum".
Calculating the limit is easy with Shannon's theorem. Approaching it in practice is hard.
kragen 6 hours ago [-]
If I recall correctly, he invented the optimal way to do it and published it in the original paper: use an arbitrarily long random code. The difficulty is that decoding a random code in the obvious way (compare the received codeword against each codeword in the codebook and decode as the one with the lowest Hamming distance) requires an exponentially large amount of both memory and computation. As I understand it, the advances since then have all been about how to get closer to the Shannon limit with reasonable amounts of computation by using codewords that aren't truly random.
PunchyHamster 1 days ago [-]
> Calculating the limit is easy with Shannon's theorem. Approaching it in practice is hard.
Many modern modulations already operate basically on Shannon's limit for a given band/SNR. Well, on raw data, the encoding almost always use some kind of error correction so the decoded bitrate is few % lower than the wire one
tverbeure 1 days ago [-]
That’s understating the importance of the error coding. The modulation scheme is almost a side show, it’s the modern error coding algorithms (LDPC or Turbo coding) that allows you to get arbitrary close to the Shannon limit.
ironqcold 1 days ago [-]
Fair distinction
dang 1 days ago [-]
The full talk seems to be at https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0..., but with a confusing interface (text chat flying by at speed, and no actual video of Alan, though you do get a prolonged view of a whiteboard). Maybe there's another copy that exists or will show up somewhere?
DonHopkins 1 days ago [-]
Yes it's a pretty klunky interface. Easy to miss that there are multiple camera icons to the right of the time slider, and you can switch to see different feeds like the speaker or their slides. It's still kind of hit or miss with some of the speakers, but at least Alan got a chance to test things out and debug all the glitches before his talk, so he didn't end up repeatedly interrupting himself!
Here is the full list of links from the video description to other related and interesting topics.
I can highly recommend smoking a joint and watching James "Doctor Chaos" Crutchfield's "Space-Time Dynamics in Video Feedback" film, which he made at UC Santa Cruz in 1984, building on Ralph Abraham's video feedback experiments there in the 1970s:
Aha i saw this video in a comment on another HN thread this week: https://news.ycombinator.com/item?id=49791117 Avoiding the babbling-idiot failure in a time-triggered communication system
aworks 1 days ago [-]
Alvin Lucier wrote other highly interesting, if unconventional works, although similar to John Cage's 4'33", this is the one that achieved meme status as conceptual art.
RobRivera 1 days ago [-]
Can someone please explain to me what this is all about?
DonHopkins 1 days ago [-]
My favorite part was how Alan's exuberant "I realize what the fuck is going on and it's just so amazing" got distorted by YouTube's speech to text transcription replacing "fuck" with "[__]", adding another layer of censorship noise and interpretation to the mix.
And how the conference's real time speech to text transcription honored Alan's "fuck", but would occasionally lapse into Danish, and say things like "We will eat your hands".
dang> Hopefully Don won't mind!
Of course not, and I hope Alan won't either, since in the recording he laughed and said "Yeah, this will be this will be fun."
thatspartan 1 days ago [-]
The way I've understood it is Shannon showed that it's possible to reliably send a signal even if you know the signal will get corrupted before arriving at the other end.
Shannon's theory is foundational to modern communication systems. You can expect to have WiFi remain functional even as other devices use the same medium. Up to a point, the Shannon limit in other words.
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.
jecel 22 hours ago [-]
You are in luck: Alan Kay's original Smalltalk, also known as Smalltalk-72, doesn't have a syntax but instead allows you to define your own. Each class includes a single method that parses incoming messages however it wants.
The two problems with this were a lack of performance and the difficulty of understanding other people's code.
Dan Ingalls looked at the most popular styles people had created in Smalltalk-72 and defined a fixed syntax for Smalltalk-76 with the same flavor. This allowed him to "compile" -76 into bytecodes which would then be executed much faster by an interpreted virtual machine (and years later a JIT compiled one).
The analogy is putting grass everywhere in a new university campus and after a while seeing where the grass has been trampled and putting concrete sidewalks there.
For Smalltalk-80 they wanted people to be able to use it on their own computers and not only on the special Xerox PARC ones so the patched the syntax to use ASCII instead of their own character set. That made it uglier, in my opinion.
I can understand many people not liking the Smalltalk-80 syntax, but we do get some new people to the language every year and quite a few of them find the syntax one of the nicest features.
Rochus 1 days ago [-]
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).
DonHopkins 1 days ago [-]
Speaking of vtables, at Kristen Nygaard's 100-year birthday celebration Bjarne Stroustrup also gave a fascinating talk after Alan Kay's, and they had some spicy back-and-forth discussion afterwards! Both call themselves Nygaard's heirs, anbd it was a delightful and respectful interplay between very different world views.
Kay came to Simula as a reader, turned it into Smalltalk, and later knew Nygaard and Dahl as colleagues. Stroustrup was taught by Nygaard in person, as a student at Aarhus, and then used Simula for his PhD.
Roughly: Stroustrup said he never took much from Smalltalk. What he took from Simula was the static part, compile-time guarantees and a direct map to hardware with zero-overhead abstraction, and C++ was never meant to be just an object-oriented language, since not everything is a class hierarchy or a virtual function. Kay argued that late binding pays for itself because the human is the slow part of an interactive system, and that static typing is a good idea applied prematurely. They agreed that the real job of an operating system or the internet is never to crash and never lose anything, and came at it from opposite ends: Stroustrup is working on guarantees against dangling pointers, out of range access, and uninitialized memory in C++, while Kay pointed out that Smalltalk protected every object dynamically.
If you hate llm generated summaries then you can stop here and go watch the entire video yourself, but here are timestamps and summaries for people who don't have five hours to spare (although I highly recommend it -- I was watching it in real time when I witnessed the feedback performance between talks):
4:56:49: Stroustrup says he was never much inspired by Smalltalk. What he took from Simula was the static part: compile-time guarantees. "It would be nice to say yes, but to be honest, not much."
4:58:25: Stroustrup on garbage collection versus scope-based resource management (RAII): nobody has managed to combine them. Java's finalizers are his example, and somene mentions Lars Bak, "also from here" (Aarhus), says never use finalizers, they're evil.
5:00:24: Banter. Someone asks whether there's anything he likes about Smalltalk, and the reply is "Anything you like about me?"
5:00:47: Kay agrees reuse isn't a good reason for much, asks why people cling to old languages, and brings up the CrowdStrike crash taking down hospitals.
5:02:05: Stroustrup says CrowdStrike was a violated configuration rule, not a language problem. Programmers and managers are conservative and "confuse familiar with simplicity." He's not saying C++ is right for everything, and Python's all-dynamic approach is successful.
5:04 to 5:06: Kay says late-bound slowness pays for itself because humans are the slow part of interactive computing. Computing is held back by corporate legacy, and PARC was lucky to build all its own hardware and software.
5:07: An audience question about the next ten years. Kay says operating systems and the internet put you in a different seat of responsibility: the goal is never to crash and never to lose anything.
5:08:59: Stroustrup agrees, but says he doesn't control any operating system. He's working on guarantees in C++: no dangling pointers, no out-of-range access, no uninitialized memory.
5:09:55: Kay says typing is a really good idea, just premature in its static form. Smalltalk's dynamic typing protected every object.
5:10:34: Stroustrup says it's very hard to get hardcore developers to stop believing they can crash a system.
5:11:59 to 5:13:40: Kay says the Smalltalk image was a complete operating system, and that he made a living writing microcode. The field is guilty of not keeping up with the hardware. Stroustrup says he tried to talk hardware makers into adding support features, in his PhD, and failed.
andrekandre 21 hours ago [-]
> Computing is held back by corporate legacy, and PARC was lucky to build all its own hardware and software.
this really resonates... apple makes both the hardware and software, is massively profitable and yet swift is basically a much much better c++ in a lot of ways. and xcode is just totally absurd excuse of a development environment...
is it better than before and welcome improvement? yes, but fundamentally conservative compared to what parc was doing with much much less...
DonHopkins 17 hours ago [-]
Alan's lament about MVC applies to many things in computing:
>Things seem to hang on in computing just because they work a little bit.
>MVC was originally done at PARC almost 40 years ago. The good part was philosophical -- the idea to adapt the notion of "cameras" and "worlds" in the original 3D graphics stuff I participated in at Utah 45 years ago. The bad part of MVC was how we implemented it -- much too much machinery, etc.
>We (my various groups since then, including Viewpoints Research) have not thought about MVC since, but have used and devised various viewing methods over the last 20+ years. I like to do views as "watchers" which do not affect what they are viewing. There are lots of ways to do this. Similarly, I like to also use "watchers" (context sensitive to the views) to catch needed inputs. We have never done a really satisfactory automatic inverter for dealing with the loss of "dimensions" that happen when a view is made (but we have done some experimental ones).
>One important criterion is for end-users of all kinds to be able to easily make their own views in a very powerful ad hoc way via construction. We have done a number of adaptations and generalizations of how this can be done in Hypercard -- and this seems to work well (enough).
>Since we always roll our own languages and development systems, we don't care about problems that other systems might have. For example, we have very little knowledge about C#, etc. We do try to learn from the few good systems that are out there.
[...]
andrekandre 5 hours ago [-]
that also rings true, as someone who has had to deal with mvc in various forms; its all so complicated, and views as watchers is exactly what i'd want
slight digression, but i feel like alot of the want for using llms for coding is because people are tired of dealing with all the complexity of implementing things that should be simple and easy; like llms are a crutch for complexity we are drowning in and people just want to "throw it at the llm" and be done with it...
Rochus 24 hours ago [-]
> Kay came to Simula as a reader, turned it into Smalltalk
There is a significant difference between Simula I and Simula 67, and Kay in his 1969 dissertation only referenced the 1966 ACM paper on Simula I. It took many more years until Simula 67 was referenced in a publication by Kay or his team (specifically, "SIMLUA Begin" in Ingalls' 1978 publication about Smalltalk-76). The documented facts (see also Ingalls' 2020 ACM HOPL paper) rather suggest the following relations: Kay - Simula I - Smalltalk-72 and Ingalls - Simula 67 - Smalltalk-76/80
dang 1 days ago [-]
> 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.
That's interesting! what did they do that corresponded better?
Rochus 1 days ago [-]
In contrast to the "usual" (i.e. Simula 67 based) OO approach, Wirth avoided virtual methods in his Oberon language, but instead used type extension (i.e. inheritance) to declare specialized message records (as the replacement to variant records of Pascal and Modula) which were handled by procedure-typed fields of record variables (i.e. objects) using polymorphic dispatch based on the dynamic message type. The intention was not to "correspond better" to Kay's vision (Wirth likely didn't know Kay nor was he interested in his visions), but he arrived at a similar design from a different motivation. And the analogy only holds when considering what Kay and team actually implemented (i.e. "message delivery" - a record in case of Oberon, a stream of tokens in case of Smalltalk-72 - via synchronous call semantics). Smalltalk-80 instead implemented compiled virtual methods and table-based polymorphic dispatch like Simula 67, just with a dynamically typed language.
kragen 6 hours ago [-]
While I agree with what you say about Oberon and Smalltalk, you've made some mistakes about Wirth.
Wirth did know Kay; his inspiration for the Lilith and Oberon projects, as he explains in his HOPL III paper on Modula-2 and Oberon, was spending a sabbatical year at PARC in 01976 and 01977, where Kay was then the director of the Learning Research Group, which had pioneered the GUI. However, Wirth's style was more influenced by the Smalltalk-inspired GUI being written in Mesa, which would officially give rise to Cedar in 01980. As he explains in the Oberon book, he considered overlapping windows (which Smalltalk-76 had) to be unnecessary complexity.
Smalltalk-76 already had compiled virtual methods and table-based polymorphic dispatch like SIMULA, by the way.
Rochus 6 hours ago [-]
> a sabbatical year at PARC in 01976 and 01977, where Kay was then the director of the Learning Research Group
Well, PARC was quite big and Wirth was focussed on the work the Mesa people with Buttler Lampson did. If you watch the Q&A session of his 1993 HOPL talk you may notice that Kay asked a question, and it is obvious that Wirth didn't know him in person. And I'm not aware of any Wirth publication before 1987 mentioning Smalltalk. The only publication where Kay appears by name at all (as "Smalltalk (Goldberg and Kay, 1980)") is Wirth's 2008 IEEE paper.
> However, Wirth's style was more influenced by the Smalltalk-inspired GUI being written in Mesa, which would officially give rise to Cedar in 01980
Pretty adventurous claims. Wirth adopted Cedar’s tiled-viewer approach; I'm not aware of any features he adopted from the Smalltalk GUI. Instead he considered Smalltalk an anti-pattern in several respects, which you confirm.
> Smalltalk-76 already had compiled virtual methods and table-based polymorphic dispatch like SIMULA
Right. That's what Ingalls published in his 1978 paper, where he explicitly quotes the 1973 "SIMULA Begin" version and discusses its features.
The examples near the top use the more familiar OOP approach, while the example at the bottom uses message sending.
DonHopkins 1 days ago [-]
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:
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 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.
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.
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."
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.
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.
This is a great post, thanks. I've been following prototype systems since I first logged into lambdamoo in 91, and Self is an old intellectual muse of mine but this is the first time I'd seen Korz.
You might be interested in my lang/environment "mica" which attacks this same dimension of problems from a relational/datalog angle and then makes object/prototype identity hopefully emergent out of that: https://github.com/timbran-project/mica -- relational dispatch feels like a broadening of multiple dispatch.
I feel like I may have ended up at a similar place as Korz without realizing it. I will need to dig into this paper.
Speaking also of multiple dispatch and prototypes, there's also this paper from an old acquaintance: https://www.cs.cmu.edu/~aldrich/courses/819/salzman-pmd.pdf which I used to find interesting (and built my first version of "mica" back then around the idea).
goatlover 1 days ago [-]
Crystal is a fast, compiled OOP language. It has static type inference with Ruby-style syntax. Ruby's OOP model took inspiration from Smalltalk.
Calculating the limit is easy with Shannon's theorem. Approaching it in practice is hard.
Many modern modulations already operate basically on Shannon's limit for a given band/SNR. Well, on raw data, the encoding almost always use some kind of error correction so the decoded bitrate is few % lower than the wire one
Here is the full list of links from the video description to other related and interesting topics.
I can highly recommend smoking a joint and watching James "Doctor Chaos" Crutchfield's "Space-Time Dynamics in Video Feedback" film, which he made at UC Santa Cruz in 1984, building on Ralph Abraham's video feedback experiments there in the 1970s:
https://www.youtube.com/watch?v=B4Kn3djJMCE
https://en.wikipedia.org/wiki/James_P._Crutchfield
https://en.wikipedia.org/wiki/Ralph_Abraham_(mathematician)
Kristen Nygaard 100 Years, Celebration Symposium (Aarhus University, Aug 27 2026):
https://cs.au.dk/nygaard100years/celebration
Entire Nygaard Symposium Recording (Alan Kay's talk begins at 3:27:49):
https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
Alan Kay:
https://en.wikipedia.org/wiki/Alan_Kay
Claude Shannon:
https://en.wikipedia.org/wiki/Claude_Shannon
Information Theory:
https://en.wikipedia.org/wiki/Information_theory
Noisy-Channel Coding Theorem:
https://en.wikipedia.org/wiki/Noisy-channel_coding_theorem
Audio Feedback:
https://en.wikipedia.org/wiki/Audio_feedback
Video Feedback:
https://en.wikipedia.org/wiki/Video_feedback
Live Looping: The History And The Practice, by Stephen Garza:
http://computermusic2008.wikidot.com/live-looping:history-an...
I Am Sitting in a Room:
https://en.wikipedia.org/wiki/I_Am_Sitting_in_a_Room
Alvin Lucier on "I am sitting in a room":
https://www.youtube.com/watch?v=v9XJWBZBzq4
And how the conference's real time speech to text transcription honored Alan's "fuck", but would occasionally lapse into Danish, and say things like "We will eat your hands".
dang> Hopefully Don won't mind!
Of course not, and I hope Alan won't either, since in the recording he laughed and said "Yeah, this will be this will be fun."
Shannon's theory is foundational to modern communication systems. You can expect to have WiFi remain functional even as other devices use the same medium. Up to a point, the Shannon limit in other words.
Hopefully Don won't mind!
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.
The two problems with this were a lack of performance and the difficulty of understanding other people's code.
Dan Ingalls looked at the most popular styles people had created in Smalltalk-72 and defined a fixed syntax for Smalltalk-76 with the same flavor. This allowed him to "compile" -76 into bytecodes which would then be executed much faster by an interpreted virtual machine (and years later a JIT compiled one).
The analogy is putting grass everywhere in a new university campus and after a while seeing where the grass has been trampled and putting concrete sidewalks there.
For Smalltalk-80 they wanted people to be able to use it on their own computers and not only on the special Xerox PARC ones so the patched the syntax to use ASCII instead of their own character set. That made it uglier, in my opinion.
I can understand many people not liking the Smalltalk-80 syntax, but we do get some new people to the language every year and quite a few of them find the syntax one of the nicest features.
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).
Kay came to Simula as a reader, turned it into Smalltalk, and later knew Nygaard and Dahl as colleagues. Stroustrup was taught by Nygaard in person, as a student at Aarhus, and then used Simula for his PhD.
Roughly: Stroustrup said he never took much from Smalltalk. What he took from Simula was the static part, compile-time guarantees and a direct map to hardware with zero-overhead abstraction, and C++ was never meant to be just an object-oriented language, since not everything is a class hierarchy or a virtual function. Kay argued that late binding pays for itself because the human is the slow part of an interactive system, and that static typing is a good idea applied prematurely. They agreed that the real job of an operating system or the internet is never to crash and never lose anything, and came at it from opposite ends: Stroustrup is working on guarantees against dangling pointers, out of range access, and uninitialized memory in C++, while Kay pointed out that Smalltalk protected every object dynamically.
Alan Kay's talk:
https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
Bjarne Stroustrup's talk:
https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
The discussion afterwards:
https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
If you hate llm generated summaries then you can stop here and go watch the entire video yourself, but here are timestamps and summaries for people who don't have five hours to spare (although I highly recommend it -- I was watching it in real time when I witnessed the feedback performance between talks):
4:56:49: Stroustrup says he was never much inspired by Smalltalk. What he took from Simula was the static part: compile-time guarantees. "It would be nice to say yes, but to be honest, not much."
4:58:25: Stroustrup on garbage collection versus scope-based resource management (RAII): nobody has managed to combine them. Java's finalizers are his example, and somene mentions Lars Bak, "also from here" (Aarhus), says never use finalizers, they're evil.
5:00:24: Banter. Someone asks whether there's anything he likes about Smalltalk, and the reply is "Anything you like about me?"
5:00:47: Kay agrees reuse isn't a good reason for much, asks why people cling to old languages, and brings up the CrowdStrike crash taking down hospitals.
5:02:05: Stroustrup says CrowdStrike was a violated configuration rule, not a language problem. Programmers and managers are conservative and "confuse familiar with simplicity." He's not saying C++ is right for everything, and Python's all-dynamic approach is successful.
5:04 to 5:06: Kay says late-bound slowness pays for itself because humans are the slow part of interactive computing. Computing is held back by corporate legacy, and PARC was lucky to build all its own hardware and software.
5:07: An audience question about the next ten years. Kay says operating systems and the internet put you in a different seat of responsibility: the goal is never to crash and never to lose anything.
5:08:59: Stroustrup agrees, but says he doesn't control any operating system. He's working on guarantees in C++: no dangling pointers, no out-of-range access, no uninitialized memory.
5:09:55: Kay says typing is a really good idea, just premature in its static form. Smalltalk's dynamic typing protected every object.
5:10:34: Stroustrup says it's very hard to get hardcore developers to stop believing they can crash a system.
5:11:59 to 5:13:40: Kay says the Smalltalk image was a complete operating system, and that he made a living writing microcode. The field is guilty of not keeping up with the hardware. Stroustrup says he tried to talk hardware makers into adding support features, in his PhD, and failed.
is it better than before and welcome improvement? yes, but fundamentally conservative compared to what parc was doing with much much less...
https://news.ycombinator.com/item?id=8841428
>I asked Alan Kay about his thoughts on MVC:
[...]
>From: Alan Kay
>Things seem to hang on in computing just because they work a little bit.
>MVC was originally done at PARC almost 40 years ago. The good part was philosophical -- the idea to adapt the notion of "cameras" and "worlds" in the original 3D graphics stuff I participated in at Utah 45 years ago. The bad part of MVC was how we implemented it -- much too much machinery, etc.
>We (my various groups since then, including Viewpoints Research) have not thought about MVC since, but have used and devised various viewing methods over the last 20+ years. I like to do views as "watchers" which do not affect what they are viewing. There are lots of ways to do this. Similarly, I like to also use "watchers" (context sensitive to the views) to catch needed inputs. We have never done a really satisfactory automatic inverter for dealing with the loss of "dimensions" that happen when a view is made (but we have done some experimental ones).
>One important criterion is for end-users of all kinds to be able to easily make their own views in a very powerful ad hoc way via construction. We have done a number of adaptations and generalizations of how this can be done in Hypercard -- and this seems to work well (enough).
>Since we always roll our own languages and development systems, we don't care about problems that other systems might have. For example, we have very little knowledge about C#, etc. We do try to learn from the few good systems that are out there.
[...]
slight digression, but i feel like alot of the want for using llms for coding is because people are tired of dealing with all the complexity of implementing things that should be simple and easy; like llms are a crutch for complexity we are drowning in and people just want to "throw it at the llm" and be done with it...
There is a significant difference between Simula I and Simula 67, and Kay in his 1969 dissertation only referenced the 1966 ACM paper on Simula I. It took many more years until Simula 67 was referenced in a publication by Kay or his team (specifically, "SIMLUA Begin" in Ingalls' 1978 publication about Smalltalk-76). The documented facts (see also Ingalls' 2020 ACM HOPL paper) rather suggest the following relations: Kay - Simula I - Smalltalk-72 and Ingalls - Simula 67 - Smalltalk-76/80
That's interesting! what did they do that corresponded better?
Wirth did know Kay; his inspiration for the Lilith and Oberon projects, as he explains in his HOPL III paper on Modula-2 and Oberon, was spending a sabbatical year at PARC in 01976 and 01977, where Kay was then the director of the Learning Research Group, which had pioneered the GUI. However, Wirth's style was more influenced by the Smalltalk-inspired GUI being written in Mesa, which would officially give rise to Cedar in 01980. As he explains in the Oberon book, he considered overlapping windows (which Smalltalk-76 had) to be unnecessary complexity.
Smalltalk-76 already had compiled virtual methods and table-based polymorphic dispatch like SIMULA, by the way.
Well, PARC was quite big and Wirth was focussed on the work the Mesa people with Buttler Lampson did. If you watch the Q&A session of his 1993 HOPL talk you may notice that Kay asked a question, and it is obvious that Wirth didn't know him in person. And I'm not aware of any Wirth publication before 1987 mentioning Smalltalk. The only publication where Kay appears by name at all (as "Smalltalk (Goldberg and Kay, 1980)") is Wirth's 2008 IEEE paper.
> However, Wirth's style was more influenced by the Smalltalk-inspired GUI being written in Mesa, which would officially give rise to Cedar in 01980
Pretty adventurous claims. Wirth adopted Cedar’s tiled-viewer approach; I'm not aware of any features he adopted from the Smalltalk GUI. Instead he considered Smalltalk an anti-pattern in several respects, which you confirm.
> Smalltalk-76 already had compiled virtual methods and table-based polymorphic dispatch like SIMULA
Right. That's what Ingalls published in his 1978 paper, where he explicitly quotes the 1973 "SIMULA Begin" version and discusses its features.
https://miasap.se/obnc/data-abstraction.html
The examples near the top use the more familiar OOP approach, while the example at the bottom uses message sending.
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.
https://selflanguage.org/
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:
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...
You might be interested in my lang/environment "mica" which attacks this same dimension of problems from a relational/datalog angle and then makes object/prototype identity hopefully emergent out of that: https://github.com/timbran-project/mica -- relational dispatch feels like a broadening of multiple dispatch.
I feel like I may have ended up at a similar place as Korz without realizing it. I will need to dig into this paper.
Speaking also of multiple dispatch and prototypes, there's also this paper from an old acquaintance: https://www.cs.cmu.edu/~aldrich/courses/819/salzman-pmd.pdf which I used to find interesting (and built my first version of "mica" back then around the idea).
https://crystal-lang.org/