James said:
So I have to ask - is JRuby a good thing for the Ruby community, as opposed
to the Java community? To me - admittedly, someone without a huge depth of
Ruby experience - it's not an obvious good idea.
Very few things are. If it gets support and ends up being Done Right -
e.g. with good bidirectional integration. I'm thinking along the lines
of Nemerle in .NET - one of the few non-MS .NET languages that a)
actually adds new features instead of just rephrasing C#, and b) very
nicely transparently both consuming the framework, and creating
interoperating assemblies.
The best I can say is that I expect that it will be a good thing for
someone. Since Java pays my bills, I wouldn't complain if JRuby brought
benefits on that side of the fence. And then again, you get things like
very decent support for newer W3C standards in Java libs soon, and being
able to at least bite your teeth on them earlier -and- using a language
you prefer is good for Rubyists too.
(PS: For those looking for a new language to play around with, and
partial to ML-likes, or those that want to learn some functional
programming from the lighter side of things, I can strongly recommend
Nemerle. The optional indentation-based syntax I find easier to
understand than Haskell's, the OO is more familiar than OCaml's take on
that, AND you get the whole of .NET thrown in for good measure for
instant "real-world" programming possibilities. No, I'm not a member of
the project ;P)
The JVM is great for running client apps. On the server side it's less than
useful; it's just another layer on top of the operating system. Servers
have a well-understood interface, and putting something like .Net or the JVM
on them just gets in the way. Sure, it may be handy for some very strange
edge cases, but Ruby runs on all the environments that the mainstream cares
about - Unix variants. (OK, and you can run Ruby on Windows, but almost no
one will for production servers.)
You also obviously don't have great experience with with Java either.
J2EE - mostly server-side computing is the single most successful
application of the language bar none.
Desktop Java started out on the wrong foot and only barely caught on
lately. The GUI toolkits are to blame for a lot of it. First came AWT,
which was a pretty sub-par "smallest common denominator" GUI toolkit; to
add insult to injury, AWT saw use with the earlier VMs which gave birth
to the low speed myth - that one was quite justified then. Then came
Swing. I have a strong love / hate relationship to Swing - I learned GUI
coding on it, the Bean-structure API is still by far my favourite
approach, and it has a great structure to code UIs in in source code as
opposed to using a visual window editor. (I never quite got the hang of
those, and am very willing to enter into long-winded flamewars with
Visual Studio monkeys on how a good handcodable GUI is useful and how my
preference is not a flaw.) However, Swing looked horribly for very long
before Sun realised users want integration with their existing setup -
AFAIK, only the upcoming Java 1.6 will actually use native APIs to draw
controls to get a native look. 1.5s Swing looks passable until you
heavens forbid change font resolution in Windows to Large fonts, when
you get pixelated hell. And the fact subpixel font antialiasing isn't
get annoying too.
Another problem with that is that Sun should have done one thing - added
native binary emit features to javac. The part of the tutorial that says
you have to call "java some.silly.class.Name" to run an app is just
laughable, and just emitting a simple binary that would use JNI to start
a VM in the process and start the program wouldn't hurt. This is where
NET frankly obliterates it, none of its idioms look out of place.
I'm guessing that for embedded devices Ruby isn't going to be a player, but
maybe I'm wrong and JRuby on something like a phone would be a huge plus.
I think someone ported Ruby to a Nokia tablet PC. For quick glue jobs
and batches, it might be workable.
Adding a JVM layer means you can interface to Java libraries, sure, but how
important is that? Most of the time things provide interfaces in C, and
Ruby will accumulate ways of using those. Seems like a time-limited problem
here that would lock Ruby into a Java-centric world.
The Java-centric world is HUGE. You also get instant binary
compatibility on all platforms and your only native dependency becomes
the JVM, which is fairly well supported on all manners of stuff. Sure,
Ruby works most of the time if you get all your dependency maintainers
to provide Windows DLLs and your deployment boxes have gcc and devel
libs to compile extensions.
Except not all native Ruby extensions have Windows ports available, and
not all deployment boxes have GCC, and if deploying on a Debian box,
odds are you won't have devel libs for everything installed, and then
you're screwed. Most Java deployment is copying a JAR / WAR / EAR around.
Running on the JVM will mean that anything coded in C won't run, no?
Libraries that need screaming performance for particular carefully chosen
optimized bits aren't going to work with the JVM, and it strikes me as
bizarre to code in Java for performance.
As I said. Everything and its mum has a Java version these days, it's
improbable you couldn't find an equivalent. Or ten. For screaming
performance, there's always JNI to make a fast implementation - the
Subversion bindings for Java do this for example.
David Vallner
