Alan Kay: Shannon gave us a way of dealing with noisy channels [video]
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
Alan Kay: Shannon gave us a way of dealing with noisy channels [video]
Unofficial Hacker News client; not affiliated with Y Combinator.
shevy-java · · focus · HN ↗
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.
Rochus · · focus · HN ↗
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).
dang · · focus · HN ↗
That's interesting! what did they do that corresponded better?
Rochus · · focus · HN ↗
kragen · · focus · HN ↗
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 · · focus · HN ↗
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.
kragen · · focus · HN ↗
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 Personal Computer"‡, which lists Lampson but not Kay among its authors, begins its "Acknowledgements" section by saying, "The concept and structure of the Alto are due primarily to Chuck Thacker, Ed McCreight, Butler Lampson, and Alan Kay."
Let's check out Teitelman's 01977 paper about DLISP, "A Display Oriented Programmer's Assistant", PARC CSL-77-3. Fortunately he published it later in the International Journal of Man-Machine Studies§. What does Teitelman say? Where does he assign the credit for the GUI idioms he used in DLISP?
> The idea of a display composed of multiple, overlapping regions called "windows" is attributable to and an essential part of the Smalltalk programming system designed and implemented by the Learning Research Group at Xerox Research Center (1976). In particular, much of the way that windows are used in the system described here was influenced by the work of Dan Ingalis on the Smalltalk user interface. The idea of using the display as a means for allowing the user to retain comprehension of complex program environments, and to monitor several simultaneous tasks, can be found in the work of Dan Swinehart (1974). The use of the "mouse" as a pointing device for selecting portions of a display goes back to the early work on NLS (English, Engelbert & Berman, 1967).
Teitelman was also the main author of Cedar.
How about Lampson, who led Mesa and Cedar? Where did he think the GUI ideas came from? In 01988° he says:
> Yet another ARPA project that had a strong influence on the Alto was Alan Kay's Flex machine, also called the Reactive Engine [21]. [...] Like Engelbart, he attached great importance to a high-quality, rapidly-changing display. He later coined the name "Dynabook" for the tool he envisioned, to capture its dynamic quality, its ubiquity, and its comfortable fit with people [22]. [...]
> The electronic office and the Dynabook, then, were the two threads that led to the Alto system. [...]
> The outstanding exception to these observations is the Smalltalk system, which was built by a tightly knit group that spent a lot of effort developing a consistent style, both for programming and for the user interface. Smalltalk also has a software-implemented virtual memory scheme that considerably relaxes the storage limitations of the Alto. The result is a far more coherent and well-integrated world than can be found in the rest of the Alto system, to the point that several of the Alto's successors modelled their user interfaces on Smalltalk. The price paid for this success was that many Smalltalk applications are too slow [...]
> The Alto system was built by two groups at PARC: the Computer Science Laboratory (CSL), run by Robert Taylor and Jerome Elkind, and the Learning Research Group (LRG), run by Alan Kay. LRG built Smalltalk, and CSL built the hardware and the rest of the system [...]
> Figures 1-3 are typical screen arrangements from three systems. Smalltalk (Fig. 1)' uses overlapping windows without icons, and the position of a window is independent of its function (unless the user manually arranges the windows according to some rule). Smalltalk was the first system to use overlapping windows and pop-up menus. The Bravo editor (Fig. 2) uses one column of tiled windows, with a control window at the top, a message window at the bottom, and a main window for each document being edited, which may be subdivided to look at different parts. Cedar (Fig. 3) uses two tiled columns and rows of icons at the bottom (which can be covered up). This window system is called Viewers; much of its design was derived from Star. The top line or two of a window is a menu. Cedar also allows the entire screen image, called a desktop, to be saved away and replaced by another one; this is switching on a large scale. Markup has a pop-up menu scheme like Smalltalk's, but considerably more elaborate (Fig. 4).
So, in conclusion, I think that my claim that Mesa's GUI was inspired by Smalltalk, far from being adventurous, is on solid ground.
______
† <a href="https://dspace.mit.edu/bitstreams/b8c2f945-251d-4ff2-8baa-82eb0f5a1e3d/download" rel="nofollow">https://dspace.mit.edu/bitstreams/b8c2f945-251d-4ff2-8baa-82...
‡ <a href="https://archive.computerhistory.org/resources/access/text/2024/06/102803961-05-0001-acc.pdf" rel="nofollow">https://archive.computerhistory.org/resources/access/text/20...
§ <a href="https://doi.org/10.1016/S0020-7373(79)80015-2" rel="nofollow">https://doi.org/10.1016/S0020-7373(79)80015-2
° <a href="https://dl.acm.org/doi/abs/10.1145/61975.66921" rel="nofollow">https://dl.acm.org/doi/abs/10.1145/61975.66921 or <a href="http://bwl-website.s3.amazonaws.com/38-AltoSoftware/WebPage.html" rel="nofollow">http://bwl-website.s3.amazonaws.com/38-AltoSoftware/WebPage....
Rochus · · focus · HN ↗
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 (and language) we know today was Ingalls' work, not Kay's.
> 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 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.
kragen · · focus · HN ↗
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 influence on the Mesa group. Certainly Kay's flamboyant and dynamically-typed style, emphasizing recovering from errors rather than preventing them, was not to Wirth's liking.
______
† <a href="https://www.research-collection.ethz.ch/bitstreams/289cc859-94e5-4758-8786-ac05437780a2/download" rel="nofollow">https://www.research-collection.ethz.ch/bitstreams/289cc859-...
‡ <a href="https://scispace.com/pdf/modula-a-language-for-modular-multiprogramming-470x3ovyzt.pdf" rel="nofollow">https://scispace.com/pdf/modula-a-language-for-modular-multi...
Rochus · · focus · HN ↗
kragen · · focus · HN ↗
eterps · · focus · HN ↗
<a href="https://miasap.se/obnc/data-abstraction.html" rel="nofollow">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.
DonHopkins · · focus · HN ↗
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:
<a href="https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0c3b34-90d9-4853-94db-b4b3009fd277&start=12581" rel="nofollow">https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
Bjarne Stroustrup's talk:
<a href="https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0c3b34-90d9-4853-94db-b4b3009fd277&start=14791" rel="nofollow">https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
The discussion afterwards:
<a href="https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0c3b34-90d9-4853-94db-b4b3009fd277&start=17774" rel="nofollow">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.
Rochus · · focus · HN ↗
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
andrekandre · · focus · HN ↗
is it better than before and welcome improvement? yes, but fundamentally conservative compared to what parc was doing with much much less...
DonHopkins · · focus · HN ↗
<a href="https://news.ycombinator.com/item?id=8841428">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.
[...]
andrekandre · · focus · HN ↗
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...