3 ms·

> VMs can have bugs and nuances that aren't captured in their specification So can compilers. Adding the additional translation layer of javac or equivalent in

by Ralith 14y ago

> VMs can have bugs and nuances that aren't captured in their specification So can compilers. Adding the additional translation layer of javac or equivalent increases the potential of being affected by bugs in third-party code. Let P be the probability of encountering a bug in the JVM, and Q be the probability of encountering a bug in javac. If we multiply the complements, (1-Q)x(1-P) we have the probability of final execution being in keeping with the HaXe implementation's intentions. Assuming all values are nonzero, (1-P)x(1-Q) < (1-P), therefore the additional translation layer increases the probability of being affected by a bug. Not to mention that the vastly more complex output format increases the possibility of introducing bugs into HaXe itself. > output is "as good as" target-native code. But it isn't. Translating code between languages is lossy. Unless HaXe is trivial, the HaXe implementation has information that could be used to generate better bytecode that is lost when bytecode generation is performed by a tool that knows nothing about HaXe, e.g. javac.

chipsy 14y ago
> Adding the additional translation layer increases the potential of bugs > the implementation has information that could be used to generate better bytecode These are theoreticals. Let me analogize. Some algorithms have a worst-case big O that is significantly worse than the average case. So even though the algorithm could have very poor performance in certain situations, it's better for the "real-world" cases that it gets used in. Most of the existing Haxe targets have similar external semantics(Algol-derived, GC, dynamic types), so we're in an average-case situation of both reliability and performance; the Q probability is close to zero because the code we input isn't that drastically different from human source input, and the input we pass in from Haxe can be a bit more optimized in most respects, because we don't have to make it maintainable. If we were targeting a really bad compiler, it would blow up. But in practice, it doesn't and we gain more than we lose, even when considering areas where there's an impedance mismatch and we have to, for example, add dynamic types on top. Bytecode output is more sensible within a short-term view - a single project with known specifications. But it's ultimately the need for flexibility that drives Haxe, and you aren't gaining additional flexibility from bytecode.
- Ralith 14y ago
  > we gain more than we lose What do you gain? As far as I can tell, there is only loss. > the need for flexibility that drives Haxe, and you aren't gaining additional flexibility from bytecode. Exactly what flexibility does this provide?
  - deleted 14y ago
    [deleted]

by Ralith 14y ago

chipsy 14y ago

> Adding the additional translation layer increases the potential of bugs > the implementation has information that could be used to generate better bytecode These are theoreticals. Let me analogize. Some algorithms have a worst-case big O that is significantly worse than the average case. So even though the algorithm could have very poor performance in certain situations, it's better for the "real-world" cases that it gets used in. Most of the existing Haxe targets have similar external semantics(Algol-derived, GC, dynamic types), so we're in an average-case situation of both reliability and performance; the Q probability is close to zero because the code we input isn't that drastically different from human source input, and the input we pass in from Haxe can be a bit more optimized in most respects, because we don't have to make it maintainable. If we were targeting a really bad compiler, it would blow up. But in practice, it doesn't and we gain more than we lose, even when considering areas where there's an impedance mismatch and we have to, for example, add dynamic types on top. Bytecode output is more sensible within a short-term view - a single project with known specifications. But it's ultimately the need for flexibility that drives Haxe, and you aren't gaining additional flexibility from bytecode.

Ralith 14y ago
> we gain more than we lose What do you gain? As far as I can tell, there is only loss. > the need for flexibility that drives Haxe, and you aren't gaining additional flexibility from bytecode. Exactly what flexibility does this provide?
- deleted 14y ago
  [deleted]