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 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.
You could be right that Wirth didn't know Kay well enough to recognize him. 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 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.
> 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 (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.
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 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.
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.
Currently the title says "Web-based IBM 1620 emulator and IPL-V from 1963" until HN's title policy inevitably vandalizes it to remove the informative part. But, to give further context on IPL-V, IPL (I think actually IPL-IV) was key to some early AI research, but the main reason it's interesting in 02026 is that it's what inspired Lisp. It's a terrible programming language by today's standards, and the manual is a horrible slog, but you can see the seed of almost every programming language popular today in it.
Reading through a CACM publication, I'm struck by how they call the whole system the "IPL Computer" -- they were specifying a bytecode VM. It looks like early IPLs dated to the 1950s, so they'll get a pass for the actual language...
True enough that IPL inspired Lisp (along with Church’s Lambda Calculus), but, to my mind, what is interesting about IPL-* is that the first true AIs and Cognitive Models were written in it/them, esp The Logic Theorist, which was the first heuristic search program, and which actually improved upon proofs by some of the most famous logicians of the time. David Moews has made several of the original IPL Logic Theorist programs run again (although not on this 1620 platfor’. . . Yet!) :: https://news.ycombinator.com/item?id=48116935
I didn't realize IPL lasted that long since indeed it's mentioned by mccarthy as a strong influence.. somehow I always assumed it meant pre-1959.
btw, for people who were there at the time, even considering the bare metal assembly nature of IPL, were people already approaching solutions similarly to lispers in the 60s ? aka dynamic generic lists, tree traversals etc
Yes. All of those were written in IPL well before Lisp. There were a dozen IPL-V implementations across almost every common computer of tat time. (Of course, there weren’t that many common computers! :-)
I haven't used this radio, but I have definitely used a 2.4-kilobit-per-second internet connection productively. Raw TCP/IP with SLIP or PPP will work, and with VJ header compression it works reasonably well. What won't work well is loading a web page with a bunch of images and a megabyte of JavaScript.
ASCII is, as people have pointed out, a 7-bit code, so it can hold only 128 characters. When they added _ and ^ to it in 01967, they had to remove the ← and ↑ characters from ASCII-1963⁂. So there was no space for any of the characters —–“”×÷£°†‡¢§•€, which are absolutely critical even for English. "National variants" of ASCII might allocate space to some of them, or to other characters like ñ which are even more critical to the languages that use them.
⁂ Smalltalk's continued use of ASCII-1963, among other things so that it could use ← as the assignment operator, is the reason that OO programmers got in the habit of using CamelCase, and are still doing so today, despite using a character set containing the underscore, and, typically, programming languages in which underscores are valid characters
> —–“”×÷£°†‡¢§•€, which are absolutely critical even for English
Assuming that second dash is an en-dash, I've not used the majority of those characters even when handwriting. I would say the quotes I handwrite are closer to symmetrical " quotes, I do still use the multiply but I use a slash for divide, I do use the pound symbol and degree symbol, and I've never used the rest. And I'm from england
It's a brilliant hack. It means that when you're dealing with valid UTF-8 strings, various kinds of string relationships enjoy a homomorphism between byte strings and Unicode strings. Specifically, where S and T are Unicode strings and E is the UTF-8 encoding operation:
• E(S concatenated with T) = E(S) concatenated with E(T)†
• S starts with T iff E(S) starts with E(T)
• S ends with T iff E(S) ends with E(T)
• S contains T iff E(T) contains E(T)
This means that, as long as you know your encoded strings don't contain invalid UTF-8, you can do a great deal of your string processing on the byte-encoded form, which is enormously faster than decoding the strings before doing the string processing, permits efficient radix-256 tries, and is much smaller in many common cases.
It also bounds the work you have to do if you're processing a string starting from the end, while certain other encodings require looking back in the string arbitrarily far to figure out how to interpret the bytes you're looking at. This is particularly important for Boyer–Moore string search, but in many cases it's also an express trip to getting your code featured on https://www.tumblr.com/accidentallyquadratic.
In short, yes.
______
†Surprisingly, even this most basic homomorphism is not true of many other character encodings, which may need extra bytes to be inserted in between.
It's helpful to put this number in context, although if the people you're talking to will do anything to avoid using the metric system, that becomes much more difficult.
Fortunately, now we have computers, which are great at unit conversion, so we can cut right through these feeble attempts at obfuscation. In non-medieval units, 10.9 billion gallons per year is 41.3 million cubic meters per year or 1.3 cubic meters per second. The river a few kilometers from me has a discharge of 22000 cubic meters per second (of fresh water dumped into the sea), so Google is the equivalent using 0.006% of the Rio de la Plata. Lake Superior contains 12070 cubic kilometers of water, which is 1.207 × 10¹³ cubic meters, also of fresh water, so Google's current use would dry up Lake Superior in only 290,000 years.
Google is mostly not very close to Lake Superior or the Rio de la Plata; a more relevant river might be the Sacramento River, which drains into the San Francisco Bay where Google was born, and it's much smaller than the Rio de la Plata. Specifically, its average discharge is 797m³/s, so Google is using 0.16% of the discharge of the Sacramento River. (But some of that is at datacenters far from California.)
https://en.wikipedia.org/wiki/Water_in_California#Agricultur... tells us that agriculture in California uses 34.1 million "acre feet" of water per year (Americans will do anything to avoid using the metric system, especially when they're trying to be sneaky). In non-medieval units, that's 42.1 billion cubic meters, and per year, it's 1330 cubic meters per second, almost exactly 1000 times Google's use. Of that, 18% (240 cubic meters per second) is spent on alfalfa, or was in 02014, anyway.
One major difference is that you need fresh water, like the water of the Sacramento River, to irrigate crops, but you can cool data centers with salt water from the ocean. It's less convenient, because there are a variety of annoying things that happen with biofouling and corrosion, but that's what you'd do if hyperscalers scaled up by another factor of 100× so that their water usage became large enough to be environmentally significant.
But that doesn't happen until they have 100× the computing power they have today. So anybody who tells you AI datacenters are a major water user is lying.
reply