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.
In the 1970s, I temporarily relocated from Vancouver to Boston. A few days after I arrived, someone said, “After work, I'm going to take the T [subway] to BC.” I was awed by the concept of a continental mass-transit system, but puzzled. It turns out that in the Massachusetts Bay area, BC is Boston College.
With all due respect to Wirth, P-Code did not originate in a vacuum. Martin Richards's BCPL compiler, dating from the late 1960s, targeted a hypothetical OCode machine. Furthermore, although there were backends for this that generated good machine code on popular computers of the time, Richards also had a backend that generated a severely reduced instruction set, which he called Intcode. You could write an assembler and interpreter for Intcode in a few hundred lines of Fortran (I did), which meant you could have a slow BCPL implementation on a new machine in a day or so's work, and then you could write a better backend in BCPL.
I have never been able to determine whether Wirth knew of this work, but, given that Richards's 1969 BCPL paper described OCode, I suspect he was aware of it, and that it influenced his design of the Pascal-P compiler. (I am not sure when Intcode appeared, but it was present when I obtained the BCPL compiler in 1972, a year before the Pascal-P release.)
With all due respect to Martin Richards, neither did his BCPL, given that bytecodes as idea go back to compilers being developed in 1950's after FORTRAN came to be, and was already part of CPL ideas anyway.
If fact there were all operating systems written with such ideas like Burroughs B5000 in 1961, nowadays still sold by Unisys, and thanks to this approach being easily retargeted to modern hardware.
Why this "who did it first thread?" in first place?
You had commented before I created a new account, so I will just add that I have never seen Wirth claim that he or his colleagues at ETH were the originators of the idea. Moreover, this idea was already used in Wirth’s “first” language, namely Euler, which he published in 1965 while at Stanford. An even earlier example may be Schorre’s META‑II from 1964 (UCLA).
Regarding the popular opinion here that Pascal was created for educational purposes (only) - implicitly meaning not for building real, large-scale software - Wirth considered these two characteristics equivalent, and in his view one was a necessary condition for the other.
From the summary/abstract of his original publication about Pascal (The Programming Language Pascal) written in 1970 and published in Acta Informatica in 1971:
In view of its intended usage both as a convenient basis to teach programming and as an efficient tool to write large programs, emphasis was placed on keeping the number of fundamental concepts reasonably small, on a simple and systematic language structure, and on efficient implementability.
The original paper is probably behind a paywall. But you can have a look at an excerpt (chapter 2) from the book Virtual Machines (2006) by Iain D. Craig.
Your last link (BCPL history) contains links to a lot of papers (all?) by Martin Richards one of which is (pdf) INTCODE - An Interpretive Machine Code for BCPL which i presume was what "vincent-manis" was referring to in addition to the other papers on BCPL Language/Compiler/Manuals. Seems quite comprehensive, i must say.
We really need to publicize all of Martin Richards' contributions to computer science. He seems to be one of those unsung heroes mentioned everywhere having contributed to Languages/Compilers/VMs/OSes but not that well-known.
From the site;
BCPL—the language and systems built with it—connects the first few generations of computer scientists and software engineers, spanning mainframes to minis to micros. It was driven from the UK, but with a tributary into the heart of US research institutions, where it begat C, the most popular systems programming language of all time.
I found the article tedious, even though I agree with its main point. However, the so-called “obvious” signs it was written by an AI—quotation marks and em-dashes—are within the ability of anyone with a Compose key (on Linux/BSD, ask your window manager or DE; on Mac, Karabiner; on Windows, WinCompose).
reply