4 ms·

This is just transcompilation to Java, not actual static compilation. The performance gains will be offset by the increased memory footprint of the JVM. Intere

This is just transcompilation to Java, not actual static compilation. The performance gains will be offset by the increased memory footprint of the JVM. Interesting nonetheless.

kristianp 14y ago
I guess headius works with what he knows best, which is the JVM.
- kintamanimatt 14y ago
  You may have missed the point of my comment: this isn't static compilation, but rather transcompilation. This isn't a bad thing, it's just mislabeled. FastRuby is implemented in a similar way to CoffeeScript.
  - ryanbraganza 14y ago
    I don't disagree. Although, I think CoffeeScript is more similar to JRuby than FastRuby.
    - batista 14y ago
      In what possible way is CoffeeScript more similar to JRuby than FastRuby??? JRuby is an actual compiler to JVM bytecode. FastRuby is translating to Java. If anything, FastRuby is the SAME THING as CoffeeScript.
  - headius 14y ago
    CoffeeScript is a transcompiler because it's largely just taking language A with semantics similar to JavaScript but different syntax and converting it directly to JavaScript. There's no static worldview as in fastruby, no exploitation of that worldview, and no fundamental differences between CoffeeScript and JavaScript.
    - kintamanimatt 14y ago
      CoffeScript was designed with transcompilation to JavaScript in mind. This is why you've correctly noted they're conceptually similar in many respects, and therefore relatively easy to transcompile. Transcompilation can be relatively simple in the case of CS to JS, or significantly more involved in the case of Ruby to Java. One of the most significant examples of transcompilation is PHP to C++, as in the case of Facebook's HipHop compiler.
      - headius 14y ago
        Yeah, I still don't agree with you. If I were compiling to JVM bytecode, would you no longer consider it a transcompiler? And if that bytecode were exactly what javac produced after compiling the Java source I emit now...what exactly is the difference? FWIW, I'm probably going to just emit JVM bytecode anyway, since it's easier than emitting syntactically correct Java source.
        kintamanimatt 14y ago
        This is where the lines get blurry. Anything that translates source code to bytecode would clearly not be a transcompiler as bytecode can hardly be considered source code, even if an abstract implementation of the machine ends up executing it. Something is considered source code if it is intended to be written and read primarily by humans. Once upon a time, machine code would have been the same as source code as there were no compilers, and punchcards were punched with opcodes and data directly. Now, nobody in their right mind considers machine language to be source code, and I could only make a very tenuous argument in favor of JVM bytecode being source code. Compilation is the process of producing something the "machine" understands natively. Traditionally this was the CPU. Your CPU doesn't understand Ruby, but it (probably) understands x86 machine code, along with various extensions. In the case of Java, the machine is no longer the CPU, but an abstraction of it. The machine in this case only understands JVM bytecode, not Java. Same with the CLR which only understands IL, not C#, F#, VB.NET, etc. If you emit bytecode directly you'd have a compiler not a transcompiler.
headius 14y ago
I disagree :) A transcompiler would have to be able to produce pretty much 1:1 mapping between one language and another. In this case, it would have to be emitting the equivalent of dynamic calls, which isn't really possible on the JVM (other than through invokedynamic, which does work very well). Instead, this is using a static view of the world to produce the resulting code...assuming only the method names it sees statically at compile time will ever exist, and generating a static picture of that world. Hell...it's actually turning all dynamic dispatch into static dispatch. How could a transcompiler possibly do that? Also...performance gains being offset by the size of the JVM? I don't understand this at all.
- kintamanimatt 14y ago
  No, what you've produced is a transcompiler which takes the source code from one language and converts it to source code in another language at the same high level. The fact there isn't a 1:1 mapping between the source language and the destination language isn't relevant. Strangely, it doesn't appear the Dragon Book mentions transcompilation, but Wikipedia has a decent definition: https://en.wikipedia.org/wiki/Transcompiler https://en.wikipedia.org/wiki/Transcompiler This isn't static compilation in any sense of the definition as you're not producing a low-level language, i.e. assembly or machine code. Ultimately the JVM will do some combination of static and JIT compilation, but your code isn't doing this. In no way am I deriding your effort, you've just got your definitions mixed up. The JVM tends to run in a relatively large memory footprint compared to the MRI, although the JVM will execute faster when it's warmed up. The JVM isn't known for being frugal when it comes to memory usage. For long running processes, your transcompiler could be very useful.

