3 ms·
Apart from the time and effort spent in writing the AOT compiler as the other poster mentioned, there is also the question of compiler complexity. You seem to
by vbit 12y ago
Apart from the time and effort spent in writing the AOT compiler as the other poster mentioned, there is also the question of compiler complexity.
You seem to be implying that JITs are somehow more complex and only help with languages having no static typing. Both assumptions aren't quite true. Also, consider the cases where it's much easier for a JIT to produce code, as it has more information than a static compiler.
For e.g. which functions should be inlined? Which mechanism should be used for dynamic dispatch? If you have 10s of types possible at one dispatch but only two seen in practice, the tracing JIT will only compile the fast paths with an exit for the other paths. The AOT compiler will have to produce a vtable or big switch statement to handle all the types as it lacks the runtime information. Which would you consider 'quality code'?
- acqq 12y agoYes, I already wrote that I'm biased. For me the essential progress is only when it results in: less writing than in C, less memory used, less CPU cycles used, more predictability in the execution, easy mixing with C or assembly code. Basically, allowing me to have everything I can get in C, but to make "easy cases easier" like that I can have type inference etc. That's why I like what Rust is trying to do, but even more what Swift is doing, as in the later easy things look more elegant. As soon as you don't care for any of these, I can see that you can like the languages with VMs, GCs and JITs. I use dynamic langauges too. But it's hard to have me impressed by some, because when I compare it to all which already exist, I must really see some major benefit, not only in the "sugarcoating" but in the work it can do. E.g. Python is worthy because of SciPy, Lua for the increase in the executable measured in kilobytes etc.