A year ago I made a version I call "Chromacline". Multiple populations of different colors duke it out. My implementation runs it on computers and phones without needing a browser.
Author here: Thanks! The 1 instruction will place the opcode received from the serial line or the keyboard to a fixed location in memory. Maybe store would be a better name. But store (!) in Forth is associated with a memory address.
The compilation term comes from the fact that at the end the memory map will be the same as the one compiled with an assembler.
Also in the Frank Sergeant 3 inst version. Load is used to load a memory address on the target and send it back to the host computer.
Feedbro is great. It has none of the arbitrary limitations that many of the web-clients impose for monetisation reasons.
The only downside (or upside depending on your perspective) is that it is a local solution. You can only access it on a specific device, and it won't be syncing when that device is turned off.
As the author of OP, I just want to say thanks for the comment. I don't disagree with any of it. I was experimenting with incendiary headlines 10 years ago when I wrote it, but perhaps a less incendiary headline is that others misinterpret Knuth by emphasizing typesetting over sequencing and structuring an exposition.
Part of my point was even if there was not an obvious place to put it, the mechanical place to put it is at the end! That's what I consistently did in the project I cited.
So I wasn't arguing for people to agonize endlessly about where to put it.
When I wrote OP I was thinking of html rendering as just another form of typesetting. Basically any method of reading something at a different place than your text editor. So markdown it itself is fine, but if you generate html from it and read that, that's "typesetting" that is taking you away from the tactile experience of working with code.
You're describing staged learning -- and the example at the bottom of my OP is trying to demonstrate exactly that. My https://akkartik.name/post/wart-layers describes the mechanism in more detail for starting from a simple example and gradually adding concerns.
It's true that the very first example a student sees shouldn't be some eldritch horror in all its complexity.
It's also true that in the real world today, people study eldritch horrors on their own after learning the basics in kiddie pools.
But we can do better than the way we've always done it. For key pieces of software that have eaten the world, it seems worthwhile to gradually chip away steps on the cliff side to help future learners more easily understand the real-world complexity.
> I constantly run into functions called doSomething that also do something else.
You have to have some trust in your fellow coders that doSomething doesn't do something else and this is often false. Still in most cases it doesn't matter on a first read as doSomething is close enough to only doing that something. LP won't help here anyway. Documentation can be wrote just as much as the function name.
You say LP is not about teaching the language, but the examples from Knuth himself are often documenting the language and not the codebase. This is a common problem with documentation.
As people repeatedly say in trying to rebut my OP, it's important not to cherry-pick examples. I try to be careful to find the best examples when criticizing. In that spirit, here's a couple of examples from https://cs.stanford.edu/~knuth/programs.html
https://akkartik.itch.io/carousel/devlog/651711/new-version-...