Programs source code is just as copyrighted as late 20th century literature.
However, it's not generally available (unlike late 20th century literature). If windows sold with the source code (even if you were forbidden from doing anything with it), then we would be reading windows source code in our CS classes.
Microsoft even had a "research kernel" they licensed out to unis, and we did read (parts of) that in CS classes. (but still of course very different than actually having the full source of real systems through history available for general study)
Ride the mach continuum between the micro and monolithic.. not really interesting. Basically opening up user mode device drivers or user mode code in the kernel (sandboxes).
MMIX is not bullshit. Knuth is interested in concrete complexity as well as asymptotic complexity, e.g. why quick sort is faster than heap sort, so he needs concrete model of computation. It may be an overkill if you aren't interested in concrete complexity, but it serves a purpose.
There’s a reason why no one explains abstract algorithms in assembly. It’s a trash idea, that obscures more than it illuminates. It’s a flex. A flex that is marginally above explaining an algorithm through a wiring diagram of thermionic valves.
I don’t think agreeing that no one else on the planet writes examples in assembly is the dunk you think it is.
Have you ever heard of anyone reaching out of those books, or even read all of them? He maybe heralded because of when we wrote them, but there are much better written books in 2021.
While there is only one Joyce, please tell me how build 627252 of Windows 3.11 glonkglonk.cpp is a unique example that provides more insight into a heap, than five lines of pseudocode.
"Here's 5 lines of pseudocode" "Here's a real-world implementation of the pseudocode. Note this section does not improve the asymptotic case, but has significant constant-factor advantages for small inputs."
[edit]
I noticed you mentioned "heap" assuming you're talking about the data-structure, that would probably be in a different class than one where you read windows source code. Just like you probably wouldn't read Joyce in a class on composing newspaper articles.
I still think it's useful to dissect existing code to get an idea of how complicated it really can be. A CS undergrad may graduate without ever reading or writing a single program over 1kloc. Even from an academia perspective, having a concept that real-world software is usually 100s or 1000s of kloc is likely useful.
A typical experience when I re-implement a technique from an academic paper:
1) Read the paper's high level description and pseudocode.
2) Write some test cases.
3) Write code based on the paper's pseudocode.
4) Observe that my test case results do not match what the authors show.
4a) Fiddle repeatedly with possible ambiguities in the pseudocode-to-real-code translation until test cases match publication. This involves a certain amount of mind reading and speculation. "They said argmax, but there are possible singularities... maybe argmax followed by clamping."
4b) Request source code from the authors. Upon receiving it, find that their real implementation diverges in small but significant ways from the pseudocode that was published. They have mixed actual-code algorithm outputs with incomplete pseudocode algorithm descriptions in the paper.
However, it's not generally available (unlike late 20th century literature). If windows sold with the source code (even if you were forbidden from doing anything with it), then we would be reading windows source code in our CS classes.