This is just transcompilation to Java, not actual static compilation. The performance gains will be offset by the increased memory footprint of the JVM. Interesting nonetheless.

kristianp 14y ago

I guess headius works with what he knows best, which is the JVM.

kintamanimatt 14y ago
You may have missed the point of my comment: this isn't static compilation, but rather transcompilation. This isn't a bad thing, it's just mislabeled. FastRuby is implemented in a similar way to CoffeeScript.
- ryanbraganza 14y ago
  I don't disagree. Although, I think CoffeeScript is more similar to JRuby than FastRuby.
  - batista 14y ago
    In what possible way is CoffeeScript more similar to JRuby than FastRuby??? JRuby is an actual compiler to JVM bytecode. FastRuby is translating to Java. If anything, FastRuby is the SAME THING as CoffeeScript.
- headius 14y ago
  CoffeeScript is a transcompiler because it's largely just taking language A with semantics similar to JavaScript but different syntax and converting it directly to JavaScript. There's no static worldview as in fastruby, no exploitation of that worldview, and no fundamental differences between CoffeeScript and JavaScript.
  - kintamanimatt 14y ago
    CoffeScript was designed with transcompilation to JavaScript in mind. This is why you've correctly noted they're conceptually similar in many respects, and therefore relatively easy to transcompile. Transcompilation can be relatively simple in the case of CS to JS, or significantly more involved in the case of Ruby to Java. One of the most significant examples of transcompilation is PHP to C++, as in the case of Facebook's HipHop compiler.
    - headius 14y ago
      Yeah, I still don't agree with you. If I were compiling to JVM bytecode, would you no longer consider it a transcompiler? And if that bytecode were exactly what javac produced after compiling the Java source I emit now...what exactly is the difference? FWIW, I'm probably going to just emit JVM bytecode anyway, since it's easier than emitting syntactically correct Java source.
      - kintamanimatt 14y ago
        This is where the lines get blurry. Anything that translates source code to bytecode would clearly not be a transcompiler as bytecode can hardly be considered source code, even if an abstract implementation of the machine ends up executing it. Something is considered source code if it is intended to be written and read primarily by humans. Once upon a time, machine code would have been the same as source code as there were no compilers, and punchcards were punched with opcodes and data directly. Now, nobody in their right mind considers machine language to be source code, and I could only make a very tenuous argument in favor of JVM bytecode being source code. Compilation is the process of producing something the "machine" understands natively. Traditionally this was the CPU. Your CPU doesn't understand Ruby, but it (probably) understands x86 machine code, along with various extensions. In the case of Java, the machine is no longer the CPU, but an abstraction of it. The machine in this case only understands JVM bytecode, not Java. Same with the CLR which only understands IL, not C#, F#, VB.NET, etc. If you emit bytecode directly you'd have a compiler not a transcompiler.

headius 14y ago

I disagree :) A transcompiler would have to be able to produce pretty much 1:1 mapping between one language and another. In this case, it would have to be emitting the equivalent of dynamic calls, which isn't really possible on the JVM (other than through invokedynamic, which does work very well). Instead, this is using a static view of the world to produce the resulting code...assuming only the method names it sees statically at compile time will ever exist, and generating a static picture of that world. Hell...it's actually turning all dynamic dispatch into static dispatch. How could a transcompiler possibly do that? Also...performance gains being offset by the size of the JVM? I don't understand this at all.

kintamanimatt 14y ago
No, what you've produced is a transcompiler which takes the source code from one language and converts it to source code in another language at the same high level. The fact there isn't a 1:1 mapping between the source language and the destination language isn't relevant. Strangely, it doesn't appear the Dragon Book mentions transcompilation, but Wikipedia has a decent definition: https://en.wikipedia.org/wiki/Transcompiler https://en.wikipedia.org/wiki/Transcompiler This isn't static compilation in any sense of the definition as you're not producing a low-level language, i.e. assembly or machine code. Ultimately the JVM will do some combination of static and JIT compilation, but your code isn't doing this. In no way am I deriding your effort, you've just got your definitions mixed up. The JVM tends to run in a relatively large memory footprint compared to the MRI, although the JVM will execute faster when it's warmed up. The JVM isn't known for being frugal when it comes to memory usage. For long running processes, your transcompiler could be very useful.