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
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.
My favorite part was how Google's speech to text transcriptions censored the word "fuck" to "[__]", adding another layer of censorship noise and interpretation to the mix.
And how the conference's real time speech to text transcription would occasionally lapse into Danish, and say things like "We will eat your hands".
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.
> 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?
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 works 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 procedure calls). Smalltalk-80 instead implemented compiled virtual methods and table-based polymorphic dispatch like Simula 67, just with a dynamic language.
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.
> 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 HOPL you may notice that Kay asked a question, and it is obvious that Wirth didn't know him.
You could be right that Wirth didn't know Kay well enough to recognize them. I thought of PARC in that period as being relatively small, and Kay was fairly prominent within it, so I'm sure he had at least seen the man.
However, I don't think it's particularly adventurous to claim that the Mesa group's GUI was inspired by Smalltalk's, though. They added their own innovations, of course, like the tiled-viewer approach Wirth later used in Oberon, but the basic grammar of windows with titlebars and text in them, noun-verb commands acting on highlighted text selections, scrollbars, menus, and a mouse to point at them, was developed in Smalltalk from its Augment/NLS roots.
Brad Allan Myers wrote his 01980 MIT master's thesis, "Displaying Data Structures for Interactive Debugging"†, about the graphical debugger Incense, which he wrote in Mesa, initially while he was at PARC. By chance this is one of the earliest papers describing the GUIs written in Mesa. What he says about Smalltalk's contribution to GUIs is:
> It was felt that graphics would make the system easier to learn and use [Kay 77]. Smalltalk developed the idea, first proposed in the FLEX system [Kay 69], of using multiple overlapping rectangular regions called windows to extend the available screen space [Goldberg 79]. [...] Smalltalk presents a uniform window interface both to the programs and the user, thereby allowing complex systems to be easy to use (e.g., an animation system [Backer 76] and Thinglab (section 3.6.4)).
"Backer 76" is presumably Ron Baecker's SIGGRAPH paper "A Conversational Extensible System for the Animation of Shaded Images," because there's no "Backer" in his bibliography. Thinglab is the constraint satisfaction system that Alan Borning wrote his 01979 doctoral dissertation on. Goldberg is of course Adele Goldberg from Kay's Learning Research Group."Kay 69" is Alan Kay's doctoral dissertation, "The Reactive Engine".
He credits pointing devices to Sketchpad in 01963, pointing for interactive debugging to someone named Zimmerman in 01967, and the mouse to Bill English in 01967. He shows a screenshot of Teitelman's DLISP UI for debugging Interlisp, which evidently also has highlighted text selections, menus, and overlapping windows with titlebars; Myers describes its windows as "essentially the same as Smalltalk windows", not vice versa.
With respect to the Alto, on p.37, Myers calls out the importance of the Alto's BitBlt microcode for GUIs like the one he mentions; he doesn't mention that it originated in a non-microcoded version written in 01975 by Dan Ingalls, Larry Tesler, Bob Sproull, and Diana Merry, for Smalltalk-72, and that the microcode version was written by Ingalls. At least Ingalls and Merry were in the LRG; I'm not sure about Tesler and Sproull.
On p. 39, we see a screenshot of Mesa's normal windowed debugger, which used overlapping windows at the time — so Cedar's tiled viewers were a later innovation, even within the Mesa group. The windows have titlebars and what appears to be a Smalltalk-style vertical popup menu.
None of the screenshots show scrollbars, but even in Smalltalk they were pop-up at the time to save scarce screen space.
The reason I keep mentioning titlebars and popup menus is that precursor GUI systems like SKETCHPAD, GENESYS, and Augment/NLS didn't have them. They all had pointing devices and windows, and GENESYS even had menus, but not popup menus.
You might reasonably argue that GUIs that ran on the Alto had to use a mouse like Smalltalk did, not because they were modeled on Smalltalk, because that's what the Alto had. But why did the Alto have the mouse? I don't know which ideas were contributed by which contributors, of course. But Kay was one of those contributors.
Shortly before Myers's thesis, in 01979, PARC CSL-79-11, "Alto: A Persona...
> I think that my claim that Mesa's GUI was inspired by Smalltalk
That was not my topic.
I was (obviously) talking about the influence of Smalltalk to Oberon, and only that.
And don't forget that the Smalltalk 76 and 80 GUI we know today was mostly Ingalls' work.
> Wirth didn't know Kay well enough to recognize him
The popularity and influence of Kay is generally overstated. And not to forget that he received the Turing award much later, and what he published in the seventies was not really the kind of topics Wirth was interested in. At least we have access to all relevant documents today and can check ourselves instead of taking the many tales at face value.
I think the main objective of both the Lilith workstation and the Oberon language were to be practical tools for the kind of graphical user interfaces Kay proposed in his dissertation in 01969 and dedicated much of his PARC research group's effort to advancing. As explained above, Kay's influence is generally acknowledged to be the reason that the PARC's Xerox Alto was capable of running such graphical user interfaces at all.
Oberon's procedure-typed fields came from Modula-2, and I believe that specifically the reason that Modula-2 reintroduced the procedure (function pointer) types that Modula had removed from Pascal was to support the kind of GUI programming that Wirth had been exposed to during his PARC sabbatical in the Mesa group. However, all I have to support that belief is the chronology, the fact that Oberon does in fact use them for that (and, as far as I've seen, only for that), and some vague memories of reading Project Oberon last millennium.
Pascal procedure types could only be passed as subroutine parameters, which enables the use of nested subroutines as closures without risking runtime errors or requiring garbage collection, because the referenced procedure cannot be called after its lexically-enclosing parent has returned. Modula-2 procedure types do not have this restriction, so they can be stored in records; instead, they have the restriction that, like C function pointers, they cannot refer to nested subroutines.
So I think that Smalltalk's (and Kay's) influence on Oberon was very strong indeed, but mediated through its influence on the Mesa group.
If I'm interpreting you correctly, you're saying that my original disagreement was mostly with my misunderstanding of what you meant, and the only thing we actually disagree on is how likely it was that Wirth knew Alan Kay personally, which neither of us is very sure about?
Speaking of vtables, at Kristen Nygaard's 100-year birthday celebration Bjorn Stroustrop also gave a fascinating talk after Alan Kay's, and they had some spicy back-and-forth discussion afterwards! It was a delightful and respectful interplay between very different world views, both direct descendents of Kristen Nygaard's work.
(I'll see if I can find a link to that part of the video, and summarize the transcript...)
Kay's talk runs 3:29 to 4:06, Stroustrup's from 4:06:31, then the discussion.
If you don't like llm generated summaries then you can go watch the entire video yourself, but here goes for people who don't have that time to spare (although I highly recommend it if you do):
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 he says 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.
> 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 nine more years (1978) 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
> 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...
>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.
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...
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.
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.
Here's some stuff about applying Korz to cellular automata (with neighborhood and time dimensions), adventure game parsers and simulators (with direct object, verb, indirect object, location, player dimensions) like Zork -- which is only coincidentally an anagram for Korz, David Ungar assured me. But it's too sweet a coincidents to pass up, because Korz is really useful for elegantly modeling that kind of stuff.
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 caused me to rethink a lot of things. But it's beautifully backwards compatible with what I've been doing with Self.
Korz is "multi dimensional", where functional program...
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.
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).
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.
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.
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.
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.
36 comments
[ 2.5 ms ] story [ 44.8 ms ] threadHere 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
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.
And how the conference's real time speech to text transcription would occasionally lapse into Danish, and say things like "We will eat your hands".
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.
https://crystal-lang.org/
Interestingly, the OO model that Wirth and Gutknecht implemented in the Oberon system corresponds quite well to the message-based approach.
Java implemented the Simula 67 object model according to a 2017 Gosling lecture (as did early C++ and Smalltalk-80 to a significant degree).
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 HOPL you may notice that Kay asked a question, and it is obvious that Wirth didn't know him.
However, I don't think it's particularly adventurous to claim that the Mesa group's GUI was inspired by Smalltalk's, though. They added their own innovations, of course, like the tiled-viewer approach Wirth later used in Oberon, but the basic grammar of windows with titlebars and text in them, noun-verb commands acting on highlighted text selections, scrollbars, menus, and a mouse to point at them, was developed in Smalltalk from its Augment/NLS roots.
Brad Allan Myers wrote his 01980 MIT master's thesis, "Displaying Data Structures for Interactive Debugging"†, about the graphical debugger Incense, which he wrote in Mesa, initially while he was at PARC. By chance this is one of the earliest papers describing the GUIs written in Mesa. What he says about Smalltalk's contribution to GUIs is:
> It was felt that graphics would make the system easier to learn and use [Kay 77]. Smalltalk developed the idea, first proposed in the FLEX system [Kay 69], of using multiple overlapping rectangular regions called windows to extend the available screen space [Goldberg 79]. [...] Smalltalk presents a uniform window interface both to the programs and the user, thereby allowing complex systems to be easy to use (e.g., an animation system [Backer 76] and Thinglab (section 3.6.4)).
"Backer 76" is presumably Ron Baecker's SIGGRAPH paper "A Conversational Extensible System for the Animation of Shaded Images," because there's no "Backer" in his bibliography. Thinglab is the constraint satisfaction system that Alan Borning wrote his 01979 doctoral dissertation on. Goldberg is of course Adele Goldberg from Kay's Learning Research Group."Kay 69" is Alan Kay's doctoral dissertation, "The Reactive Engine".
He credits pointing devices to Sketchpad in 01963, pointing for interactive debugging to someone named Zimmerman in 01967, and the mouse to Bill English in 01967. He shows a screenshot of Teitelman's DLISP UI for debugging Interlisp, which evidently also has highlighted text selections, menus, and overlapping windows with titlebars; Myers describes its windows as "essentially the same as Smalltalk windows", not vice versa.
With respect to the Alto, on p.37, Myers calls out the importance of the Alto's BitBlt microcode for GUIs like the one he mentions; he doesn't mention that it originated in a non-microcoded version written in 01975 by Dan Ingalls, Larry Tesler, Bob Sproull, and Diana Merry, for Smalltalk-72, and that the microcode version was written by Ingalls. At least Ingalls and Merry were in the LRG; I'm not sure about Tesler and Sproull.
On p. 39, we see a screenshot of Mesa's normal windowed debugger, which used overlapping windows at the time — so Cedar's tiled viewers were a later innovation, even within the Mesa group. The windows have titlebars and what appears to be a Smalltalk-style vertical popup menu.
None of the screenshots show scrollbars, but even in Smalltalk they were pop-up at the time to save scarce screen space.
The reason I keep mentioning titlebars and popup menus is that precursor GUI systems like SKETCHPAD, GENESYS, and Augment/NLS didn't have them. They all had pointing devices and windows, and GENESYS even had menus, but not popup menus.
You might reasonably argue that GUIs that ran on the Alto had to use a mouse like Smalltalk did, not because they were modeled on Smalltalk, because that's what the Alto had. But why did the Alto have the mouse? I don't know which ideas were contributed by which contributors, of course. But Kay was one of those contributors.
Shortly before Myers's thesis, in 01979, PARC CSL-79-11, "Alto: A Persona...
That was not my topic.
I was (obviously) talking about the influence of Smalltalk to Oberon, and only that.
And don't forget that the Smalltalk 76 and 80 GUI we know today was mostly Ingalls' work.
> Wirth didn't know Kay well enough to recognize him
The popularity and influence of Kay is generally overstated. And not to forget that he received the Turing award much later, and what he published in the seventies was not really the kind of topics Wirth was interested in. At least we have access to all relevant documents today and can check ourselves instead of taking the many tales at face value.
Oberon's procedure-typed fields came from Modula-2, and I believe that specifically the reason that Modula-2 reintroduced the procedure (function pointer) types that Modula had removed from Pascal was to support the kind of GUI programming that Wirth had been exposed to during his PARC sabbatical in the Mesa group. However, all I have to support that belief is the chronology, the fact that Oberon does in fact use them for that (and, as far as I've seen, only for that), and some vague memories of reading Project Oberon last millennium.
Pascal procedure types could only be passed as subroutine parameters, which enables the use of nested subroutines as closures without risking runtime errors or requiring garbage collection, because the referenced procedure cannot be called after its lexically-enclosing parent has returned. Modula-2 procedure types do not have this restriction, so they can be stored in records; instead, they have the restriction that, like C function pointers, they cannot refer to nested subroutines.
So I think that Smalltalk's (and Kay's) influence on Oberon was very strong indeed, but mediated through its influence on the Mesa group.
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.
(I'll see if I can find a link to that part of the video, and summarize the transcript...)
Kay's talk runs 3:29 to 4:06, Stroustrup's from 4:06:31, then the discussion.
If you don't like llm generated summaries then you can go watch the entire video yourself, but here goes for people who don't have that time to spare (although I highly recommend it if you do):
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 he says 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.
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 nine more years (1978) 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
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...
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.
Self:
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.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
Here's some stuff about applying Korz to cellular automata (with neighborhood and time dimensions), adventure game parsers and simulators (with direct object, verb, indirect object, location, player dimensions) like Zork -- which is only coincidentally an anagram for Korz, David Ungar assured me. But it's too sweet a coincidents to pass up, because Korz is really useful for elegantly modeling that kind of stuff.
https://github.com/SimHacker/moollm/tree/main/designs/korz
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 caused me to rethink a lot of things. But it's beautifully backwards compatible with what I've been doing with Self.
Korz is "multi dimensional", where functional program...
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.
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).
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.
Calculating the limit is easy with Shannon's theorem. Approaching it in practice is hard.
"I can calculate the movement of the stars, but not the madness of the people."
Isaac Newton