Ask HN: Where do I find good code to read?

In the early 1980s, I inadvertently agreed to produce a 100-page manual for the student programming environment I had designed and implemented at the University of BC. I stupidly decided to do it in TeX. The stupidity here was that (a) the only laser printer on campus was in another building and (b) the TeXBook didn't exist yet. All I had was a listing of a late prerelease of the Web source of TeX, along with some of Knuth's writings about TeX77, which was a substantially different system. I managed to do it, including formatting much of the manual in the style of Unix man pages (the environment itself lasted for several years, until mainframe timesharing for students went away for good). When I finally got my hands on the TeXBook, I found that I had learned much about TeX, including a few things that weren't so :).

Knuth's programming style is highly idiosyncratic, and there are many points with which I'd disagree. Furthermore, the choice of Pascal required all sorts of strange compromises. That said, I highly commend reading the source of TeX, to see how a brilliant computer scientist attacked a problem that is not nicely structured, using very restricted programming tools. You will not get much that you can copy into your programs, but it is an excellent, well-documented attack on an interesting and complex problem. (By the way, Knuth's TeX was written long before modern typesetting things like Unicode, PDF, and OTF fonts; you don't want to use Knuth's TeX for modern work; I use LuaTeX. But Knuth's version remains as a useful subject of study.)

Another good thing to study is Lions's commentary on Unix V6. This is interesting because it shows many of Unix's key abstractions implemented in a few thousand lines of code.

NetBSD source. Exemplary for C code and astoundingly well documented.

One thing to look for are programs that use advanced techniques as opposed to programs that are just simply clear or well-commented. For instance, instead of learning a new programming language, you should learn how programming languages are made. Most of the secrets that computer science majors know that you probably don't were learned in compilers class.

(Unfortunately many people are chasing the Holy Grail of "functional programming" and never finding it because "functional programming" is a pale shadow of what's possible when you understand how compilers work: this is how Common LISP and scheme are so much more profound then, say, Haskell)

It's a little out of date but I was lately thinking up about the Scott Adams adventure games of the early 1980s that were written with a specialized interpreter which could be implemented in BASIC but was also implemented in assembly language for better performance. See

https://ahopeful.wordpress.com/2020/09/13/digging-up-adventu...

If you tried to implement a game like that directly in a language like BASIC you would be driven nuts because that kind of game is fundamentally "object oriented" in that there are a number of things like rooms and items that are all mostly the same except they are different in some ways and trying to code that with IF, THEN and ELSE is bad enough even before GOTO gets added to the mix. The thing is that GOTO becomes quite benign and even useful when it is used to implement interpreters.

So back in the day you would study systems like that to stretch your skills, today I would look at compilers and related technology, like the Jena rules engine.

This is what "top down" coding looks like. In "top down" coding you're told what to do by the boss, given too short a timeline, and forced to push something out the door.

Congratulations on figuring out how to create a massive churn rate among your actual good engineers.

This looks excellent, thanks for sharing.

It also links off to this which looks like a good read https://third-bit.com/sdxjs/