Listing all the things bad about it would take me the rest of the afternoon, and likely evoke many replies along the lines of "you don't understand why he does

Listing all the things bad about it would take me the rest of the afternoon, and likely evoke many replies along the lines of "you don't understand why he does it that way, it's supposed to be handmade, so you can't have all the nice things", like last time I commented about the HH code. The executive summary would be that the code is basically full of unsafe code, pointer chasing, half-hearted argument/input validity checking, no memory management, no abstractions of the higher-level parts of the code, it uses none of the idioms we've learned through years of writing crap code to avoid common mistakes (RAII would be a good example, etc), doesn't use 99% of the language features C++ offers over C. Casey himself dismisses these things as adding unnecessary bloat and/or mental overhead, that they have no benefits for his purpose, and that the way he writes code you don't need them, but I just flat-out disagree with that. Let me make clear that I'm not saying this because I don't like HH or because there's nothing to be learned from it, just that the results you get from this programming style should not be taken as an example. The quality of the code is immediately apparent if you watch Casey work on it in the streams, almost every line he changes breaks something somewhere else in the code, often even multiple things.