One of the best labs I ever did in university (this was circa 1970), was to create an Initial Program Load (bootstrap) program for a virtual IBM System/360, which copied punch cards, using no OS assistance. (Modern zSeries I/O is so complicated that you'd never ask people to write it bare, but the 360 was just barely manageable for that.)
I think that wrangling with a computer in the absence of an OS is the only way for a person to understand what the OS is actually doing for you. It's all very nice to study synchronization schemes or memory management, but the methodologies all seem pretty abstract until you have to face a real computer.
Burgess reputedly disliked the American edition's inclusion of a glossary. I'm in partial agreement with that.The right way to read it is to let the language flow over you, and you gradually start making sense of it. The glossary is useful in demonstrating how brilliantly constructed the Nadsat language is, especially the words derived from Russian: horrorshow from khorosho, good; lewdies from lyudi, people; and starry from starei, old.
I disagree with much of Burgess's politics,but his use of language was masterful.
I second the recommmendation, for these two systems with a caveat. MIT Scheme has not been made to run on Apple Silicon, though with a few tricks, the amd64 version is usable on a modern Mac (this will presumably go away once Apple takes away Rosetta2). Racket might therefore be a better choice.
It is possible to use pretty much any decent Scheme system with SICP, but the language has changed since even the Second Edition, so I don't recommend it. That said, once you are working on your own projects, nothing stops you from using a different system, even though you might have to RTFM to see modern equivalents to ancient idioms.
I always got a chuckle when Stargate went meta. They had a planet called Kelowna (a real BC city) and a country called Langara (I was for a time a faculty member at Langara College). At one point, they visit an Oregon town called Steveston, with the location being the Steveston district of Richmond BC.
Of course, nothing can beat the thrill of waking up every morning and looking out my bedroom building at the office building that was taken over by an evil computer on X-Files.
I did that kind of thing when I first started using C (my attitude then was that C was fine, but it should have looked more like BCPL). I stopped after a short time.
I was puzzled by this claim, too. I think that the article is wrong, and that the code is written in HAL/S, a NASA-only language that sort of started off as a preprocessor to Fortran, though it has some PL/I-like features. If it really was written in Fortran, it probably was in a vendor-extended Fortran IV, which a lot of old guys like us know. But NASA used HAL/S for a number of projects, including the Shuttle. (And, by the way, thanks to perplexity.ai, here's a link to the HAL/S language manual: https://archive.org/details/nasa_techdoc_19750002029.)
The parent comment is apt. Of course, languages have their own quirks. But, as Christopher Strachey is once claimed to have said, “I use the same language no matter what compiler I run.”
Now what is more likely to be true is that the code is strangely structured (both because structured programming was new then, and because of memory and processor limitations), and also that much of the internal documentation has been lost. I wish the article had been clearer on that.
Versioned files existed in Tenex, developed by Bolt Beranek and Newman in the early 1970s; version numbering was based on a similar feature in MIT's Incompatible Timesharing System. DEC's variant of Tenex was eventually called TOPS-20. Many features of VAX/VMS were influenced by Tenex/Tops-20.
This is great...I would encourage you to add the ability for users to offer new languages. I noticed that Modula-2, PL/I, Trac Language, ALGOL 60, ALGOL68, and Joss/Focal could be added. (ALGOL 60 would be a challenge, as the originally-defined language had no input/output!)
Actually, variations on M-expressions have been created many times in the Lisp world. (Look what you can do with macros!) So far, none of them has caught on. The latest attempt for Scheme is SRFI-266, which creates a very nice infix expression sublanguage. If I were working on a team, I would encourage them to use this, but I don't know if it has enough traction to become widespread.
I'm on a convertible as I read this comments thread; I'm typing this comment on the keyboard, and scrolling the comments via the touchscreen.
I have never bought the argument that there should be one modality of input (or output). I'm basically a keyboard guy, but I use a pointing stick, mouse, trackball, or stylus/touchscreen as appropriate. Some applications benefit from direct contact, others really prefer keyboard input. Further, various disabilities prioritize modalities as well: someone may have serious trouble typing or pointing, and visually-impaired people may prefer voice and speech.
So all these rhapsodies of fingers flying across the keyboard or pointing on a touchscreen as the One True Way miss the point. I want my computing devices to support the kind of interaction I want to engage in, which differs from application to application and time to time.
“There are two novels that can change a bookish fourteen-year old’s life: The Lord of the Rings and Atlas Shrugged. One is a childish fantasy that often engenders a lifelong obsession with its unbelievable heroes, leading to an emotionally stunted, socially crippled adulthood, unable to deal with the real world. The other, of course, involves orcs." -- John Rogers
And just to point out that there is WinCompose, for Windows, and a somewhat janky but usable solution using Karabiner Elements and macos-compose for Mac.
I was present at the IFIP 1978 conference in Toronto where Dijkstra announced that personal computing was a dead end because most people don't know how to program.
There's an irony about the design of ALGOL 68. It was denounced at the time as being too big a language, with too many experimental features. In fact, the language in the Report is unimplementable, primarily because the lexical syntax is fanciful (there's an actual difference between the roman period and the italic period) and also abstract (so no two implementations actually have the same lexical syntax). I was on the periphery of an ALGOL 68 implementation project that foundered because the goal was to implement every conceivable edge case, include those that could never occur in practice, e.g., x[i] := x[...50 pages of code...] Yet very reasonable subsets (including ALGOL-68R and FLACC) were built. As for the language breadth, arguably C# is much broader, and I haven't heard anyone claim that it is a failure.
As for the Report...there was a time when I understood it cover to cover. But Lindsey and van der Meulen's Informal Introduction presented the whole language at a level understandable to anyone who understood ALGOL 60. van Wijngaarden did the language a terrible disservice when he forced (that is the correct word, I believe) the use of two-level grammars in order to ensure type correctness. Had the Report never existed, the language would have had much more traction.
The irony? Apart from the grossly-overengineered “transput” library—much better adapted to a unit-record and line printer world than our modern world—the one actual experimental feature in the language was the par clause, which provided parallel execution, and relied on semaphores for synchronization. Dijkstra's semaphores.
I think that wrangling with a computer in the absence of an OS is the only way for a person to understand what the OS is actually doing for you. It's all very nice to study synchronization schemes or memory management, but the methodologies all seem pretty abstract until you have to face a real computer.