> You'd like to pay money to be assured that you're right?
I know I'm right, I'd pay money to see the embarrassment of the presumptuous Clean Code people who think that they can write maintainable code better than those who write software that matters (like Linux or Postgres, as mentioned before).
> So, your thesis is that writing a terminal emulator - software which is pretending to be hardware that existed 40+ years ago, shows that this person is great at handling surprising requirements changes during development ?
No. My thesis is that this guy can write code better than people who are supposed to be in the top 1% of the developers (well, it's Microsoft, not a web app sweatshop).
He works on games, where you not only have to iterate very quickly but you also may need to completely change direction halfway through the project. They can't have an "unmaintainable mess", otherwise they're not shipping the game, so your premise is wrong from the start. Also, games are much more complicated to program than the average Clean Code Crud app project that Uncle Bob bikesheds on.
> An insistence that the only thing we can measure is performance and specifically speed and therefore that's the only thing that matters is nonsense
Nobody said that, how are you coming up with this stuff?
The point Casey was making is that you're paying a significant performance penalty (speed, in this example) by doing Clean Code, which is true. You're denying yourself very basic performance techniques if you close your eyes and pretend to not see the internals of each shape.
> Try it, first add the hollow box example shape,
What if you don't have to? What if those are all the shapes you have to support? But there's ten billion shapes, you chose to do Clean Code and now you have slow code for zero benefit. Ouch.
On the other hand, if you want to add more shapes then the problem you're solving changed, and therefore you need to change the code (not really the tragedy you're making it out to be). I don't get this obsession, "code should change as little as possible"; it's actually a "careful what you wish for" moment because class hierarchies tend to become very rigid and difficult to change. Good luck making significant changes when your 100k+ loc program relies on a particular class hierarchy being in place.
> the iterators produce exactly the same machine code
That's great but it seems you're trying really hard to interpret Casey's video in bad faith. The way I understood it, he used an old fashioned for loop to avoid detracting from the main discussion, as not everyone knows what are the internals of STL iterators and how they translate to machine code.