Here's a few of the main opposition points:
- execute_*() / object editing during execution - It's not recommended/advisable to use them anyway, as it's very easy for people to inject code, see your source etc. Also they bloat your executable with the library required to handle and execute GML. Nevertheless, for backwards compatibility and people who don't know better alternatives, just as the interpreter is included now, a compiler/assembler could be included, and run in a similar way to 'just in time' compilers like Java.
- Runtime error checking - This is still possible with compiled languages (although they do add bloat, but not nearly as much as interpretation). A compromise to this would be that it is optional whether runtime checks such as array bounds, (internal) null pointers etc are included - a system which would only be possible through a linker and thus the compile process. Runtime checks would be used for betas and development builds, but not for final binaries, where presumably the programmer would have sorted out all their bugs.
- Extra effort to create a compiler - Quite frankly, it isn't the duanting task it is made out to be, especially if you do not intend to beat commercial compilers such as Intel C. Even a simple, naively produced compiler will by far beat a completely unoptimised interpreted language like GML. The lexer/abstract syntax tree generator (frontend) should (depending on how Yoyo/Mark coded it) be adaptable from the current source code, in some form, leaving the emitter. As I said, if the objective is to reach a respectable speed, optimisations like SSA aren't needed, and even without I would expect speed increases in multiples of atleast 20x. Don't get me wrong, it's a big undertaking, but a company like Yoyo Games should seriously look into it.
- Loosely typed variables - Contrary to what some might think, this is still possible in compiled languages, through the use of an enumerated reference byte before variables defining their current type, followed by 4 bytes of either a pointer to a string instance, or numeric data, depending on context. This will increase memory usage compared to most languages, but GM already employs dynamic types, so this won't result in an adverse change.
- Speed - Clearly, there would be huge speed increases.
- Size - Even with runtime checking routines and a JIT compiler for on-the-fly coding, the executable sizes could be dramatically decreased by modularly including (via the linker) sections of GML's runtime library (graphics, sound, math functions and so on).
- More powerful, built in features, such as the inclusion of third party static libraries.
- Portability - The possibility, in the future, for more operating systems (if OpenGL, SDL or the like was used) support and even different architectures (ARM for portable devices, say). Of course, the latter would be a much more difficult task and would need a backend of its own for each new compatible system.
This was taken from this post, but it seems that topic doesn't really get much attention from people other than for their own feature requests, plus this is a topic which, IMHO, deserves its own... topic.
