&gt; But now you&#x27;re talking way more work, and yet another IR.<p>What makes you think every abstraction layer has to be an IR? There&#x27;s a reason we moved away from &quot;assembly language&quot; looking things: so we can think at a higher layer of abstraction and not worry about how a machine implements it.<p>&gt; A developer wants to develop the code they wrote.<p>Again you&#x27;re looking at it the wrong way. The generated C code _is_ the developer&#x27;s code. An amplify-C developer would generate C code with the very purpose of looking at it. And the reason it has to be C and not an &quot;assembly language&quot; looking thing is that it has to be &#x27;human readable&#x27;.<p>This is an entire approach quite orthogonal to the previous two approaches:<p>- shoehorn hand-picked fixed abstractions (like OO, templates) on top of C using cryptic syntax (the C++ approach)<p>- working at a higher layer and never having to deal with C but instead generating IR for a virtual machine (the Java, Perl, Python, LLVM-client, approach).<p>It turns out both approaches have turned out to be quite unsatisfactory for game programming. If you don&#x27;t like this new approach, so be it, but unless you have an evidence of how game-programming is thriving on top of a VM model, you have to give them a break.