3 ms·

Could someone explain why this is needed? I don't understand why someone wouldn't just write Java if they wanted to write Java. I also don't understand why an

Could someone explain why this is needed? I don't understand why someone wouldn't just write Java if they wanted to write Java. I also don't understand why anyone would want generated code. The unnecessary abstraction leaves you less expressive and with less control. Not trying to be a troll here, just hoping to learn something I'm missing.

pit 14y ago
Weirdly, I was wondering about the existence of something like this about 20 minutes ago. I'm using Grails for work, and it's pretty unpleasant. I don't want to write Groovy, but I have to write Groovy.
amalter 14y ago
This could be useful for someone wanting to whip up some Android code in Ruby, but not wanting to import the full JRuby or Ruby NDK overhead. I bet it's mostly for fun. He essentially extracted his JRuby JIT into a conventional compiler. In other words, a neat hack.
- rst 14y ago
  All the more so because current "jruby-on-Android" has performance problems. This hits particularly hard on startup (where a simple app can take several seconds to get past a splash page; see http://ruboto-startup.heroku.com/measurements http://ruboto-startup.heroku.com/measurements for timing). But even once the app gets running, things still drag compared to a conventional JVM because the JIT doesn't work (due to Android's nonstandard Dalvik bytecodes). If rubyflux winds up bypassing most of this overhead, it could be a major win. (Right now, I've got a project to try to use Scala to try to build a full-featured, reduced-boilerplate Android environment here: http://rst.github.com/positronic_docs.html http://rst.github.com/positronic_docs.html --- but I'd really rather be using Ruby if the performance penalties could be ironed out.)
zem 14y ago
there are a lot of people who want to have java written, but don't want to write java. this way you might get less control, but you get the greater expressiveness of ruby.
scott_s 14y ago
It may not be needed. The author may just have done it because they could, and thought it was neat. But the potential reasons for wanting it is that now the runtime is the JVM, MRI (Matz's Ruby interpreter). JRuby accomplishes using the JVM as the runtime for Ruby by reimplementing the Ruby runtime in Java. This is a different approach, one in which Ruby code is compiled to Java code, rather than using Java runtime interpret Ruby code.
yareally 14y ago
Definitely with Android. Lots of people want to make Android apps, but a decent percentage do not want to use Java. I prefer Mono for Android as a native alternative, but this could be nice for those that want to use a more dynamic language than C# or F# (Mono for Android does not have real support for dynamic languages due to limitations imposed by the Dalvik VM).
bascule 14y ago
You're essentially asking why someone would write a compiler. Why wouldn't someone consume target language X directly instead of using a compiler to generate output in target language X. We want our programs to wind up as machine language, so why not write opcodes for the host ISA instead of writing in, say, any other language?

pit 14y ago

Weirdly, I was wondering about the existence of something like this about 20 minutes ago. I'm using Grails for work, and it's pretty unpleasant. I don't want to write Groovy, but I have to write Groovy.

amalter 14y ago

This could be useful for someone wanting to whip up some Android code in Ruby, but not wanting to import the full JRuby or Ruby NDK overhead. I bet it's mostly for fun. He essentially extracted his JRuby JIT into a conventional compiler. In other words, a neat hack.

rst 14y ago
All the more so because current "jruby-on-Android" has performance problems. This hits particularly hard on startup (where a simple app can take several seconds to get past a splash page; see http://ruboto-startup.heroku.com/measurements http://ruboto-startup.heroku.com/measurements for timing). But even once the app gets running, things still drag compared to a conventional JVM because the JIT doesn't work (due to Android's nonstandard Dalvik bytecodes). If rubyflux winds up bypassing most of this overhead, it could be a major win. (Right now, I've got a project to try to use Scala to try to build a full-featured, reduced-boilerplate Android environment here: http://rst.github.com/positronic_docs.html http://rst.github.com/positronic_docs.html --- but I'd really rather be using Ruby if the performance penalties could be ironed out.)

zem 14y ago

there are a lot of people who want to have java written, but don't want to write java. this way you might get less control, but you get the greater expressiveness of ruby.

scott_s 14y ago

It may not be needed. The author may just have done it because they could, and thought it was neat. But the potential reasons for wanting it is that now the runtime is the JVM, MRI (Matz's Ruby interpreter). JRuby accomplishes using the JVM as the runtime for Ruby by reimplementing the Ruby runtime in Java. This is a different approach, one in which Ruby code is compiled to Java code, rather than using Java runtime interpret Ruby code.

yareally 14y ago

Definitely with Android. Lots of people want to make Android apps, but a decent percentage do not want to use Java. I prefer Mono for Android as a native alternative, but this could be nice for those that want to use a more dynamic language than C# or F# (Mono for Android does not have real support for dynamic languages due to limitations imposed by the Dalvik VM).

bascule 14y ago

You're essentially asking why someone would write a compiler. Why wouldn't someone consume target language X directly instead of using a compiler to generate output in target language X. We want our programs to wind up as machine language, so why not write opcodes for the host ISA instead of writing in, say, any other language?