Your last rant about APIs at the end of episode 135 prompted me to write this post.
In a nutshell, from ranter to ranter: I love Handmade Hero, but I sometimes wish I could watch the arrogance-free version, if that makes sense :)
I've been following Handmade Hero development pretty much from the start, and I've watched most of the episodes (on YouTube, for timezone and schedule reasons). It's a fantastic initiative, and I'm looking forward to watching many more hundreds episodes.
I respect the message and attitude you're trying to convey through the episodes: keeping things simple, "compression oriented programming", focusing on the useful development rather than on "administrative cruft", etc. I share many of the same sentiments. I'm also equally saddened by the state of affairs in our industry.
However, I feel that you're sometimes unreasonably critical of the technology choices or development practices of other people, teams and companies. I'm regularly surprised--and annoyed--by the lack of humility and balance in your discourse, especially coming from a mature programmer.
Not everyone is working on a small 2D game that can realistically be implemented from scratch without relying on a single third-party library. Pretty much all games or game engines rely on third party libraries because there are no other sensible ways to provide the basic functionalities player or game developers have come to expect.
Let me be clear: I absolutely understand why you're writing HH the way you do, and I praise the effort. It makes complete sense. I also realize that you have your own style, tone and persona, and, like a Charles Bloom, ranting is part of the show (and the character).
What follows are a few specific things that bothered me about that API rant in episode 135. I hope none of it is too obvious.
First, Dependency Walker does not fail to load dependencies "because there are too many". Most of the time, missing dependencies are not a problem because the application is prepared to handle them being missing.
Let's be fair: There are way fewer dependencies than you think. For instance, most system dependencies such as kernel32.dll, ntdll.dll or user32.dll, as well as runtime libraries such as msvcrt.dll are repeated over and over. What you seem to have missed about Dependency Walker is that it shows the dependency tree: most DLLs rely directly or indirectly on the same set of dependencies, themselves relying again on the same set of dependencies, over and over. The actual number of dependencies for devenv.exe is probably a few orders of magnitude lower than what you seem to think.
Now, is it really surprising that Visual Studio's IDE rely on many third party libraries? For better or worse, VS is a large application catering to a wide audience: native C/C++ developers, C#/VB.NET developers, Web developers (HTML/JS/CSS/XML/XSLT...), mobile apps developers, etc. It features many tools and custom editors whose existence most users don’t even suspect. It's just to be expected that Visual Studio relies on many external modules, some developed in-house at Microsoft, some developed by external or acquired companies, etc.
Regarding the overall DLL situation in Windows: I agree that it's a mess. However, I do not agree that it was caused by incompetence or "mediocre programmers" that "drowned the great kernel programmers". Rather, I believe this is the unfortunate messy nature of large scale software development.
I encountered this again and again in my job (mostly working on high-end rendering software), and if you worked on any large software, you probably did too: Despite all the good will and competency of development teams, software architecture and code often become less than beautiful because requirements change, technologies evolve, employees come and go, etc. Refactorings and cleanups are started but are then interrupted for a variety of reasons: employees leaving or being moved to another team, more pressing development tasks popping up, etc. This hasn’t much to do with incompetence (unfortunately!).
Here is an interesting article on this very topic: The Lava Layer Anti-Pattern.
Regarding side-by-side assemblies in Windows: How would you solve the following classic problem which I'm sure you're familiar with: As a Microsoft developer, you need to fix a bug in a platform DLL (say, in DirectX). Unfortunately, you realize that many games (voluntarily or not) actually rely on the incorrect behavior, and fixing the bug would break those games. There aren't many options: you could keep such bugs forever; you could fix the bug and break those games; or you could keep the old DLL for those games, and provide a fixed DLL for newer games, losing a bit of disk space (and, possibly, sanity) on the way. Microsoft has pretty much always chosen the last option.
Despite your sentiment, Windows is by far the most backward-compatible consumer operating system the world has ever seen. It's not all happy bunny, but you surely realize what a feat of engineering this is, when you consider the scale and breadth of the product... The "layers of cruft", the SxS stuff, and the overall apparent complexity is what permits this feat.
Keep up the awesome work on HH, and keep ranting. Simply keep in mind that you are a role model to a growing audience, and that your opinion carries much weight. As such, a bit more humility and understanding certainly cannot hurt!