4 ms·

Why not just write a program that can convert any program written in one language to any of the others? It is basically the same problem and about the same leve

Why not just write a program that can convert any program written in one language to any of the others? It is basically the same problem and about the same level of difficulty.

johnnybgoode 17y ago
Edit: Were you being sarcastic? I don't think it's exactly the same, because being able to compile many languages down to a single language is easier than also having to go in the other direction. Original comment: Yeah, that would be one solution, but I think the shared VM helps so you can easily access libraries written in different languages. I remember why (of Ruby fame) trying to run Ruby code on Google App Engine back when it was Python-only. He discovered that Ruby bytecode is nearly identical to Python bytecode. Like me, he didn't understand why Python and Ruby still need to be on separate runtimes.
- karanbhangui 17y ago
  That wasn't sarcasm; it was a rhetorical question to illustrate a point.
  - johnnybgoode 17y ago
    Thank you for adding so much to the discussion. (That was sarcasm.)
- briansmith 17y ago
  No, I wasn't being sarcastic. If you want to use libraries written in Python in Ruby (just as an example), you need to be able to convert all the Pythonisms to Rubyisms and/or Rubyisms to Pythonisms. That is the case whether you are doing source-to-source rewriting or using a shared VM. Note that the JVM and .NET runtimes do pretty much exactly what was asked--they run programs written in multiple languages on the same VM. Because the "native" VMs for Python and Ruby are so bad, the JVM and .NET VMs can even out-perform the native ones for most tasks.
ori_b 17y ago
How much of the source level semantics do you want to preserve? If you don't care about many of them then it's not too hard to do (although quite pointless). Just compile to an array of bytes, and a turing machine emulator or equivalent, in your target language of choice, and you've converted. The hard part comes when you want to preserve source-level semantics and provide a natural-feeling translation so that a human can understand, read, and write the source. However, with a VM you don't have that problem. With a VM, a lossy, one-way transform is sufficient. You can easily throw away information as you compile, since you're not targeting humans consumption for the output. You can replace, say, overloaded functions with mangled names. You can turn multiple dispatch into decision trees of conditional statements. And so on. With a VM, you would want to keep enough high-level detail to efficiently JIT stuff, and it's a bit of a challenge to decide what detail is sufficiently useful to include, but it's not insurmountable.

Why not just write a program that can convert any program written in one language to any of the others? It is basically the same problem and about the same level of difficulty.

johnnybgoode 17y ago

Edit: Were you being sarcastic? I don't think it's exactly the same, because being able to compile many languages down to a single language is easier than also having to go in the other direction. Original comment: Yeah, that would be one solution, but I think the shared VM helps so you can easily access libraries written in different languages. I remember why (of Ruby fame) trying to run Ruby code on Google App Engine back when it was Python-only. He discovered that Ruby bytecode is nearly identical to Python bytecode. Like me, he didn't understand why Python and Ruby still need to be on separate runtimes.

karanbhangui 17y ago
That wasn't sarcasm; it was a rhetorical question to illustrate a point.
- johnnybgoode 17y ago
  Thank you for adding so much to the discussion. (That was sarcasm.)
briansmith 17y ago
No, I wasn't being sarcastic. If you want to use libraries written in Python in Ruby (just as an example), you need to be able to convert all the Pythonisms to Rubyisms and/or Rubyisms to Pythonisms. That is the case whether you are doing source-to-source rewriting or using a shared VM. Note that the JVM and .NET runtimes do pretty much exactly what was asked--they run programs written in multiple languages on the same VM. Because the "native" VMs for Python and Ruby are so bad, the JVM and .NET VMs can even out-perform the native ones for most tasks.

ori_b 17y ago

How much of the source level semantics do you want to preserve? If you don't care about many of them then it's not too hard to do (although quite pointless). Just compile to an array of bytes, and a turing machine emulator or equivalent, in your target language of choice, and you've converted. The hard part comes when you want to preserve source-level semantics and provide a natural-feeling translation so that a human can understand, read, and write the source. However, with a VM you don't have that problem. With a VM, a lossy, one-way transform is sufficient. You can easily throw away information as you compile, since you're not targeting humans consumption for the output. You can replace, say, overloaded functions with mangled names. You can turn multiple dispatch into decision trees of conditional statements. And so on. With a VM, you would want to keep enough high-level detail to efficiently JIT stuff, and it's a bit of a challenge to decide what detail is sufficiently useful to include, but it's not insurmountable.