3 ms·

Hi, Michael. I'm familiar with Oberon and have contributed to Peter De Wachter's Norebo bootstrapping scripts. I wrote a recent comment in another thread abou

by cxr 6y ago

Hi, Michael. I'm familiar with Oberon and have contributed to Peter De Wachter's Norebo bootstrapping scripts. I wrote a recent comment in another thread about the use of "applicative literature" in pedagogy. <https://news.ycombinator.com/item?id=25490826 https://news.ycombinator.com/item?id=25490826> Rikke's README for this project—and many other projects related to Oberon—end up describing processes in natural language, with steps to be performed manually, e.g. to change the bootloader. This is not special to Oberon, though. The gist of my argument is that pretty much every student and professor already has a suitable environment for handling process documents that could be adapted to be also executable by a machine. Do you have any thoughts about this? Do you have any experience trying to work with anything that follows Knuth's "literate programming" paradigm (including difficulties you've encountered)? Anyway, nice work by you and your students. Wirth's RISC machine has a simplicity that others don't, which makes it good for teaching, but it makes some pragmatic choices that make it more realistic than similar attempts that result in toy computers that are a little too toy-like. It's work like this that makes for a decent transition after going from not knowing anything about a computer to hands-on understanding using a practical fantasy system like Wirth's to a full-on "industry-approved" instruction set RISC-V.

johndoe0815 6y ago
Literate programming could solve some of our everyday problems, such as discrepancies between documentation and implementation (in contrast with often hard to use automatically generated documentation e.g. using JavaDoc). I'm not sure why it never caught on - perhaps most programmers rather want to work on code and not on explaining it... While not as elaborate as Knuth's WEB system, I liked the approach used by Douglas Comer in his Xinu OS books (my first OS textbook) very much. Comer's integration of explaining text sections and related code is not as tight as some of the commonly mentioned literate programming examples, but IMHO it still helps a lot to understand the system structure and the dependencies of the piece of code discusses with other parts of the system. What is great about the Comer books is that - like Oberon - they also cover more than just the OS. In the original version of the Xinu book, there was an extensive explanation of the PDP11 the system was developed on, though not on a sufficient level of detail to actually build a PDP11. While Comer doesn't include a compiler or GUI in Xinu, he extends the system in another useful direction with Xinu-based Ethernet and TCP/IP support in a second volume. The Project Oberon book includes a short chapter on networking, but this is a point where the "not-invented-here" paradigm that helps to keep the Oberon system so simple and elegant seems to break down, as real-world interfacing is essential today. The difference in complexity between the homebrew approach and TCP/IP is easy to see, however. Networking is covered in a single chapter (IIRC) in the Project Oberon book, whereas it took Comer a whole book volume to describe his TCP/IP implementation (admittedly, also including the description of a number of network protocols on top of TCP/IP).

by cxr 6y ago

johndoe0815 6y ago

Literate programming could solve some of our everyday problems, such as discrepancies between documentation and implementation (in contrast with often hard to use automatically generated documentation e.g. using JavaDoc). I'm not sure why it never caught on - perhaps most programmers rather want to work on code and not on explaining it... While not as elaborate as Knuth's WEB system, I liked the approach used by Douglas Comer in his Xinu OS books (my first OS textbook) very much. Comer's integration of explaining text sections and related code is not as tight as some of the commonly mentioned literate programming examples, but IMHO it still helps a lot to understand the system structure and the dependencies of the piece of code discusses with other parts of the system. What is great about the Comer books is that - like Oberon - they also cover more than just the OS. In the original version of the Xinu book, there was an extensive explanation of the PDP11 the system was developed on, though not on a sufficient level of detail to actually build a PDP11. While Comer doesn't include a compiler or GUI in Xinu, he extends the system in another useful direction with Xinu-based Ethernet and TCP/IP support in a second volume. The Project Oberon book includes a short chapter on networking, but this is a point where the "not-invented-here" paradigm that helps to keep the Oberon system so simple and elegant seems to break down, as real-world interfacing is essential today. The difference in complexity between the homebrew approach and TCP/IP is easy to see, however. Networking is covered in a single chapter (IIRC) in the Project Oberon book, whereas it took Comer a whole book volume to describe his TCP/IP implementation (admittedly, also including the description of a number of network protocols on top of TCP/IP).