
Among his admonitions for writing user manuals is this:
Read. Books on overall style are a matter of personal taste. Our own favourite is Strunk (1959). As examples of good writing on technical matters, we especially like the works of D. E. Knuth and of M. V. Wilkes, and also the book "Software Tools" (Kernighan and Plauger, 1976). Perhaps the most pleasant of all writing on technical matters is in the field of gardening, not computing; read "The Small Garden" by Lucas Phillips (1952) and not only your turnips but also you writing will improve.
1. Peter John Brown. 1979. Writing Interactive Compilers and Interpreters.
2. Timothy Budd. 1987. A Little Smalltalk.
3. Ralph E. Griswold. 2000. The Icon Programming Language, 3e.
4. Pat Shaughnessy. 2013. Ruby Under a Microscope: An Illustrated Guide to Ruby Internals.
This is a new one I haven't read yet, but it looks very practical:
5. Clinton L. Jeffery. 2021. Build Your Own Programming Language: A Programmer's Guide to Designing Compilers, Interpreters, and DSLs for Solving Modern Computing Problems.
I don't know anything about this one, but people have told me they prefer the first edition:
6. Ronald Mak. 1991. Writing Compilers and Interpreters: An Applied Approach.
HP TSB did not have a REPL. If your program crashed or stopped you could not examine variables from the terminal. You could not peek or poke memory locations as you could with microcomputer BASICs (which didn't support multiple users, so didn't have the security concern). You had to insert PRINT statements to debug the code. TSB BASIC didn't have compile/link steps, it tokenized the code as you entered the lines, and the interpreter amounted to a big switch statements on the tokens. P. J Brown's book Writing Interactive Compilers and Interpreters (1981) describes how TSB works. Eventually I got the source code to TSB (written in assembler) and figured it out for myself.
Other BASIC implementations that popped up around the same time had richer feature sets. In my senior year at high school I got (unauthorized) access to a couple of Unix systems in Portland, ordered the Bell Labs Technical Journal issues that described Unix and C, and taught myself from those. I didn't get paid to work on a Unix system until several years later (detours into RSTS-11, TOPS-20, VMS, Microdata, Pr1me, others) but I caught the Unix and C bugs young and I still work with those tools every day.
Some programmer friends and more than a few colleagues over the years have made fun of my continued use of what they call obsolete and arcane tools. I don't mind, I have never felt like I did less or sloppier work than my co-workers, and my freelance customers don't care what I use as long as I can solve their problems. Most of the work in programming doesn't happen at the keyboard anyway. I do pay attention and experiment with all kinds of tools but I usually end up going back to the Unix tools I have long familiarity with. That said I did spend many years in Visual Studio, MPW, CodeWarrior, and MPW writing C and C++ code, and I do think those tools (well, maybe not MPW) offered a lot of benefits over coding with vim and grep, for the projects I did back then.
Maybe ironically I use an iPad Pro, I don't have a desktop or laptop anymore. So I have the most modern hardware and a touch-based (soon) AI-assisted operating system that runs a terminal emulator during my work time.