> He compared Visual C++ 6's debugger on hardware from the time to current Visual Studio's debugger on current hardware, and found the former much faster when performing the exact same tasks on the exact same project file and code files.

this shouldn't be right, wtf

It's right.

When did you start using computers? I'm getting older now, and some people weren't alive when I first used a computer.

It's because the older programming approach was to just tell the computer how to do the thing - and the modern approach is to write a framework inside which you write a framework inside which you write an inefficient version of the thing because it's constrained to the tools available in the framework stack.

Old-school implementation of "scroll up": copy pixels then redraw the pixels at the bottom.

New-school implementation of "scroll up": delete virtualized rows from the beginning of a DOM table and add more to the end. Change the height properties on different parts of the scrollbar. Relayout the whole DOM, several times if you're not careful. Redraw the whole screen.

From what I heard from Visual Studio folk it is surprising it is not orders of magnitude faster rather than "much faster".

Also I learned to program in Turbo C and Turbo Pascal with its debugger and nothing comes faster (at least nothing single threaded)

VC++ 6 was an amazing IDE. My favourite of all time, with the debugger being one of the highlights. Still unmatched today.

Yes, it really shouldn’t, and so Casey goes to great and careful lengths to fully evidence these results. This is a nuance that’s easy to miss in evangelizing “Casey Muratori content” to others. It’s easy to gloss “abjectly unacceptable performance” as “bad performance”.

https://www.youtube.com/watch?v=GC-0tCy4P1U at 21:30 for modern Visual Studio and then 35:51 for Windows XP era Visual Studio.