EDSAC as early as 1949 had an "initial orders" module. A boot-up ROM. There was a bank of rotary selector switches, to set the octal digits in each ROM word.
David Wheeler (of subroutine fame) figured out the most sensible thing to put in the tiny ROM was a paper tape loader and mini-assembler that loaded the rest of itself from paper tape. So at switch-on the machine would start reading the tape input and run. Programs could be written on the teletype with mnemonics and relative addresses in octal.
It seems a little strange that more advanced later machines like the original PDP-11 from 1970, couldn't "autostart" from ROM like that. You had to toggle in a bootloader.
I think that was because core memory was non-volatile. (EDSAC didn't use core; it had a refreshing DRAM-like delay line memory.) With core, you only had to toggle the bootloader into once and, provided your software didn't accidentally overwrite it, it was still there after a power cycle. So re-toggling in the boot loader was not really that common, despite how much lore surrounds it.
DEC supplied optional boot rom cards for UNIBUS, starting with the BM792, which arrived as a 32 x 16 matrix of diodes. You had to remove some of the diodes by hand to set the boot code.
Later cards used PROMs, and were pretty fancy. The M9312 had 512 words and included some basic CPU diagnostics. Different variants handled boot from disk, paper tape, console, etc, and you had to specify the options you wanted when you bought the card.
Yes that early pdp-11s had core memory, its contents survived power cycling. We'd hand toggle in the bootstrap into high ROM and start it, it would load whatever we were running from paper tape - unless you did something stupid that trashed that high memory you'd get to reuse the bootstrap over and over
Having said that the bootstrap was something like 8 16-bit instructions, a pain but not impossible
DonHopkins comment is marked dead but I’m glad I had show dead on because it’s right in the intersection of what I’m interested in, especially the forth on pdp-7 stuff. (The intersection is my interest in explanations of implementing forth from scratch and about the pdp-7 specifically.)
We had a GT40 at the University of Maryland Vax lab, which we would play Lunar Lander on when the Vax was down.
Scott Swazey gave a great talk at VCF West 2024 about restoring a GT40 and getting Lunar Lander running on it again, and it touches on everything in this thread: core memory, bootloaders, front panel single stepping, light pens, and retyping lost ROMs from listings.
Your point about core surviving power cycles is part of the game (19:44): "because the game has core memory which is nonvolatile, so when I turn off the machine it saves everything, all of the carcasses from the crash landers of all the failed attempts are scattered across the screen. And interestingly enough, if you leave the game running long enough the game will crash, because there's no more memory left for any more carcasses."
It was also arguably the first Easter egg, in 1973 (20:17). Land next to the McDonald's and the astronaut walks over and says "I'll take two cheeseburgers and a Big Mac to go." At a show he crashed into it instead and got "You have destroyed the only McDonald's on the moon", and since core remembers everything, nobody else could find it after that (21:13).
The GT40 came up in a bootloader and pulled programs down the serial line, so no toggling, but debugging it was pure front panel. Hitting line feed crashed the PDP-11, so he single-stepped through the bootloader with a diagnostic card, down to a byte compare of the high byte, which goes through a shift, and found a dead 74194 4-bit shifter (15:50).
A PROM on one of the boards had failed, and no binary of it survived anywhere, so they typed its 256 entries back in from the listings (13:46). His rule number one is "don't trust anybody": he double-checked his friend's careful transcription and found two transposed digits that "would have created a bug so subtle that it would have taken us months to find it" (14:31). The same rule caught the downloaded diagnostics, which had a stray "!" and a newline inserted that made the loader abort (17:15). And on Bitsavers: "we could not have restored it without it" (13:10).
Other highlights: Atari's 1979 Lunar Lander turns out to be a direct copy of the GT40's vector generator, binary rate multipliers and all, with a 6502, ROM and static RAM swapped in for the PDP-11 and its expensive core (5:11). At VCF Midwest the wall power sagged to 90 volts, so he ran it off his camping battery (23:39). And he showed it next to the PDP-11/45 that animated the Death Star trench briefing in Star Wars, with a dueling light pen battle between the two (24:46).
I've been doing the same kind of thing without the soldering iron: bringing Heinz Lemke's 1972 PIXIE/SYMELEC light pen system for the PDP-7 and Type 340 back to life in a browser emulator, from a scanned listing, since no tape survives. Then DEC's own 1964 370 Light Pen Diagnostic, transcribed from a scan that skips from page 5 to page 7, so page 6 had to be rebuilt from how the surviving pages use each of its symbols.
Scott's rule number one turned out to be mine too. Every bug falls into one of three kinds: ours (the emulator got it wrong), the transcription's (the listing was misread off the scan), and 1972's (the listing itself is wrong, and the emulator should faithfully reproduce the mistake). The first one was a truncated literal pool. The conversion stopped at word 11741, so every (JMP INT literal read as 0, and the machine initialized itself into a wall. So far, every bug had its answer on paper before anyone went looking. The emulator's job is to run the listing until it disagrees with itself, and then to show where.
In 1972 the PDP-7 was the small one. It hung off Cambridge's Titan (an Atlas 2 that filled a room and ran the university) as a satellite, phoning home over Neil Wiseman's custom link to store and retrieve drawings in the Titan filestore.
The emulator inverts that: tiny-titan is the whole of Titan, as much of it as PIXIE ever saw, in one TypeScript file, serving its emulated satellite from inside a browser tab. It implements only what the one surviving caller ever dialed, and SYMELEC's unmodified link code runs against it.
Press the "DEMO" button and it will make a goofy child's drawing with the virtual light pen. I plan to ask Claude to make a new demo by trying to draw a pelican riding a bicycle.
Enable the MEMORY panel's "SOURCE" + "FOLLOW PC" mode, then slow the emulator down with the slider, to see the PDP-7 assembly source code it's executing (from the OCR of the scan of 128 pages of line printer output).
You can also pick "LIGHT PEN TEST (1964)" from the menu and press "DEMO", or pick "DUEL (1968)" and play spacewar for two, DECUS 7-40, loaded from paper tape through the RIM loader, the PDP-7's version of your bootstrap.
And I made a non-graphical "HILO (2026)" number guessing game and a "LUNAR LANDER (2026)" game to test out the TTY simulator. The lander is in the spirit of the turn-based original Scott describes (1:52), before the GT40 made it real time: "YOU ARE 500 FEET UP, FALLING AT 50 FT/S, WITH 60 UNITS OF FUEL."
PDP-7 Unix is coming soon. Warren Toomey, Phil Budne, Tom Everett, Sebastian Rasmussen, Robert Swierczek and friends did this kind of restoration on a much bigger scale with the pdp7-unix project. Starting in 2016 they typed in Ken Thompson's 1969-70 PDP-7 Unix from Norman Wilson's scans of the only surviving printouts, wrote a cross-assembler (as7) and a user-mode simulator, and got the kernel booting to a shell with a working filesystem.
In 2019 a second notebook of missing sources turned up and was scanned and typed in too, and in January 2020 it ran on a real PDP-7 at the Living Computer Museum. It even has moo, the bulls-and-cows number guessing game, a 1970 cousin of my HILO.
Their as7 was the precedent for my own assembler, which can run in the browser and produce symbol tables and source maps, the way a TypeScript to JavaScript compiler does. That's what drives the Memory panel's Source + Follow PC mode, and it's the groundwork for live coding:
To run Unix, the cabinet needs what its SIMH script asks for: 8K with EAE, the teletype, the clock, and the RB09 fixed-head disk. It loads boot.rim, and the bootstrap reads the system from disk. So the new part is porting SIMH's RB09.
B comes with it: the interpreter (bi.s) and loader (bl.s) survive in the scans, and Robert Swierczek rebuilt the missing compiler in 2016. There's no C on the PDP-7. C came later on the PDP-11, and B was Thompson's cut-down BCPL.
And a couple days ago Mitch Bradley wrote a PDP-7 FORTH for it, including a Turtle Graphics package, which I'll integrate soon too! That's the other half of live coding. My assembler is TypeScript running on the emulator host, but Forth will run on the PDP-7 itself: you type new definitions at the emulated teletype, and the turtle draws them on the 340, interactively, in a language living inside the machine.
B compiles to threaded code too, so the cabinet will have two threaded interpreters, 1970 and 2026, running side by side!
Fittingly for a thread about whether the ENIAC had a BIOS: Mitch is the one who wrote Open Firmware, the Forth-based boot firmware in Sun workstations, PowerPC Macs, and the OLPC XO. So the PDP-7 is getting its Forth from the same man who invented Open Firmware to put Forth in the BIOS.
Mitch's threading technique is a new one, as far as we can tell, small fast and elegant on the PDP-7. NEXT is three instructions, and the core of it is XCT I 10: it bumps an auto-index register and executes the thread cell it points at, so every cell in a compiled definition is itself a PDP-7 instruction, and its opcode is its type. CAL enters a colon word, JMP runs a primitive, and LAC or LAW pushes a constant or variable.
That makes location 10 a second program counter, running a virtual machine whose instruction set is the PDP-7's own. It doesn't fit Anton Ertl's threading taxonomy. For publication, "XCT Threading". For the T-shirt, "Indirectly Direct Threading".
The EDSAC's "boot ROM" consisted of a bank of large electro-meachanical "uniselector" rotary switches, hardwired to contain the 31 instructions ("initial orders") of the tape loader.
Subsequent computers could have followed this "electro-mechanical ROM" approach, but I suppose it was rather bulky and inconvenient to change.
You can see what the uniselectors looked like here at 8:50
Of course programmable ROM chips would have to wait, so in the meantime the alternatives were either the toggle-it-in approach (still also used by the 1974 MITS Altair 8800), or other more compact types of handmade/hardcoded physical ROM such as magnetic core or diode matrices.
Typically daily. They were used for troubleshooting and repairing military avionics. They survived decades onboard ships, etc. They got temperamental in their later years, but we kept them going.
If you have any interest you can search up the (sparse) information on the AN/USM-484 Hybrid Test Set (or System).
> It seems a little strange that more advanced later machines like the original PDP-11 from 1970, couldn't "autostart" from ROM like that.
Because the PDPs had magnetic core memory, so the bootloader, once toggled in, stayed in memory. The OS took care not to overwrite it.
And in normal operation you wouldn't have to use it at all, you just switched on your PDP, and it was in the same state as when you switched it off.
Also, bootloaders were short (because peripherals had lots of intelligence); toggling one in was a matter of minutes.
> I think that was because core memory was non-volatile.
Exactly. And when RAM cards were available to replace core (very late in the lifecycle of the minis), the RAM was battery backed to simulate that behaviour.
In Fred Hoyle’s science fiction novel, The Black Cloud, there is a computer in an early chapter that is clearly inspired by EDSAC. When they run a program on it, the process is just what you describe - they load a paper tape in through the tape reader, which Hoyle describes in detail.
I first read that book before I knew that in British English a vacuum tube is called a valve (from thermionic valve and which makes more sense than the American term, I think), so I was confused by the line about how warm the room was due to all of the valves!
Valve gear is particularly full of transatlantic differences, as well as valves vs tubes in many cases the same specific valves can have different names depending on the side of the Atlantic you're on such as EL84 vs 6BQ5. Your high voltage line is called HT in British but B+ in American, while what we'd call an anode in the UK is more commonly called a plate in the US. I'm not sure if it's as fixed but I've usually heard Americans calling what I'd call the heater the filament as well.
While 'valve' makes more sense from the point of view of what it does, 'tube' makes more sense from the point of view of what it is I think.
We called them thermionic valves too, just the terminology shifted a bit over time. We also called capacitors "condensers". Both were references to steam powered control systems.
They say the term did not originate from the steam condenser. Quite the opposite, it became deprecated because of the ambiguous meaning of steam condenser.
What I'm reading (and was told by grey beards) is that it originated as a metaphor to steam condensers, and was deprecated because the two different systems having the same term led to ambiguities. Including the fact that they do have different properties, such as steam condensers are able to absorb steam pressure, but can't actually return the steam when the input pressure drops back down (since it's already been condensed back into water).
I just met John Robson at a meeting who was one of the first people in the world to run a frequency domain analysis on time series data - on EDSAC! He spent a long time explaining the precise algorithms to me - amazing!
Processes like this are where "boot" comes from. The machine was pulling itself up by its bootstraps. The ROM was sometimes called the "bootstrap loader."
I had Claude Opus disassemble the CDC 6600 dead start panel. The hard part was finding a better image of the switches so the vision could read the bits.¹
The content isn't very interesting, and Claude's comments aren't very detailed. Not bad for 2 minutes of work about a 62 year old computer though. Look out Ken Shirriff, AI is coming for you.²
Addr Octal Instruction Meaning
0001 7512 DCN 12 Disconnect channel 12 (put it in a known idle state)
0002 7712 FNC 12, 4000? Send function code to channel 12's device
0003 4000? └ function code (last bit unclear: 4000 or 4001)
0004 7712 FNC 12, 0001 Send another function code
0005 0001 └ function code
0006 7712 FNC 12, 1500? Send a third function code
0007 1500? └ function code (least certain row)
0010 2000 LDC 0160? Load A with a word count
0011 0160? └ the count
0012 7412 ACN 12 Activate channel 12
0013 7112 IAM 12, 0015 Read A words from channel 12 into memory starting at 0015
0014 0015 └ destination address
I'm pretty sure Kay's not quite correct about the Eniac not being a stored program computer. In it's original form it obviously was not, as it had to physically reconfigured to solve different problems. However, after the war it was rebuilt to operate like any other stored program (von Neumann architecture) computer, as it was the first recipient of the design philosophy seen in the EDVAC report. It operated in that mode from '48 to '55, when it was decommissioned.
ENIAC in Action: Making and Remaking the Modern Computer is an excellent summary of the initial design and redesign of the Eniac.
Apparently Eckert (John Mauchly and J. Presper Eckert designed the ENIAC) claimed that von Neumann basically stole their idea of the stored program and that they had already came up with the idea and he just took it and ran with it as if it was his
> And John Von Neumann? He came and looked at our stuff and went back to Princeton and wrote a long document about the principles. He gets a lot of credit but the inventions were ours. Someday I’ll write a book on who really invented the computer.
>Johnny learned instantly, of course, as was his nature. But he chose to refer to the modules we had described as “organs” and to substitute hypothetical “neurons” for hypothetical vacuum tubes or other devices which could perform logical functions. It was clear that Johnny was rephrasing our logic, but it was still the SAME logic. Also, he was introducing different but equivalent symbols; nevertheless the devices still did the same things. Johnny did NOT alter the fundamental concepts which we had already formulated for the EDVAC.
>Small wonder, then, that computer history gave von Neumann the credit. Eckert and I, who left the Univ. of Penna. In 1946, no longer had access to the documents which might have helped to show “who did what, when.” But after many years, litigation has unearthed some of those documents, and historians can read what was once classified. But, even after declassification, those reports are not accessible to most people, since they were reproduced in such small quantities. Nevertheless, we hope that more historians will refer to them.
Eckert and Mauchly weren't reliable narrators of the history of their work, given how much they needed to claim in order to get the patents that were later invalidated. They claimed quite a few things that were later disproven in court or through historical study. At the least, Eniac was designed by the team at the Moore School.
von Neumann's "First Draft of a Report on the EDVAC" was both a summary of discussions by the Eniac team as well as von Neumann's own original work proving and expanding on various aspects of those discussions. It's called the von Neumann architecture because he was the author of the seminal paper, not because he laid any particular claim to the ideas. Eckert and Mauchly were mostly upset about the paper's existence, regardless of author, because it made it impossible for them to patent the stored program idea in general.
Story as old as time: corporate vs academia working towards very different goals and with different incentives, short term profit vs publication. In very rare cases, the scholar gets the rewards.
>Eckert and Mauchly weren't reliable narrators of the history of their work, given how much they needed to claim in order to get the patents
The existence of an incentive doesn't predestine the outcome.
Von Neumann was the one who inappropriately failed to credit them in "First draft...". Goldstine was the one who distributed it knowing they were legally unable to publish themselves. These are the unethical actions that clouded the record. Between these two sides, I'll be trusting Eckert and Mauchly's account.
>They claimed quite a few things that were later disproven in court or through historical study.
Ehh.. I'm curious which things you're referring to. The patent trial was hogwash, so depending on the topic, 'disproven in court' could mean literally nothing. I hope you're not just an Atanasoff crank...?
Saying "like any other stored program computer" makes it sound like there were a bunch of them, but as I understand it there was really only ONE up and running at that time in 1948 - IBM's SSEC. The stored program EDVAC, whose architecture Von Neumann had formalized, was still not yet running, and Von Neumann personally advised on adapting ENIAC to this mode of operation.
As I understand it, even after adaptation to "stored program" mode, the program was still configured rather than loaded and stored, but now configuration was done using the function table dials (essentially a dedicated dial for each program step) rather than patch cords, and was a lot more convenient. Punched cards could be used for reading/writing data, but not for programs.
It seems there was no BIOS because I/O was so primitive. Per configuration a punched card would be read into the "constant transmitter" unit, then one of the read numbers could be copied into one of the 20 accumulators. Or you could do the same in reverse to output data from the accumulators.
Right. The patent refers to "semi-permanent cable connections" between card reader, registers, and printer. Basically, you could load and dump parts of memory, in decimal. The registers were all decimal, and so were IBM tabulators, so the interface is mostly a set of relays. No sign of format conversion or alphabetic capability.
Alan Kay answering questions on Quora. What a cool gift to the world!
This is one of the thing we lose as more and more of the conversations turn to people privately asking LLMs things, who do their best to scrape out answers from the existing info or make up a best guess. People are losing the ability to ask experts with real, unique knowledge and then share that knowledge with humanity.
Somewhat tangential, I've watched a bunch of videos on YouTube from @deramp5113 about the Altair 8800 and other early microcomputers, which feature a similar set of front panel switches for dialing in your initial program. One thing that's interesting to me, as someone who learned computing in the late 90s, is how much is expressed in octal instead of hex on these early computers.
As shown in the linked picture, the byte pairs are divided into [4 groups of 3] instead of [3 groups of 4] switches, which I would find more comfortable as a hex-reader. I believe, maybe someone can confirm, that octal notation is easier to translate into bits than hex is. We just don't do either of those things terribly often anymore, so octal has mostly fallen out of favor, perhaps because it groups less nicely into multiples of 8.
Nowadays I almost never think in octal. The only time it seems to come up is for Unix file mode switches (chmod etc), which likely date to this time when octal was more common.
I have restored a Data General MicroNOVA that also uses octal. It has an emulated front panel over serial and uses octal in multi-digit commands like specifying which address you want to boot from, "33L" to book from an MFM disk controller for example. That is probably a legacy carryover from the NOVA 3 and earlier where you would be able to input the same thing into the front panel switches.
Fundamentally I wouldn't say octal is fundamentally easier to interpret other than hex because it's just half as many digits. The shorthand things about octal used in unix you mentioned all still technically apply to hex as well. The only really tricky part is where it becomes letters and you have to think if D or E is the odd value with the first bit set. If you were doing hex all day though, the 6 hex letter patterns would be pretty easy to memorize.
Personally I would say for front panel systems specifically was just about physical space for the switches. If you look up CPU trainers for something like Intel 8080 in the Altair 8800, you'll see it uses a hex keypad. Multiple 16b values would have been a lot harder to fit in single bit switches.
Octal allowed used of simpler numeric displays (numeric nixie tubes or 7-segment displays) as you only needed digits and not ABCDEF that you'd need for hex notation.
On a PDP-11 there were 8 registers, R0-R7, with R6 being the (default) stack pointer and R7 being the program counter.
There were 8 address modes for each register.
So a src/dst instruction used up 12 bits for the src/dst+modes, a single register instruction used 6 bits.
You could load the registers directly at addresses 177770 through 177777 on the front panel. So if your program was 5 words long, you could load that into registers R0-R4, then load R7 with the address 177770 and execute.
Even into the "modern" microprocessor era, a lot of them had no BIOS to speak of they just loaded the first instruction (or a pointer to it) from a standard address (e.g. 0000) and started running.
I don't remember any CP/M system with the BIOS part in ROM (and BDOS loaded from disk). It would be possible, of course, but every subsequent version of CP/M for that machine would need to be able to work with the "frozen" BIOS, and I'm not sure CP/M was designed thinking of mixing BIOS/BDOS versions.
Saying that, I think the Epson PX-4 and PX-8 had CP/M in ROM.
Having said that, Alan Kay has seen things we people wouldn't believe, so, if he says it happened, I'm betting on him.
Man I didn't even realize that Quora was still around, let alone prominent people still answering questions on it. I deprioritized it in my Kagi searches months ago and even then I didn't notice that much of a change in the quality of my searches.
Quora is such a gamble when it comes to accurate or relevant results. Either you get something incredibly insightful from someone with real experience or you get misinformation and stupid opinions. It's really only slightly helpful when I'm looking for subjective opinions or a personal perspective on some topic. It's very much a negative result when I'm looking for factual, verifiable information.
Some older people are on it, apparently, and some good experts among them too. Older folks often don't keep up with platform fashion. Some good older scientists even use academia.edu or researchgate...
Of course I'd prefer if he answered on a StackExchange site, tho I heard those are in decline too, but at least not enshittified like Quora.
Me too. It's a shame he doesn't post here more often, because Quora's thoroughly enshitified user interface is so spectacularly hard to use and intentionally, aggressively, darkly patterned.
Quora has at least three different ways of folding content, and each one needs its own click: answers truncated at "(more)", comments collapsed behind "View comments", and nested replies collapsed again behind "View more replies", yet tellingly no "Expand all" button.
For logged-out readers there's also a login wall that blurs the rest of the page. The whole thing is fragile. Click the wrong thing, hit Back, or refresh, and it forgets everything you expanded and where you were scrolled, and dumps you back into a feed of unrelated "related" answers.
Worst of all, there's no way to link to a comment so that it restores your viewpoint and opens everything back up. The link lands on a page with everything folded again, and whoever you sent it to has to redo all the clicking to find what you meant. While HN has one kind of fold, [–], and every comment has a permanent item id that takes you straight to it, expanded and in context.
Maybe his last long visit here didn't leave him with a good impression of the "civilized behavior" of Hacker News. hota_mazi aggressively argued that Alan didn't coin the term "object-oriented," and then, when challenged, posted a bunch of unsubstantiated disrespectful misinformation.
Worse, hota_mazi did it while attacking Alan's friend Joe Armstrong in Joe's own memorial thread, days after Joe died, when Joe could no longer answer for himself. Alan exasperatedly asked him twice to do his homework.
Joe Armstrong died on April 20, 2019. The next day his essay "Why OO Sucks" was posted here, and the thread became a place to remember him.
> Actually, this is not really about if OO sucks, but to reflect on one of the articles Joe Armstrong wrote. Joe passed away two days ago.
oldpond wrote:
> Joe was truly one of the greats. [...] Thank, Joe.
(Not everyone was so kind. Someone posted just "Why Joe Armstrong sucks"; it's [dead].)
The top comment, by rhblake, quoted Joe's own 2010 explanation of why he changed his mind about OO:
> "Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". [...] Alan Kay himself wrote this famous thing and said "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages"."
That's Joe, in his own words, crediting his supervisor and Alan. hota_mazi replied to it, two days after Joe's death, by accusing both men of opportunism [log in and set showdead=true to view flagged posts]:
> Both Alan Kay and Joe Armstrong struck me as having had the same attitude of trying to capitalize on the topic of object oriented programming, failing to recognize its importance, and then later trying to appropriate it by redefining it.
> Not the best moment of these otherwise two bright minds.
skndr asked:
> Didn't Alan Kay coin the term "object oriented"?
Before Alan had even joined the thread, hota_mazi dismissed Alan's own account of his own work:
> That's what he claims but there's zero evidence besides his own word.
lliamander asked the obvious question:
> Well, how large is the pool of other possible candidates? Wouldn't someone from that time period (say the Simula folks, or another PARC employee) challenge that assertion?
So did DonaldPShimoda:
> Ah, so you have evidence that it was somebody else?
hota_mazi admitted he had none:
> I don't, but that's not how the burden of proof works.
DonaldPShimoda, who works in programming language research, set him straight:
> Every source I've ever come across on this topic (and I work in PL research) points to Kay as the originator of the term "object-oriented" in relation to programming. No exceptions.
> You are now making an affirmative assertion that Alan Kay did not coin the term. The burden of proof is on you, not him.
hota_mazi demanded the sources while still rejecting the claim while hypocritically not doing any homework or providing any sources to his misinformation:
> Link these sources, then! Even someone who recently interviewed him and researched the subject for months confessed he could never corroborate that claim.
> You make the claim he coined the term, the burden of proof is on you.
> Until you do, it's perfectly reasonable and intellectually honest to reject that claim.
> I didn't coin the term "object" -- and I shouldn't have used it in 1966 when I did coin the term "object-oriented programming" flippantly in response to the question "what are you working on?".
And he replied directly to hota_mazi's first comment:
> This is way off. Please try to do more homework.
hota_mazi wasn't done with Joe. lliamander had challenged him:
> I'd be really interested to hear what you think they missed, because I find your claim to be surprising and a bit preposterous.
So, in the thread where people were mourning Joe, hota_mazi explained that Joe had been a bandwagon-chaser who bent the definition of OOP to cash in on its success:
> Armstrong wrote the very famous "Why OO sucks" and then a decade or two later, changed his mind when he saw how successful OO was, and then tried to retrofit Erlang into an OO language. Not by changing Erlang, but by twisting the definition of OOP so that Erlang would fit it.
That contradicts Joe's own explanation, quoted at the top of the same thread, and Joe was no longer alive to correct it. revvx did it for him:
> Joe Armstrong was criticizing C++-style OOP when he wrote his critique. After he learned more about Alan Kay's view on OOP, he decided that Erlang is closer to Alan Kay's OOP and he approves that specific flavor of OOP. He didn't change his stance based on popularity.
And Alan, two days after losing his friend, was left defending Joe's character:
> That isn't what happened at all (see the rebuttal by revvx). Joe was a great guy and also a great systems thinker. And he was the last person to worry about "bandwagons" (quite the opposite!)
hota_mazi doubled down, arguing that since mainstream OOP ended up meaning something else, Alan's and Joe's view didn't count:
> He doesn't even mention C++ in his essay [1], but regardless, the C++ OOP is pretty much the mainstream OOP, which we still use today in Java, Kotlin, C#, etc...
> And... no, the change in mindset about OOP never happened. Kay and Armstrong's view of OOP never took on. Today, OOP is still not seen as message passing and mostly seen as polymorphism, parametric typing, classes/traits/interfaces, and encapsulation. The complete opposite of what Erlang is.
> I'm the one mentioning C++. To anyone familiar with both styles, Joe Armstrong is clearly not talking about Smalltalk-style OOP in his essay, he's talking about C++/Java/etc style. And later on he only praised Smalltalk-style OOP.
On top of that, people doubted it was really Alan at all. hannofcart asked:
> Are you the Alan Kay. Is there any way we can verify this is you? The HN user account seems to have a very low "karma" rating, so one can't help but be more suspicious.
Alan answered:
> I'm the "computing Alan Kay" from the ARPA/Parc research community (there's a clarinettist, a judge, a wrestler, etc.) I did create a new account for these replies (I used my old ARPA login name).
> I'm a little skeptical. [...] A one-day-old HN account claiming to belong to one of the most important people in CS from the past 50 years seems a little suspicious haha.
That's what Alan was answering with his weary verdict:
> An interesting and unfortunately true commentary on the lack of civilized behavior using technology that actually required a fair amount of effort -- and civilized behavior -- to invent in the first place.
(To DonaldPShimoda's credit, he apologized, and Alan graciously reminisced about crawling over Simula machine code listings unrolled down the hallways of the Merrill Engineering Building.)
A week later Alan was still correcting the record, when someone misquoted him:
> Actually, I said: "I invented the term "object-oriented", and I didn't have C++ in mind". In other comments here I explain why "object-oriented" was a too quick and bad choice for what I thought I was doing ...
Many people unfortunately completely conflate one or more of these terms to generically mean "ROM-resident code that enables a device to self-bootstrap": BIOS, UEFI, firmware, bootloader, boot ROM, boot flash, IPL, (boot) monitor, microcode
Kristen Nygaard would have turned 100 last month, so here's a history of object-oriented programming as a series of subtractions, each one taking away something the previous generation thought was essential.
Nygaard and Ole-Johan Dahl built Simula at the Norwegian Computing Center to simulate things like ships moving through harbors and customers waiting in queues. Simula I (1962-65) was a simulation language. Simula 67 generalized it and gave us nearly the whole kit: classes, objects, subclasses, virtual procedures (dynamic dispatch), and coroutines, so each object could run its own little process. They shared the Turing Award for it in 2001. Nygaard went on to design BETA with Ole Lehrmann Madsen and Birger Møller-Pedersen, and to pioneer participatory design, working with trade unions on how workers should have a say in the systems imposed on them. He never thought of programming as separate from the people it was for.
>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, and 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.
Simula inspired two very different children.
Alan Kay saw Simula I and Sketchpad in the same week in grad school at Utah in 1966, and it gave him the idea that everything could be like a little computer: protected, self-contained processes that only communicate by sending messages. When someone asked what he was working on, he flippantly answered "object-oriented programming", and the name stuck. Smalltalk kept Simula's classes, but the big idea was messaging. As he put it in 2003: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
Bjarne Stroustrup used Simula for his PhD simulations at Cambridge, loved how it let him structure programs, and found the implementation far too slow. So in 1979 he bolted Simula's classes onto C, and "C with Classes" became C++. It kept the classes and the static types, and dropped the messaging and most of the late binding, so the compiler could make it fast.
Alan has been drawing the contrast ever since. In his own words, correcting someone here who misquoted him: "I invented the term 'object-oriented', and I didn't have C++ in mind."
Then David Ungar and Randy Smith took something away. Self removed the classes. Only objects remain, and they inherit directly from other objects through parent slots. An object can have several parents, so you get multiple inheritance for free, and since parents are just slots, you can change them at runtime. There's no assignment syntax either: variables are slots you send messages to. The title of the 1987 paper says what it was about: "Self: The Power of Simplicity."
A language that dynamic was supposed to be too slow to use, so Craig Chambers, Urs Hölzle and Ungar invented the techniques that made it fast anyway: maps (hidden classes), customization, polymorphic inline caches, adaptive recompilation, and deoptimization (pessimization) so you could still debug optimized code.
That work went through Animorphic's Strongtalk to Sun and became Java's HotSpot, and Lars Bak carried it on into V8 for JavaScript. JavaScript's design credited Self, but missed the point by subtracting the one thing Self was about: simplicity. Brendan Eich never understood simplicity, or even the $1000 question: equality.
Anders Hejlsberg, who designed Turbo Pascal, Delphi, C#, and then TypeScript to clean up after JavaScript, at a 2019 panel with Guido van Rossum, James Gosling and Larry Wall:
>"My favorite is always the billion dollar mistake [Tony Hoare's name for null] of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
>"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
Self's ideas (speculate on what you've observed, guard the assumption, bail out when it breaks) are how everybody's JIT works now, from .NET's tiered compilation for C# to LuaJIT's traces. Separately, Self's prototypes became JavaScript's object model, and Lua's metatables follow the same prototype approach.
The irony is that Self's compiler was the reward for simplicity, and it became the subsidy and license for complexity. The same techniques now make Java, JavaScript, C# and Lua run fast no matter how complicated their object models get, which flies in the face of the key word Ungar and Smith put in the title: simplicity.
Then Ungar, Harold Ossher and Doug Kimelman at IBM took the next thing away. Korz removed the objects and kept the slots. A program is a flat sea of slots that belong to nothing, each guarded on named dimensions, and a message is sent in a context of dimension bindings that flows implicitly down the call chain. The receiver becomes one ordinary dimension (rcvr) among any number. Group the slots by rcvr and you see ordinary objects again, but that's just one view, and no view is the privileged one. Once again the title leads with the point: "Korz: Simple, Symmetric, Subjective, Context-Oriented Programming" (Onward! 2014).
The name comes from Alfred Korzybski, whose Science and Sanity (1933) argued how much perspective shapes perception, and who gave us "the map is not the territory." It's a fitting name, because Self's implementation was built on maps: hidden structures describing the layout of objects that share a shape, which the programmer never sees, while the objects themselves are the territory. (V8 still calls its hidden classes Maps.) In Korz it's the other way around. The slots are the territory, and objects are just maps of it, one of many possible projections. Self hid its maps behind the objects, and Korz shows the objects were maps all along.
Look at that title and you can see what happened in between. When the receiver is the only thing allowed to vary behavior, everything else that needs to vary behavior has to start its own movement. Subject-oriented programming (Harrison and Ossher, 1993) varies by who is looking. Aspect-oriented programming (Kiczales et al. at PARC, 1997) varies by which concern cuts across. Context-oriented programming (Hirschfeld, Costanza and Nierstrasz, around 2005-2008) varies by what situation you're in. Then there's feature-oriented, role-oriented, and the rest.
Each one takes the same mechanism and freezes a different dimension into its name. Ossher co-invented subject-oriented programming, and with Korz he and his colleagues argued that all of these are projections of one smaller mechanism: dispatch on any number of named dimensions.
So I propose continuing the tradition by removing the next thing that complicates matters: the modifier. Object-Oriented Programming, minus the Object guard, is just Oriented Programming. Behavior is chosen by where you stand along whatever dimensions you've declared, and none of them is privileged in the name. How it's oriented matters less than whether it's oriented.
Oriented languages have one declared bearing that everything else follows, whatever that bearing is: Smalltalk and Self (objects receiving messages), CLOS (generic functions dispatching on all their arguments, with method combination), Korz (slots, guards and dimensions), Erlang (isolated processes sending messages, which is why Joe Armstrong concluded it might be the only object-oriented language), Lisp (lists), Forth (the stack), APL (arrays), Tcl (strings), Lua (tables), Prolog, Datalog and SQL (relations), and Unix (files and pipes).
The corollary is Disoriented Programming: a language that names one dimension in its paradigm, while its real behavior depends on a dozen unstated ones scattered across unrelated mechanisms. It comes in two flavors, naive and diabolical.
The classic naive case is PHP. It was never designed so much as accreted, one "next logical step" at a time, with open contempt for computer science and for design itself. Rasmus Lerdorf said as much: "I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." and "We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." The result has no bearing at all: functions, classes, traits, magic methods, superglobals, variable variables, and a standard library whose argument order you have to look up every time.
C++ is disoriented in many of the same ways, but on purpose. Every mechanism was deliberately chosen, carefully argued, and added on the principle that you don't pay for what you don't use. The upshot is that the behavior of a single call can depend on classes, templates, overloading, argument-dependent lookup, virtual versus non-virtual, implicit conversions, macros and friends, all interacting exactly as specified. That's diabolical, and Stroustrup knew it: "Within C++, there is a much smaller and cleaner language struggling to get out." It's still not what Alan had in mind.
Most other mainstream languages drift somewhere between those two poles. In enterprise Java, annotations, reflection, dependency injection and aspect weavers decide more than the classes do. JavaScript has prototypes underneath, class syntax on top, and several different rules for what "this" means. C# and Scala keep adding features instead of taking them away.
Disoriented doesn't mean useless. Those dimensions of variation are real and necessary, which is exactly why all those mechanisms got bolted on. It's disoriented to pretend there's only one direction on the compass, and hide all the others in places the language won't admit are part of the model.
I've written this up at more length as a Chip Morningstar-style "How to Deconstruct Almost Anything" deconstruction: declassification, then deobjectification, then what's left:
>Marvin Minsky saw the same enthronement in psychology. In a 1982 essay he demolished what he called the Single Agent theory -- the folk idea of "a little person deep down there" who does the real mental work -- and concluded: "Self, itself, is not a single thing." He wrote that five years before Self the language shipped, and it reads as a prophecy of what came next.
That leaves an open question for David Ungar: having demoted the receiver, would he go the rest of the way, drop the modifier, and call the whole genre Oriented Programming?
www.quora.com
Performing security verification
This website uses a security service to protect against malicious bots. This page is displayed while the website verifies you are not a bot.
Funny. Just tested that because I'm always told: too complicated, nothing will work!
And got no check at all.
Edit: Maybe it depends on where you come from, or what they think you come from. Or using VPN. Wrong browser with insufficient base for uBo. uBo configured wrong. (Not?) using an ad-blocking DNS-Server, so that shit doesn't even make it to your local uBo?
Tested from Hamburg, Germany via private tunnel from my home in Colorado, which also works.
Threat intel of the IP or network you're coming from matter as much as anything else. FirefoxLinux on a clean IP can access places ChromeWindows on a dirty high-risk IP cannot.
EDSAC as early as 1949 had an "initial orders" module. A boot-up ROM. There was a bank of rotary selector switches, to set the octal digits in each ROM word.
David Wheeler (of subroutine fame) figured out the most sensible thing to put in the tiny ROM was a paper tape loader and mini-assembler that loaded the rest of itself from paper tape. So at switch-on the machine would start reading the tape input and run. Programs could be written on the teletype with mnemonics and relative addresses in octal.
It seems a little strange that more advanced later machines like the original PDP-11 from 1970, couldn't "autostart" from ROM like that. You had to toggle in a bootloader.
I think that was because core memory was non-volatile. (EDSAC didn't use core; it had a refreshing DRAM-like delay line memory.) With core, you only had to toggle the bootloader into once and, provided your software didn't accidentally overwrite it, it was still there after a power cycle. So re-toggling in the boot loader was not really that common, despite how much lore surrounds it.
DEC supplied optional boot rom cards for UNIBUS, starting with the BM792, which arrived as a 32 x 16 matrix of diodes. You had to remove some of the diodes by hand to set the boot code.
Later cards used PROMs, and were pretty fancy. The M9312 had 512 words and included some basic CPU diagnostics. Different variants handled boot from disk, paper tape, console, etc, and you had to specify the options you wanted when you bought the card.
Yes that early pdp-11s had core memory, its contents survived power cycling. We'd hand toggle in the bootstrap into high ROM and start it, it would load whatever we were running from paper tape - unless you did something stupid that trashed that high memory you'd get to reuse the bootstrap over and over
Having said that the bootstrap was something like 8 16-bit instructions, a pain but not impossible
DonHopkins comment is marked dead but I’m glad I had show dead on because it’s right in the intersection of what I’m interested in, especially the forth on pdp-7 stuff. (The intersection is my interest in explanations of implementing forth from scratch and about the pdp-7 specifically.)
I have no idea why somebody flagged his last few comments or why "vouch" doesn't work. Frustrating.
The first machine I ever played with was a PDP-11/10 with 16K of "core" and 3 ASR-33s & a VT52 connected by 20mA current loop serial.
Bootstrap was a small set of octal instructions on a piece of paper stuck to the front panel.
That was enough to load the "absolute loader" from paper tape on one of the ASR-33s, which then loaded blocks of BASIC from paper tape.
It was a "multi-user" BASIC that dropped string functions (except CHR$()) in exchange for allowing 3 users.
We had a GT40 at the University of Maryland Vax lab, which we would play Lunar Lander on when the Vax was down.
Scott Swazey gave a great talk at VCF West 2024 about restoring a GT40 and getting Lunar Lander running on it again, and it touches on everything in this thread: core memory, bootloaders, front panel single stepping, light pens, and retyping lost ROMs from listings.
https://www.youtube.com/watch?v=G6h6r6MGWyI
Your point about core surviving power cycles is part of the game (19:44): "because the game has core memory which is nonvolatile, so when I turn off the machine it saves everything, all of the carcasses from the crash landers of all the failed attempts are scattered across the screen. And interestingly enough, if you leave the game running long enough the game will crash, because there's no more memory left for any more carcasses."
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=1184s
It was also arguably the first Easter egg, in 1973 (20:17). Land next to the McDonald's and the astronaut walks over and says "I'll take two cheeseburgers and a Big Mac to go." At a show he crashed into it instead and got "You have destroyed the only McDonald's on the moon", and since core remembers everything, nobody else could find it after that (21:13).
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=1273s
The GT40 came up in a bootloader and pulled programs down the serial line, so no toggling, but debugging it was pure front panel. Hitting line feed crashed the PDP-11, so he single-stepped through the bootloader with a diagnostic card, down to a byte compare of the high byte, which goes through a shift, and found a dead 74194 4-bit shifter (15:50).
A PROM on one of the boards had failed, and no binary of it survived anywhere, so they typed its 256 entries back in from the listings (13:46). His rule number one is "don't trust anybody": he double-checked his friend's careful transcription and found two transposed digits that "would have created a bug so subtle that it would have taken us months to find it" (14:31). The same rule caught the downloaded diagnostics, which had a stray "!" and a newline inserted that made the loader abort (17:15). And on Bitsavers: "we could not have restored it without it" (13:10).
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=826s
Other highlights: Atari's 1979 Lunar Lander turns out to be a direct copy of the GT40's vector generator, binary rate multipliers and all, with a 6502, ROM and static RAM swapped in for the PDP-11 and its expensive core (5:11). At VCF Midwest the wall power sagged to 90 volts, so he ran it off his camping battery (23:39). And he showed it next to the PDP-11/45 that animated the Death Star trench briefing in Star Wars, with a dueling light pen battle between the two (24:46).
I've been doing the same kind of thing without the soldering iron: bringing Heinz Lemke's 1972 PIXIE/SYMELEC light pen system for the PDP-7 and Type 340 back to life in a browser emulator, from a scanned listing, since no tape survives. Then DEC's own 1964 370 Light Pen Diagnostic, transcribed from a scan that skips from page 5 to page 7, so page 6 had to be rebuilt from how the surviving pages use each of its symbols.
Scott's rule number one turned out to be mine too. Every bug falls into one of three kinds: ours (the emulator got it wrong), the transcription's (the listing was misread off the scan), and 1972's (the listing itself is wrong, and the emulator should faithfully reproduce the mistake). The first one was a truncated literal pool. The conversion stopped at word 11741, so every (JMP INT literal read as 0, and the machine initialized itself into a wall. So far, every bug had its answer on paper before anyone went looking. The emulator's job is to run the listing until it disagrees with itself, and then to show where.
Bug Journal:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
370 Light Pen Diagnostic (DEC-4-45-M, 7-78-M):
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
1972 PIXIE PDP-7 Assembler Listings:
https://github.com/SimHacker/WillWrightShowForFood/tree/main...
In 1972 the PDP-7 was the small one. It hung off Cambridge's Titan (an Atlas 2 that filled a room and ran the university) as a satellite, phoning home over Neil Wiseman's custom link to store and retrieve drawings in the Titan filestore.
The emulator inverts that: tiny-titan is the whole of Titan, as much of it as PIXIE ever saw, in one TypeScript file, serving its emulated satellite from inside a browser tab. It implements only what the one surviving caller ever dialed, and SYMELEC's unmodified link code runs against it.
Tiny Titan:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
tiny-titan.ts:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
Flight of the PIXIE - Yuja Wang:
https://www.youtube.com/watch?v=jDrqR9XssJI
PIXIE Live in PDP-7 Emulator with 340 Vector Display Simulator:
https://hyperties.org/databases/pixie/pixie-live/
Press the "DEMO" button and it will make a goofy child's drawing with the virtual light pen. I plan to ask Claude to make a new demo by trying to draw a pelican riding a bicycle.
Enable the MEMORY panel's "SOURCE" + "FOLLOW PC" mode, then slow the emulator down with the slider, to see the PDP-7 assembly source code it's executing (from the OCR of the scan of 128 pages of line printer output).
You can also pick "LIGHT PEN TEST (1964)" from the menu and press "DEMO", or pick "DUEL (1968)" and play spacewar for two, DECUS 7-40, loaded from paper tape through the RIM loader, the PDP-7's version of your bootstrap.
And I made a non-graphical "HILO (2026)" number guessing game and a "LUNAR LANDER (2026)" game to test out the TTY simulator. The lander is in the spirit of the turn-based original Scott describes (1:52), before the GT40 made it real time: "YOU ARE 500 FEET UP, FALLING AT 50 FT/S, WITH 60 UNITS OF FUEL."
Lander README:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
lander.s:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
PDP-7 Unix is coming soon. Warren Toomey, Phil Budne, Tom Everett, Sebastian Rasmussen, Robert Swierczek and friends did this kind of restoration on a much bigger scale with the pdp7-unix project. Starting in 2016 they typed in Ken Thompson's 1969-70 PDP-7 Unix from Norman Wilson's scans of the only surviving printouts, wrote a cross-assembler (as7) and a user-mode simulator, and got the kernel booting to a shell with a working filesystem.
In 2019 a second notebook of missing sources turned up and was scanned and typed in too, and in January 2020 it ran on a real PDP-7 at the Living Computer Museum. It even has moo, the bulls-and-cows number guessing game, a 1970 cousin of my HILO.
PDP-7 Unix:
https://github.com/DoctorWkt/pdp7-unix
Recovered Unix documents:
http://www.tuhs.org/Archive/Distributions/Research/McIlroy_v...
Their as7 was the precedent for my own assembler, which can run in the browser and produce symbol tables and source maps, the way a TypeScript to JavaScript compiler does. That's what drives the Memory panel's Source + Follow PC mode, and it's the groundwork for live coding:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
To run Unix, the cabinet needs what its SIMH script asks for: 8K with EAE, the teletype, the clock, and the RB09 fixed-head disk. It loads boot.rim, and the bootstrap reads the system from disk. So the new part is porting SIMH's RB09.
B comes with it: the interpreter (bi.s) and loader (bl.s) survive in the scans, and Robert Swierczek rebuilt the missing compiler in 2016. There's no C on the PDP-7. C came later on the PDP-11, and B was Thompson's cut-down BCPL.
The plan is in the cabinet README:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
And a couple days ago Mitch Bradley wrote a PDP-7 FORTH for it, including a Turtle Graphics package, which I'll integrate soon too! That's the other half of live coding. My assembler is TypeScript running on the emulator host, but Forth will run on the PDP-7 itself: you type new definitions at the emulated teletype, and the turtle draws them on the 340, interactively, in a language living inside the machine.
B compiles to threaded code too, so the cabinet will have two threaded interpreters, 1970 and 2026, running side by side!
Fittingly for a thread about whether the ENIAC had a BIOS: Mitch is the one who wrote Open Firmware, the Forth-based boot firmware in Sun workstations, PowerPC Macs, and the OLPC XO. So the PDP-7 is getting its Forth from the same man who invented Open Firmware to put Forth in the BIOS.
Mitch Bradley's PDP-7 Forth:
https://github.com/MitchBradley/pdp7forth/tree/main
PDP-7 Forth — Design Notes:
https://github.com/MitchBradley/pdp7forth/blob/main/DESIGN.m...
turtle.fs: Turtle Graphics for 340 vector graphics processor in FORTH (which works by assembling 340 display IOT opcodes):
https://github.com/MitchBradley/pdp7forth/blob/main/lib/turt...
Mitch Bradley singing the Open Firmware Song
https://www.youtube.com/watch?v=b8Wyvb9GotM
Mitch Bradley shows and explains Open Firmware
https://www.youtube.com/watch?v=KvxxAeuhPp0
Mitch's threading technique is a new one, as far as we can tell, small fast and elegant on the PDP-7. NEXT is three instructions, and the core of it is XCT I 10: it bumps an auto-index register and executes the thread cell it points at, so every cell in a compiled definition is itself a PDP-7 instruction, and its opcode is its type. CAL enters a colon word, JMP runs a primitive, and LAC or LAW pushes a constant or variable.
That makes location 10 a second program counter, running a virtual machine whose instruction set is the PDP-7's own. It doesn't fit Anton Ertl's threading taxonomy. For publication, "XCT Threading". For the T-shirt, "Indirectly Direct Threading".
PDP-7 Forth XCT Threading:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
The EDSAC's "boot ROM" consisted of a bank of large electro-meachanical "uniselector" rotary switches, hardwired to contain the 31 instructions ("initial orders") of the tape loader.
Subsequent computers could have followed this "electro-mechanical ROM" approach, but I suppose it was rather bulky and inconvenient to change.
You can see what the uniselectors looked like here at 8:50
https://www.youtube.com/watch?v=Yc945sNB0uA
Of course programmable ROM chips would have to wait, so in the meantime the alternatives were either the toggle-it-in approach (still also used by the 1974 MITS Altair 8800), or other more compact types of handmade/hardcoded physical ROM such as magnetic core or diode matrices.
The Harris 100 launched in 1978 still used a bank of toggles for initial load.
I was operating and maintaining several until about a decade ago.
That's a bit surprising on a more expensive machine.
How often would you reboot them?
Typically daily. They were used for troubleshooting and repairing military avionics. They survived decades onboard ships, etc. They got temperamental in their later years, but we kept them going.
If you have any interest you can search up the (sparse) information on the AN/USM-484 Hybrid Test Set (or System).
> It seems a little strange that more advanced later machines like the original PDP-11 from 1970, couldn't "autostart" from ROM like that.
Because the PDPs had magnetic core memory, so the bootloader, once toggled in, stayed in memory. The OS took care not to overwrite it.
And in normal operation you wouldn't have to use it at all, you just switched on your PDP, and it was in the same state as when you switched it off.
Also, bootloaders were short (because peripherals had lots of intelligence); toggling one in was a matter of minutes.
> I think that was because core memory was non-volatile.
Exactly. And when RAM cards were available to replace core (very late in the lifecycle of the minis), the RAM was battery backed to simulate that behaviour.
In Fred Hoyle’s science fiction novel, The Black Cloud, there is a computer in an early chapter that is clearly inspired by EDSAC. When they run a program on it, the process is just what you describe - they load a paper tape in through the tape reader, which Hoyle describes in detail.
I first read that book before I knew that in British English a vacuum tube is called a valve (from thermionic valve and which makes more sense than the American term, I think), so I was confused by the line about how warm the room was due to all of the valves!
Valve gear is particularly full of transatlantic differences, as well as valves vs tubes in many cases the same specific valves can have different names depending on the side of the Atlantic you're on such as EL84 vs 6BQ5. Your high voltage line is called HT in British but B+ in American, while what we'd call an anode in the UK is more commonly called a plate in the US. I'm not sure if it's as fixed but I've usually heard Americans calling what I'd call the heater the filament as well.
While 'valve' makes more sense from the point of view of what it does, 'tube' makes more sense from the point of view of what it is I think.
We called them thermionic valves too, just the terminology shifted a bit over time. We also called capacitors "condensers". Both were references to steam powered control systems.
Many languages still call them "condensers"; from the top of my head, Spanish, French, Italian, German, Japanese, and likely many others.
Even in English in some cases the term is still used, for example in condenser microphones, and in the context of old mechanical fuel systems.
My dad, a lifetime ham radio operator and an EE called them condensers sometimes. And would refer to frequencies in kilocycles.
Hmm, I have read contradicting accounts.
They say the term did not originate from the steam condenser. Quite the opposite, it became deprecated because of the ambiguous meaning of steam condenser.
What I'm reading (and was told by grey beards) is that it originated as a metaphor to steam condensers, and was deprecated because the two different systems having the same term led to ambiguities. Including the fact that they do have different properties, such as steam condensers are able to absorb steam pressure, but can't actually return the steam when the input pressure drops back down (since it's already been condensed back into water).
Very biased, but at Cambridge we were taught (by Maurice Wilkes among others) that the EDSAC was the first “useful” computer.
I just met John Robson at a meeting who was one of the first people in the world to run a frequency domain analysis on time series data - on EDSAC! He spent a long time explaining the precise algorithms to me - amazing!
"Oh, I wonder which subroutine he came up with"
(Googles it)
"Ah"
"Which subroutine did he come up with?"
"Yes"
"The"
TIL about delay line memory, thanks! Curious idea. Wikipedia says Alan Turing proposed the use of gin as an ultrasonic delay medium :-)
Processes like this are where "boot" comes from. The machine was pulling itself up by its bootstraps. The ROM was sometimes called the "bootstrap loader."
I had Claude Opus disassemble the CDC 6600 dead start panel. The hard part was finding a better image of the switches so the vision could read the bits.¹
The content isn't very interesting, and Claude's comments aren't very detailed. Not bad for 2 minutes of work about a 62 year old computer though. Look out Ken Shirriff, AI is coming for you.²
1. https://dyninst.github.io/scalable_tools_workshop/petascale2...2. Not really. I have no idea if this disassembly is corrrect.
3. Quora is prison for words.
I'm pretty sure Kay's not quite correct about the Eniac not being a stored program computer. In it's original form it obviously was not, as it had to physically reconfigured to solve different problems. However, after the war it was rebuilt to operate like any other stored program (von Neumann architecture) computer, as it was the first recipient of the design philosophy seen in the EDVAC report. It operated in that mode from '48 to '55, when it was decommissioned.
ENIAC in Action: Making and Remaking the Modern Computer is an excellent summary of the initial design and redesign of the Eniac.
Apparently Eckert (John Mauchly and J. Presper Eckert designed the ENIAC) claimed that von Neumann basically stole their idea of the stored program and that they had already came up with the idea and he just took it and ran with it as if it was his
> And John Von Neumann? He came and looked at our stuff and went back to Princeton and wrote a long document about the principles. He gets a lot of credit but the inventions were ours. Someday I’ll write a book on who really invented the computer.
>Johnny learned instantly, of course, as was his nature. But he chose to refer to the modules we had described as “organs” and to substitute hypothetical “neurons” for hypothetical vacuum tubes or other devices which could perform logical functions. It was clear that Johnny was rephrasing our logic, but it was still the SAME logic. Also, he was introducing different but equivalent symbols; nevertheless the devices still did the same things. Johnny did NOT alter the fundamental concepts which we had already formulated for the EDVAC.
>Small wonder, then, that computer history gave von Neumann the credit. Eckert and I, who left the Univ. of Penna. In 1946, no longer had access to the documents which might have helped to show “who did what, when.” But after many years, litigation has unearthed some of those documents, and historians can read what was once classified. But, even after declassification, those reports are not accessible to most people, since they were reproduced in such small quantities. Nevertheless, we hope that more historians will refer to them.
Eckert and Mauchly weren't reliable narrators of the history of their work, given how much they needed to claim in order to get the patents that were later invalidated. They claimed quite a few things that were later disproven in court or through historical study. At the least, Eniac was designed by the team at the Moore School.
von Neumann's "First Draft of a Report on the EDVAC" was both a summary of discussions by the Eniac team as well as von Neumann's own original work proving and expanding on various aspects of those discussions. It's called the von Neumann architecture because he was the author of the seminal paper, not because he laid any particular claim to the ideas. Eckert and Mauchly were mostly upset about the paper's existence, regardless of author, because it made it impossible for them to patent the stored program idea in general.
Story as old as time: corporate vs academia working towards very different goals and with different incentives, short term profit vs publication. In very rare cases, the scholar gets the rewards.
>Eckert and Mauchly weren't reliable narrators of the history of their work, given how much they needed to claim in order to get the patents
The existence of an incentive doesn't predestine the outcome.
Von Neumann was the one who inappropriately failed to credit them in "First draft...". Goldstine was the one who distributed it knowing they were legally unable to publish themselves. These are the unethical actions that clouded the record. Between these two sides, I'll be trusting Eckert and Mauchly's account.
>They claimed quite a few things that were later disproven in court or through historical study.
Ehh.. I'm curious which things you're referring to. The patent trial was hogwash, so depending on the topic, 'disproven in court' could mean literally nothing. I hope you're not just an Atanasoff crank...?
Saying "like any other stored program computer" makes it sound like there were a bunch of them, but as I understand it there was really only ONE up and running at that time in 1948 - IBM's SSEC. The stored program EDVAC, whose architecture Von Neumann had formalized, was still not yet running, and Von Neumann personally advised on adapting ENIAC to this mode of operation.
As I understand it, even after adaptation to "stored program" mode, the program was still configured rather than loaded and stored, but now configuration was done using the function table dials (essentially a dedicated dial for each program step) rather than patch cords, and was a lot more convenient. Punched cards could be used for reading/writing data, but not for programs.
It seems there was no BIOS because I/O was so primitive. Per configuration a punched card would be read into the "constant transmitter" unit, then one of the read numbers could be copied into one of the 20 accumulators. Or you could do the same in reverse to output data from the accumulators.
>as I understand it there was really only ONE up and running at that time in 1948
As a matter of interest, "that time" being April, it was only two months later in June that the Manchester Baby ran its first stored program.
Right. The patent refers to "semi-permanent cable connections" between card reader, registers, and printer. Basically, you could load and dump parts of memory, in decimal. The registers were all decimal, and so were IBM tabulators, so the interface is mostly a set of relays. No sign of format conversion or alphabetic capability.
Alan Kay answering questions on Quora. What a cool gift to the world!
This is one of the thing we lose as more and more of the conversations turn to people privately asking LLMs things, who do their best to scrape out answers from the existing info or make up a best guess. People are losing the ability to ask experts with real, unique knowledge and then share that knowledge with humanity.
he answers questions here too
Somewhat tangential, I've watched a bunch of videos on YouTube from @deramp5113 about the Altair 8800 and other early microcomputers, which feature a similar set of front panel switches for dialing in your initial program. One thing that's interesting to me, as someone who learned computing in the late 90s, is how much is expressed in octal instead of hex on these early computers.
As shown in the linked picture, the byte pairs are divided into [4 groups of 3] instead of [3 groups of 4] switches, which I would find more comfortable as a hex-reader. I believe, maybe someone can confirm, that octal notation is easier to translate into bits than hex is. We just don't do either of those things terribly often anymore, so octal has mostly fallen out of favor, perhaps because it groups less nicely into multiples of 8.
Nowadays I almost never think in octal. The only time it seems to come up is for Unix file mode switches (chmod etc), which likely date to this time when octal was more common.
Just some interesting cultural drift.
I have restored a Data General MicroNOVA that also uses octal. It has an emulated front panel over serial and uses octal in multi-digit commands like specifying which address you want to boot from, "33L" to book from an MFM disk controller for example. That is probably a legacy carryover from the NOVA 3 and earlier where you would be able to input the same thing into the front panel switches.
Fundamentally I wouldn't say octal is fundamentally easier to interpret other than hex because it's just half as many digits. The shorthand things about octal used in unix you mentioned all still technically apply to hex as well. The only really tricky part is where it becomes letters and you have to think if D or E is the odd value with the first bit set. If you were doing hex all day though, the 6 hex letter patterns would be pretty easy to memorize.
Personally I would say for front panel systems specifically was just about physical space for the switches. If you look up CPU trainers for something like Intel 8080 in the Altair 8800, you'll see it uses a hex keypad. Multiple 16b values would have been a lot harder to fit in single bit switches.
Octal allowed used of simpler numeric displays (numeric nixie tubes or 7-segment displays) as you only needed digits and not ABCDEF that you'd need for hex notation.
Octal on a PDP-11 meant that the instruction set (16 bits) allowed two-register instructions with src/dst register and modes taking up 12 bits.
So you programmed the front panel with 3 fingers for octal instead of 4 for hex.
Octal just maps onto 3 bits instead of hex's 4. I always imagined it had something to do with the size of the byte not being standardized yet.
AFAIK, a "byte" is 8 bits, but a "word" wasn't quite decided yet, and they were often divisible by 3, making octal make more sense
On a PDP-11 there were 8 registers, R0-R7, with R6 being the (default) stack pointer and R7 being the program counter.
There were 8 address modes for each register.
So a src/dst instruction used up 12 bits for the src/dst+modes, a single register instruction used 6 bits.
You could load the registers directly at addresses 177770 through 177777 on the front panel. So if your program was 5 words long, you could load that into registers R0-R4, then load R7 with the address 177770 and execute.
Was this at all related to standard tubes using octal sockets? I can't think of any reason this would be personally, but I could be missing something.
Octal sockets are just tube sockets with 8 pins, it doesn't mean they calculate in octal
Right, how could they? It's just one tube.
Kay nails it: the ENIAC 'BIOS' was literally a team of humans with patch cables. Makes you appreciate modern bootloaders.
Even into the "modern" microprocessor era, a lot of them had no BIOS to speak of they just loaded the first instruction (or a pointer to it) from a standard address (e.g. 0000) and started running.
I don't remember any CP/M system with the BIOS part in ROM (and BDOS loaded from disk). It would be possible, of course, but every subsequent version of CP/M for that machine would need to be able to work with the "frozen" BIOS, and I'm not sure CP/M was designed thinking of mixing BIOS/BDOS versions.
Saying that, I think the Epson PX-4 and PX-8 had CP/M in ROM.
Having said that, Alan Kay has seen things we people wouldn't believe, so, if he says it happened, I'm betting on him.
Man I didn't even realize that Quora was still around, let alone prominent people still answering questions on it. I deprioritized it in my Kagi searches months ago and even then I didn't notice that much of a change in the quality of my searches.
Quora is such a gamble when it comes to accurate or relevant results. Either you get something incredibly insightful from someone with real experience or you get misinformation and stupid opinions. It's really only slightly helpful when I'm looking for subjective opinions or a personal perspective on some topic. It's very much a negative result when I'm looking for factual, verifiable information.
Yeah this is the first time in months if not years that I’m seeing the website.
Some older people are on it, apparently, and some good experts among them too. Older folks often don't keep up with platform fashion. Some good older scientists even use academia.edu or researchgate...
Of course I'd prefer if he answered on a StackExchange site, tho I heard those are in decline too, but at least not enshittified like Quora.
So isn't the BIOS sort of an intermediary artifact?
I think when CPM booted, there must have been some hardcoded disk firmware to get the boot sector into memory.
The IBM PC bios was burned into the system.
I think the boot process is multifaceted and can have as many stages.
So early computers did have BIOS, but they loaded from wetware rather than firmware?
The most surprising thing about this to me is Alan Kay answering questions on Quora.
He's been doing that for years. I wish he'd come back to HN!
https://news.ycombinator.com/posts?id=alankay
Me too. It's a shame he doesn't post here more often, because Quora's thoroughly enshitified user interface is so spectacularly hard to use and intentionally, aggressively, darkly patterned.
Quora has at least three different ways of folding content, and each one needs its own click: answers truncated at "(more)", comments collapsed behind "View comments", and nested replies collapsed again behind "View more replies", yet tellingly no "Expand all" button.
For logged-out readers there's also a login wall that blurs the rest of the page. The whole thing is fragile. Click the wrong thing, hit Back, or refresh, and it forgets everything you expanded and where you were scrolled, and dumps you back into a feed of unrelated "related" answers.
Worst of all, there's no way to link to a comment so that it restores your viewpoint and opens everything back up. The link lands on a page with everything folded again, and whoever you sent it to has to redo all the clicking to find what you meant. While HN has one kind of fold, [–], and every comment has a permanent item id that takes you straight to it, expanded and in context.
Maybe his last long visit here didn't leave him with a good impression of the "civilized behavior" of Hacker News. hota_mazi aggressively argued that Alan didn't coin the term "object-oriented," and then, when challenged, posted a bunch of unsubstantiated disrespectful misinformation.
Worse, hota_mazi did it while attacking Alan's friend Joe Armstrong in Joe's own memorial thread, days after Joe died, when Joe could no longer answer for himself. Alan exasperatedly asked him twice to do his homework.
Joe Armstrong died on April 20, 2019. The next day his essay "Why OO Sucks" was posted here, and the thread became a place to remember him.
https://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
https://news.ycombinator.com/item?id=19715191
arendtio wrote:
> Actually, this is not really about if OO sucks, but to reflect on one of the articles Joe Armstrong wrote. Joe passed away two days ago.
oldpond wrote:
> Joe was truly one of the greats. [...] Thank, Joe.
(Not everyone was so kind. Someone posted just "Why Joe Armstrong sucks"; it's [dead].)
The top comment, by rhblake, quoted Joe's own 2010 explanation of why he changed his mind about OO:
> "Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". [...] Alan Kay himself wrote this famous thing and said "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages"."
That's Joe, in his own words, crediting his supervisor and Alan. hota_mazi replied to it, two days after Joe's death, by accusing both men of opportunism [log in and set showdead=true to view flagged posts]:
https://news.ycombinator.com/item?id=19716281
hota_mazi on April 22, 2019 [flagged]:
> Both Alan Kay and Joe Armstrong struck me as having had the same attitude of trying to capitalize on the topic of object oriented programming, failing to recognize its importance, and then later trying to appropriate it by redefining it.
> Not the best moment of these otherwise two bright minds.
skndr asked:
> Didn't Alan Kay coin the term "object oriented"?
Before Alan had even joined the thread, hota_mazi dismissed Alan's own account of his own work:
https://news.ycombinator.com/item?id=19716318
hota_mazi on April 22, 2019:
> That's what he claims but there's zero evidence besides his own word.
lliamander asked the obvious question:
> Well, how large is the pool of other possible candidates? Wouldn't someone from that time period (say the Simula folks, or another PARC employee) challenge that assertion?
So did DonaldPShimoda:
> Ah, so you have evidence that it was somebody else?
hota_mazi admitted he had none:
> I don't, but that's not how the burden of proof works.
DonaldPShimoda, who works in programming language research, set him straight:
https://news.ycombinator.com/item?id=19716632
> Every source I've ever come across on this topic (and I work in PL research) points to Kay as the originator of the term "object-oriented" in relation to programming. No exceptions.
> You are now making an affirmative assertion that Alan Kay did not coin the term. The burden of proof is on you, not him.
hota_mazi demanded the sources while still rejecting the claim while hypocritically not doing any homework or providing any sources to his misinformation:
> Link these sources, then! Even someone who recently interviewed him and researched the subject for months confessed he could never corroborate that claim.
> You make the claim he coined the term, the burden of proof is on you.
> Until you do, it's perfectly reasonable and intellectually honest to reject that claim.
DonaldPShimoda:
https://news.ycombinator.com/item?id=19716791
> This would be just like saying "Well I don't think da Vinci really made the Mona Lisa. I mean, all we have is his word for it." [...]
> Your position is not "intellectually honest" because it sincerely looks like you're just trying to be antagonistic.
Then Alan arrived and said it plainly, in his own words:
https://news.ycombinator.com/item?id=19717640
alankay on April 22, 2019:
> I didn't coin the term "object" -- and I shouldn't have used it in 1966 when I did coin the term "object-oriented programming" flippantly in response to the question "what are you working on?".
And he replied directly to hota_mazi's first comment:
> This is way off. Please try to do more homework.
hota_mazi wasn't done with Joe. lliamander had challenged him:
> I'd be really interested to hear what you think they missed, because I find your claim to be surprising and a bit preposterous.
So, in the thread where people were mourning Joe, hota_mazi explained that Joe had been a bandwagon-chaser who bent the definition of OOP to cash in on its success:
https://news.ycombinator.com/item?id=19716419
hota_mazi on April 22, 2019 [flagged]:
> Armstrong wrote the very famous "Why OO sucks" and then a decade or two later, changed his mind when he saw how successful OO was, and then tried to retrofit Erlang into an OO language. Not by changing Erlang, but by twisting the definition of OOP so that Erlang would fit it.
That contradicts Joe's own explanation, quoted at the top of the same thread, and Joe was no longer alive to correct it. revvx did it for him:
https://news.ycombinator.com/item?id=19716488
> Joe Armstrong was criticizing C++-style OOP when he wrote his critique. After he learned more about Alan Kay's view on OOP, he decided that Erlang is closer to Alan Kay's OOP and he approves that specific flavor of OOP. He didn't change his stance based on popularity.
And Alan, two days after losing his friend, was left defending Joe's character:
https://news.ycombinator.com/item?id=19717646
> That isn't what happened at all (see the rebuttal by revvx). Joe was a great guy and also a great systems thinker. And he was the last person to worry about "bandwagons" (quite the opposite!)
hota_mazi doubled down, arguing that since mainstream OOP ended up meaning something else, Alan's and Joe's view didn't count:
https://news.ycombinator.com/item?id=19716595
> He doesn't even mention C++ in his essay [1], but regardless, the C++ OOP is pretty much the mainstream OOP, which we still use today in Java, Kotlin, C#, etc...
> And... no, the change in mindset about OOP never happened. Kay and Armstrong's view of OOP never took on. Today, OOP is still not seen as message passing and mostly seen as polymorphism, parametric typing, classes/traits/interfaces, and encapsulation. The complete opposite of what Erlang is.
> [1] http://harmful.cat-v.org/software/OO_programming/why_oo_suck...
revvx:
https://news.ycombinator.com/item?id=19716625
> I'm the one mentioning C++. To anyone familiar with both styles, Joe Armstrong is clearly not talking about Smalltalk-style OOP in his essay, he's talking about C++/Java/etc style. And later on he only praised Smalltalk-style OOP.
To which Alan could only say, again:
https://news.ycombinator.com/item?id=19717662
> Again, please do your homework.
On top of that, people doubted it was really Alan at all. hannofcart asked:
> Are you the Alan Kay. Is there any way we can verify this is you? The HN user account seems to have a very low "karma" rating, so one can't help but be more suspicious.
Alan answered:
> I'm the "computing Alan Kay" from the ARPA/Parc research community (there's a clarinettist, a judge, a wrestler, etc.) I did create a new account for these replies (I used my old ARPA login name).
DonaldPShimoda still wasn't sure:
https://news.ycombinator.com/item?id=19721376
> I'm a little skeptical. [...] A one-day-old HN account claiming to belong to one of the most important people in CS from the past 50 years seems a little suspicious haha.
That's what Alan was answering with his weary verdict:
https://news.ycombinator.com/item?id=19721772
alankay on April 22, 2019:
> An interesting and unfortunately true commentary on the lack of civilized behavior using technology that actually required a fair amount of effort -- and civilized behavior -- to invent in the first place.
(To DonaldPShimoda's credit, he apologized, and Alan graciously reminisced about crawling over Simula machine code listings unrolled down the hallways of the Merrill Engineering Building.)
A week later Alan was still correcting the record, when someone misquoted him:
> Actually, I said: "I invented the term "object-oriented", and I didn't have C++ in mind". In other comments here I explain why "object-oriented" was a too quick and bad choice for what I thought I was doing ...
How often would those cold-start switches be altered?
Just when they wanted to swap tape-reading hardware?
Or did different programs want slightly different loaders?
Reading Kay's take reminds me those guys were the BIOS. Fascinating how computing evolved from pure hardware, not just software.
Boot loader before init. Point is that ISO runs with .img files.
Kay probably explained how we were the BIOS then, flipping switches and loading programs by hand. Different era!
Leave it to Alan Kay to articulate the spirit of a BIOS, even for ENIAC. Those fundamental abstractions persist.
BIOS wasn't a concept until 1975 with CP/M so it isn't possible for a computer older than that to have one.
Many people unfortunately completely conflate one or more of these terms to generically mean "ROM-resident code that enables a device to self-bootstrap": BIOS, UEFI, firmware, bootloader, boot ROM, boot flash, IPL, (boot) monitor, microcode
Guy who still writes Quora answers
Kristen Nygaard would have turned 100 last month, so here's a history of object-oriented programming as a series of subtractions, each one taking away something the previous generation thought was essential.
Nygaard and Ole-Johan Dahl built Simula at the Norwegian Computing Center to simulate things like ships moving through harbors and customers waiting in queues. Simula I (1962-65) was a simulation language. Simula 67 generalized it and gave us nearly the whole kit: classes, objects, subclasses, virtual procedures (dynamic dispatch), and coroutines, so each object could run its own little process. They shared the Turing Award for it in 2001. Nygaard went on to design BETA with Ole Lehrmann Madsen and Birger Møller-Pedersen, and to pioneer participatory design, working with trade unions on how workers should have a say in the systems imposed on them. He never thought of programming as separate from the people it was for.
https://cs.au.dk/nygaard100years/celebration
https://news.ycombinator.com/item?id=49850612
>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, and 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.
Simula inspired two very different children.
Alan Kay saw Simula I and Sketchpad in the same week in grad school at Utah in 1966, and it gave him the idea that everything could be like a little computer: protected, self-contained processes that only communicate by sending messages. When someone asked what he was working on, he flippantly answered "object-oriented programming", and the name stuck. Smalltalk kept Simula's classes, but the big idea was messaging. As he put it in 2003: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
Bjarne Stroustrup used Simula for his PhD simulations at Cambridge, loved how it let him structure programs, and found the implementation far too slow. So in 1979 he bolted Simula's classes onto C, and "C with Classes" became C++. It kept the classes and the static types, and dropped the messaging and most of the late binding, so the compiler could make it fast.
Alan has been drawing the contrast ever since. In his own words, correcting someone here who misquoted him: "I invented the term 'object-oriented', and I didn't have C++ in mind."
Then David Ungar and Randy Smith took something away. Self removed the classes. Only objects remain, and they inherit directly from other objects through parent slots. An object can have several parents, so you get multiple inheritance for free, and since parents are just slots, you can change them at runtime. There's no assignment syntax either: variables are slots you send messages to. The title of the 1987 paper says what it was about: "Self: The Power of Simplicity."
https://selflanguage.org/
A language that dynamic was supposed to be too slow to use, so Craig Chambers, Urs Hölzle and Ungar invented the techniques that made it fast anyway: maps (hidden classes), customization, polymorphic inline caches, adaptive recompilation, and deoptimization (pessimization) so you could still debug optimized code.
That work went through Animorphic's Strongtalk to Sun and became Java's HotSpot, and Lars Bak carried it on into V8 for JavaScript. JavaScript's design credited Self, but missed the point by subtracting the one thing Self was about: simplicity. Brendan Eich never understood simplicity, or even the $1000 question: equality.
https://dorey.github.io/JavaScript-Equality-Table/
Anders Hejlsberg, who designed Turbo Pascal, Delphi, C#, and then TypeScript to clean up after JavaScript, at a 2019 panel with Guido van Rossum, James Gosling and Larry Wall:
https://news.ycombinator.com/item?id=19568378
>"My favorite is always the billion dollar mistake [Tony Hoare's name for null] of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
>"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
Self's ideas (speculate on what you've observed, guard the assumption, bail out when it breaks) are how everybody's JIT works now, from .NET's tiered compilation for C# to LuaJIT's traces. Separately, Self's prototypes became JavaScript's object model, and Lua's metatables follow the same prototype approach.
The irony is that Self's compiler was the reward for simplicity, and it became the subsidy and license for complexity. The same techniques now make Java, JavaScript, C# and Lua run fast no matter how complicated their object models get, which flies in the face of the key word Ungar and Smith put in the title: simplicity.
Then Ungar, Harold Ossher and Doug Kimelman at IBM took the next thing away. Korz removed the objects and kept the slots. A program is a flat sea of slots that belong to nothing, each guarded on named dimensions, and a message is sent in a context of dimension bindings that flows implicitly down the call chain. The receiver becomes one ordinary dimension (rcvr) among any number. Group the slots by rcvr and you see ordinary objects again, but that's just one view, and no view is the privileged one. Once again the title leads with the point: "Korz: Simple, Symmetric, Subjective, Context-Oriented Programming" (Onward! 2014).
https://dl.acm.org/doi/10.1145/2661136.2661147
The name comes from Alfred Korzybski, whose Science and Sanity (1933) argued how much perspective shapes perception, and who gave us "the map is not the territory." It's a fitting name, because Self's implementation was built on maps: hidden structures describing the layout of objects that share a shape, which the programmer never sees, while the objects themselves are the territory. (V8 still calls its hidden classes Maps.) In Korz it's the other way around. The slots are the territory, and objects are just maps of it, one of many possible projections. Self hid its maps behind the objects, and Korz shows the objects were maps all along.
Look at that title and you can see what happened in between. When the receiver is the only thing allowed to vary behavior, everything else that needs to vary behavior has to start its own movement. Subject-oriented programming (Harrison and Ossher, 1993) varies by who is looking. Aspect-oriented programming (Kiczales et al. at PARC, 1997) varies by which concern cuts across. Context-oriented programming (Hirschfeld, Costanza and Nierstrasz, around 2005-2008) varies by what situation you're in. Then there's feature-oriented, role-oriented, and the rest.
Each one takes the same mechanism and freezes a different dimension into its name. Ossher co-invented subject-oriented programming, and with Korz he and his colleagues argued that all of these are projections of one smaller mechanism: dispatch on any number of named dimensions.
So I propose continuing the tradition by removing the next thing that complicates matters: the modifier. Object-Oriented Programming, minus the Object guard, is just Oriented Programming. Behavior is chosen by where you stand along whatever dimensions you've declared, and none of them is privileged in the name. How it's oriented matters less than whether it's oriented.
Oriented languages have one declared bearing that everything else follows, whatever that bearing is: Smalltalk and Self (objects receiving messages), CLOS (generic functions dispatching on all their arguments, with method combination), Korz (slots, guards and dimensions), Erlang (isolated processes sending messages, which is why Joe Armstrong concluded it might be the only object-oriented language), Lisp (lists), Forth (the stack), APL (arrays), Tcl (strings), Lua (tables), Prolog, Datalog and SQL (relations), and Unix (files and pipes).
The corollary is Disoriented Programming: a language that names one dimension in its paradigm, while its real behavior depends on a dozen unstated ones scattered across unrelated mechanisms. It comes in two flavors, naive and diabolical.
The classic naive case is PHP. It was never designed so much as accreted, one "next logical step" at a time, with open contempt for computer science and for design itself. Rasmus Lerdorf said as much: "I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." and "We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." The result has no bearing at all: functions, classes, traits, magic methods, superglobals, variable variables, and a standard library whose argument order you have to look up every time.
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
C++ is disoriented in many of the same ways, but on purpose. Every mechanism was deliberately chosen, carefully argued, and added on the principle that you don't pay for what you don't use. The upshot is that the behavior of a single call can depend on classes, templates, overloading, argument-dependent lookup, virtual versus non-virtual, implicit conversions, macros and friends, all interacting exactly as specified. That's diabolical, and Stroustrup knew it: "Within C++, there is a much smaller and cleaner language struggling to get out." It's still not what Alan had in mind.
Most other mainstream languages drift somewhere between those two poles. In enterprise Java, annotations, reflection, dependency injection and aspect weavers decide more than the classes do. JavaScript has prototypes underneath, class syntax on top, and several different rules for what "this" means. C# and Scala keep adding features instead of taking them away.
Disoriented doesn't mean useless. Those dimensions of variation are real and necessary, which is exactly why all those mechanisms got bolted on. It's disoriented to pretend there's only one direction on the compass, and hide all the others in places the language won't admit are part of the model.
I've written this up at more length as a Chip Morningstar-style "How to Deconstruct Almost Anything" deconstruction: declassification, then deobjectification, then what's left:
How to Deconstruct Almost Anything:
https://www.fudco.com/chip/deconstr.html
https://news.ycombinator.com/item?id=6389498
How to Disorient Almost Anything:
https://github.com/SimHacker/moollm/blob/main/designs/korz/d...
>Marvin Minsky saw the same enthronement in psychology. In a 1982 essay he demolished what he called the Single Agent theory -- the folk idea of "a little person deep down there" who does the real mental work -- and concluded: "Self, itself, is not a single thing." He wrote that five years before Self the language shipped, and it reads as a prophecy of what came next.
That leaves an open question for David Ungar: having demoted the receiver, would he go the rest of the way, drop the modifier, and call the whole genre Oriented Programming?
www.quora.com Performing security verification This website uses a security service to protect against malicious bots. This page is displayed while the website verifies you are not a bot.
If you have too much adblock, as I do, you can never visit quora.com. The security check will just loop infinitely.
Funny. Just tested that because I'm always told: too complicated, nothing will work!
And got no check at all.
Edit: Maybe it depends on where you come from, or what they think you come from. Or using VPN. Wrong browser with insufficient base for uBo. uBo configured wrong. (Not?) using an ad-blocking DNS-Server, so that shit doesn't even make it to your local uBo?
Tested from Hamburg, Germany via private tunnel from my home in Colorado, which also works.
Threat intel of the IP or network you're coming from matter as much as anything else. FirefoxLinux on a clean IP can access places ChromeWindows on a dirty high-risk IP cannot.
Maybe the times are changing. Went through with Adblock and vpn. No looping.