In Unicode it's named "NULL", line one of UnicodeData.txt[1] is `0000;<control>;Cc;0;BN;;;;;N;NULL;;;;`. Unlike ASCII characters Unicode code point names can be more than 3 letters.
Bytes are not strictly ASCII. Even within the realm of ASCII, if you have a binary with strings terminated in 0x00, those aren't generally called "NUL-terminated strings".
Depends on when "back in the day" was; even in the mid-to-late 80s, especially if you were on a multi-user system, on BSD 4.2/4.3 local and networked printer access went through the Line Printer Daemon (still available on the BSDs).
For PostScript printers, there was a filter application (provided by Adobe) that would turn plain text (without the %! magic) into PostScript.
At a previous employer we generated assemblers and disassemblers for various DSP cores based on an Excel spreadsheet that the software tools team shared with the processor architects. The spreadsheet cells described the layout of the various instruction fields; this was converted with a script to an architecture description DSL, from which the assembler, disassembler, and other tools could be generated. Another DSL described the pipeline stalls and hazards, and code generated from the combined descriptions drove instruction schedulers and code checkers.
While I couldn't find any characters with more than three or four readings in this list, the Taiwan list (https://language.moe.gov.tw/files/people_files/%e5%88%9d%e7%...) has one character with five readings (著) and one with six (和). Still a long way from 15, though.
Overall this is helpful, but it seems a bit ranty, and doesn't do as much as (for example) John Day's Patterns in Network Architecture to provide a positive alternative model.
This is a serious criticism... even if it's not likely to catch on enough to have a real effect on the sea level, it is a complete waste of energy to accomplish something that could be done much more efficiently some other way, if it is indeed worth doing at all.
As a Guix developer (there's a lot of Scheme and Common Lisp in Guix :) ), every few years I check on Open Dylan but so far each time there was something missing that made me unable to package it for Guix (building it entirely from source).
I've checked it a few minutes ago and Open Dylan's ./configure says to download a bootstrap compiler from https://opendylan.org/download/index.html first -- but there's no such bootstrap compiler there.
The way you actually have to do it is trawling through git repos to find an old version of Gwydion, bashing at it for a while, and maybe getting it to compile on modern platforms. Look for 2.4, then rewind, then pass a config flag, and a few more steps.
I wouldn't call Dylan thriving, unless you're a Windows user that really doesn't care about bootstrapping your language.
It's alive though, in the same sense that Miles, the dog that Segall froze and then brought back to life in 1987, was alive. Brain damaged, but alive.
You can't bootstrap OpenDylan from source without a Dylan compiler. You can bootstrap Gwydion without one with substantial elbow work, which you can then pivot into bootstrapping OpenDylan.
I know what I was doing, and if you look elsewhere in the thread, I was right about what the GUIX maintainer wanted. Not to get egg on your face.
There's no special "bootstrap compiler"; you can download a binary release for your platform from the page you linked, and then use that to bootstrap a newer version from a source checkout. If it would help, we could provide a minimalistic build that was only useful for bootstrapping, but at present our builds are "batteries included" (with LLVM/Clang and the BDW garbage collector already provided in the tarball).
So for Dylan, we'd like to have a compiler for Open Dylan, not written in Dylan. (it can also require multiple steps to get up to Open Dylan--that would be fine)
It's not in the interest of our users to use binary blob compilers for bootstrapping.
We would also unbundle LLVM, clang and the bdw gc and use the ones from Guix.
I, for one, welcome my whitespace-surrounded operator overlords, but if you really don't want that you're welcome to use function-call syntax for them.
I think it would be great to experiment with building this sort of thing for an e-ink tablet, adding an enhanced layer of interactivity to by-hand notetaking.
My dream is combining a simple self-hosted programming system like smalltalk-78 with the kind of experimental notetaking systems demoed here and in other inkandswitch work (crosscut and untangle) on an e-paper based tablet (like the PineNote).