Essentials of Compilation

When I did the same almost 30 years ago, we used graphical debuggers, namely Turbo Assembler debugger.

GDB isn't the only game in town, and even so, it has graphical debuggers as well.

So I see that more as a failure of teaching than anything else.

As for WebAssembly, I actually agree, if anything else it is now fashionable and that motivates students.

I'd say go further than that and focus on writing course material as "applicative literature"—something akin to an executable textbook. Once you're in this mindset, it's natural to recognize that writing your tools so they run in the browser is not just something that can be done, it's the way it should be done for that context. In terms of accessibility and portability, there's nothing that comes close.

I once wanted to write the spiritual equivalent of objdump(1) for an esoteric object file format and operating system. One implementation was already written as a native utility for that OS itself, but it was kind of a chore to deal with if you weren't directly using that system as your development environment. So I was facing the task of porting the utility, and since the situation around that compiling that language into runnable binaries outside that system wasn't great, "porting" really meant rewriting it. But that was actually the easy part. The hard part was deciding which language to use and which platform to target. It couldn't be guaranteed that others with an interest in using it themselves would be able to do so if I made the wrong choice—I knew that many others were on Windows, and a few on Mac.

I ended up realizing that I needed to write it to run in the browser, and doing it was friggin' trivial, despite what all the JS haters and JS lovers alike would seem to want you to believe.

I wrote it in JS as a single file foo.app.htm, which when double-clicked opens in the browser. The whole thing from top to bottom was less than 2000 lines written in a boring late 90s OO style that anyone coming from a mainstream language should be able to grok. When you open it, it puts a button on the screen, which gives you a filepicker, and you give it your object file, and then it dumps the output onto the page. But the ubiquity of browsers notwithstanding, I didn't want to actually have to switch to a browser window to use it, so with a little trickery I made it so I did some stuff that let me use that same foo.app.htm from the command-line using a single command. So now I can point it to any file and get it to dump its output to the terminal instead, similar to a traditional CLI app. And it's fast, too. I've since done this with a few other apps, including one command-line app that was written in Java. My naive, straightforward, totally unoptimized port to JS is able to spin up a new process, get its code parsed, do all its work, and then terminate all faster than the equivalent Java program—that that it matters since both complete in under a second, but still. Better than Java, though, it retains the benefits that it, too, can run in the browser, so I could give this baz.app.htm to almost anybody to double click and use on their workstation without any care that they've set anything up beforehand, almost like the situation with Go's statically linked binaries.

The unfortunate thing I've noticed with a lot of WebAssembly stuff, on the other hand, is that the common ritual is made up of a bunch of practices imported from traditional, non-portable toolchains, e.g. LLVM junk. I've commented before how even JS-infatuated developers like those who congregate in and around NodeJS and NPM make this weird trade <https://www.colbyrussell.com/2019/03/06/how-to-displace-java...>. (I mean, surely if you're writing JS, then the thing to do would be to make sure it will run using the engine that everyone already has on their computer, right? Otherwise, what's the point? If you're going to go the opposite route and make people people download and configure a completely separate toolchain, like some unwieldy TypeScript+Yarn+Webpack monstrosity running on NodeJS, inside Docker, and cursed by Zalgo, then why not go full bore and just... go for a conventional setup and write it in something else? You're already paying the cost and get none of the it-runs-in-the-browser benefits. See also <https://news.ycombinator.com/item?id=24495646>.)