> But now you're talking way more work, and yet another IR. What makes you think every abstraction layer has to be an IR? There's a reason we moved away from "

> But now you're talking way more work, and yet another IR. What makes you think every abstraction layer has to be an IR? There's a reason we moved away from "assembly language" looking things: so we can think at a higher layer of abstraction and not worry about how a machine implements it. > A developer wants to develop the code they wrote. Again you're looking at it the wrong way. The generated C code _is_ the developer'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 "assembly language" looking thing is that it has to be 'human readable'. This is an entire approach quite orthogonal to the previous two approaches: - shoehorn hand-picked fixed abstractions (like OO, templates) on top of C using cryptic syntax (the C++ approach) - 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). It turns out both approaches have turned out to be quite unsatisfactory for game programming. If you don'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.