I'm not sure how to feel about this one 
http://duckdown.blogspot.com/2006/11/thoughts-on-smalltalk.html
"...the Ruby community at large should drop their current approach and embrace the JRuby stuff."
I blogged a response as well:
Let the games begin!
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ www.headius.com/rubyspec
headius@headius.com -- charles.nutter@sun.com
Charles Oliver Nutter wrote:
Enterprise Architecture: From Incite comes Insight...: Thoughts on SmallTalk
James McGovern blogged:
By the Ruby community acknowledging the greatness of Java, they could
gain the following capabilities for Ruby:Kick butt concurrency
Better deployment tools
A lot better documentation
How does James McGovern think that running ruby on a JVM improves the docs? It's still the same language...
A more secure platform
Access to a larger community
Type safety
Whuh? Ruby's not type safe?
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Charles Oliver Nutter wrote:
I'm not sure how to feel about this one
Enterprise Architecture: From Incite comes Insight...: Thoughts on SmallTalk
"...the Ruby community at large should drop their current approach and embrace the JRuby stuff."
I blogged a response as well:
Let the games begin!
Well ... I know how *I* feel about it:
http://borasky-research.blogspot.com/2006/11/nitty-gritty-of-ruby_11.html
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
Joel VanderWerf wrote:
Charles Oliver Nutter wrote:
Enterprise Architecture: From Incite comes Insight...: Thoughts on SmallTalk
James McGovern blogged:
By the Ruby community acknowledging the greatness of Java
*groans*
Sorry.
-Justin
Joel VanderWerf wrote:
James McGovern blogged:
Type safety
Whuh? Ruby's not type safe?
Yeah, and exactly how does running on Java help that? Maybe we should add static typing to JRuby! There's a great idea!
It's a peculiar list.
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ Welcome to headius.com
headius@headius.com -- charles.nutter@sun.com
Right, I'm dropping my Java troll hat for a change.
Joel VanderWerf wrote:
Charles Oliver Nutter wrote:
Enterprise Architecture: From Incite comes Insight...: Thoughts on SmallTalk
James McGovern blogged:
By the Ruby community acknowledging the greatness of Java, they could
gain the following capabilities for Ruby:Kick butt concurrency
Alright, I'll let him keep that.
Better deployment tools
Maven fanboy. Run for the hills, kids. Ant isn't bad, but it's rather
baroque and also one of the worse abuses of XML there is. (Completely
unvalidable, etc.) Now Maven 2 trying to play apt-get for Java libraries
is an abomination. (E.g. heavens forbid you get a distribution with
dependencies shipped.). And if you need to reconcile dependencies by
hand (from behind a firewall, for deployment), manually downloading gems
isn't noticeably worse than manually setting up JARs (which you'll end
up with unless you feel like creating a local Maven2 repo mirror, which
is mere hassle.).
A lot better documentation
How does James McGovern think that running ruby on a JVM improves the
docs? It's still the same language...
Well, if you take core libraries and exhaustive tutorials, maybe. But
enter the realms of open-source libraries, and you get documentation
quality of all scales on both sides, with all the usual symptoms. (To
wit: 90% of Apache documentation, and the tons of projects - on both
sides - that barely have API docs, and definitely not human-readable
"how to use" documents.)
A more secure platform
Integrated security policies I'll grant there are. However, I don't
think I'd find five people at the department I work at (Java Knowledge
Base) that have actually ever seen the insides of a policy descriptor,
and more than two that did so outside a course on Java security.
Access to a larger community
A fragmented one too, and absolute values mean nothing - you just want
the significant projects sufficiently covered.
Type safety
Whuh? Ruby's not type safe?
No, it's not. Ruby is strongly typed (all objects have a known type
which doesn't undergo implicit conversions to try and make an operation
succeed), but not type-safe (no verification of whether an object is of
a correct type for an operation until it's too late - NoMethodError).
That's "userspace" type checks notwithstanding, those aren't part of the
language though.
David Vallner
M. Edward (Ed) Borasky wrote:
Well ... I know how *I* feel about it:
http://borasky-research.blogspot.com/2006/11/nitty-gritty-of-ruby_11.html
Impose JRuby on the world? I have my doubts Sun would even try - the
time of Java hype marketing is past. And I don't think JRuby will be as
earthshaking to both the Ruby and Java worlds as some people make it out
to be. By adopting JRuby as the implementation language for the Java
platform, you are also partially dropping the advantages that keeping to
Java has (existing infrastructure, experience, tool support). In the
end, it might be a useful tool on both sides, but I don't see paranoid
managers adopting Ruby en masse just because it has a J prepended to it
- not all of them are that gullible.
That the JVM become the primary runtime for Ruby is somehow laughable.
So far, it hasn't become the primary runtime for any major programming
language that isn't Java, evidence would suggest that this remains the
case. It would be foolish for performance reasons if nothing else, a
dedicated optimised VM will do better when treated with Ruby
idiosyncratisms like pervasive use of closures.
The signal-to-noise ratio of blog topics that concern both Java and Ruby
has been abysmal unless it was about JRuby in specific, I hate to see
random opinionated rants and wishful thinking cloud that topic too.
David Vallner
Charles Oliver Nutter wrote:
Joel VanderWerf wrote:
James McGovern blogged:
Type safety
Whuh? Ruby's not type safe?
Yeah, and exactly how does running on Java help that? Maybe we should
add static typing to JRuby! There's a great idea!
Running on Java would of course do bugger all for that. However, I am
one of the proponents of -some- (optional) ahead-of-time contract
checking for Ruby. Static typing is one method of contract checking, and
an easy one to implement, and in optional form wouldn't be rubbing me
the wrong way. YMMV, and it's a vapourware proposition anyway - IIRC, it
was pondered for Ruby 2.0, but there's no sign of that in any material
describing Ruby 1.9 changes, so I'm not holding my breath.
Duck typing fans will probably howl over the above comment, but if I've
seen code behaviour do -any- type checking (mostly in the standard lib),
it's based on #is_a?, and not on #respond_to?, so apparently most duck
typing preachers really mean "I don't want to bother with any checks".
David Vallner
David Vallner wrote:
M. Edward (Ed) Borasky wrote:
Well ... I know how *I* feel about it:
http://borasky-research.blogspot.com/2006/11/nitty-gritty-of-ruby_11.html
Impose JRuby on the world? I have my doubts Sun would even try - the
time of Java hype marketing is past.
Well, the original poster wanted jRuby to be the one true way. I was simply saying that wasn't possible; even Sun couldn't do it. I too doubt if they would try. But Sun is a big enough company to try things that might not necessarily work.
The time of Java hype marketing is past? Maybe, but the language seems to be an 800-pound gorilla in some peoples' minds. I can't imagine Sun *not* doing everything they can to insure that jRuby succeeds and wins business for Sun.
And I don't think JRuby will be as
earthshaking to both the Ruby and Java worlds as some people make it out
to be. By adopting JRuby as the implementation language for the Java
platform, you are also partially dropping the advantages that keeping to
Java has (existing infrastructure, experience, tool support). In the
end, it might be a useful tool on both sides, but I don't see paranoid
managers adopting Ruby en masse just because it has a J prepended to it
- not all of them are that gullible.
Again, *I* don't support dropping other implementations of Ruby. If nothing else, Microsoft will make at least one release of at least one Ruby implementation. And I'm sure Matz and Koichi will continue leading the community path.
What I'm *not* sure about is whether Rubinius will flourish. Cardinal seems pretty much dead, but I think there's a lot of energy behind Rubinius.
That the JVM become the primary runtime for Ruby is somehow laughable.
So far, it hasn't become the primary runtime for any major programming
language that isn't Java, evidence would suggest that this remains the
case. It would be foolish for performance reasons if nothing else, a
dedicated optimised VM will do better when treated with Ruby
idiosyncratisms like pervasive use of closures.
But we're talking about two different things here -- a community and commercial enterprises. The community can afford to strive for perfection. Commercial enterprises can not. They must *satisfice*, not optimize!
The signal-to-noise ratio of blog topics that concern both Java and Ruby
has been abysmal unless it was about JRuby in specific, I hate to see
random opinionated rants and wishful thinking cloud that topic too.
Still, you have to acknowledge that jRuby is now a commercial project funded by a major hardware and software vendor. That's going to draw opinions and rants and wishful thinking and love and hate and arguments and FUD. I'm surprised someone from Microsoft hasn't attacked it publicly yet.
jRuby is an investment. Only time will tell whether that investment will pay off and what the payoffs will be. I don't know enough about the Java runtime (or the CLR or Parrot, for that matter) to predict success or failure. I'm personally much more interested in the open source community efforts. There are many more opportunities for me to create signal there than there are in two corporations, neither of which pays me a dime. 
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
David Vallner wrote:
Joel VanderWerf wrote:
Better deployment tools
Maven fanboy.
There's a lot more to deployment than Maven. Being able to zip up a Rails app and with a single command spit it out to your 100-server cluster is perhaps more compelling than anything Maven-related. I don't use Maven, but I know firsthand the power of EAR and WAR deployment and how easy they make app management in a typical app server. I think this is more what McGovern was getting at.
A more secure platform
Integrated security policies I'll grant there are. However, I don't
think I'd find five people at the department I work at (Java Knowledge
Base) that have actually ever seen the insides of a policy descriptor,
and more than two that did so outside a course on Java security.
Java has been mercilessly beaten on for a decade. Ruby, not so much. The worst security flaws in Rails or in Ruby are yet to be discovered.
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ Welcome to headius.com
headius@headius.com -- charles.nutter@sun.com
David Vallner wrote:
M. Edward (Ed) Borasky wrote:
Well ... I know how *I* feel about it:
http://borasky-research.blogspot.com/2006/11/nitty-gritty-of-ruby_11.html
Impose JRuby on the world? I have my doubts Sun would even try - the
time of Java hype marketing is past. And I don't think JRuby will be as
earthshaking to both the Ruby and Java worlds as some people make it out
to be. By adopting JRuby as the implementation language for the Java
platform, you are also partially dropping the advantages that keeping to
Java has (existing infrastructure, experience, tool support). In the
end, it might be a useful tool on both sides, but I don't see paranoid
managers adopting Ruby en masse just because it has a J prepended to it
- not all of them are that gullible.
You seem to imply that folks will either use Ruby or Java, but not both. In JRuby, it's safe to say they'll complement each other. I don't expect that in five years all app servers will be written in Ruby from the ground up. But I do expect they'll use Ruby in surprising and significant ways to tie together other code and components written in Java.
And I've been talking to a lot of those paranoid managers. News flash: they're far more likely to adopt JRuby than Ruby when they have an army of Java folks and server rooms full of Java app servers. And guess what else: many of their developers would rather leave or use Ruby than keep on writing struts actions and ant scripts.
That the JVM become the primary runtime for Ruby is somehow laughable.
So far, it hasn't become the primary runtime for any major programming
language that isn't Java, evidence would suggest that this remains the
case. It would be foolish for performance reasons if nothing else, a
dedicated optimised VM will do better when treated with Ruby
idiosyncratisms like pervasive use of closures.
I'll dodge this one by saying this: there are a lot of good VMs out there that could be put to use running Ruby code, and from what I know about Ruby there's nothing that would prevent them from running extremely well. Ruby isn't that idiosyncratic, and most of its idiosyncracies are just syntactic sugar.
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ Welcome to headius.com
headius@headius.com -- charles.nutter@sun.com
I would love JRuby to be a solid Ruby implementation that can leverage the investment in Java/JVM debugging/performance/profiling tools. But here's an example where it would be very useful:
I am writing a monitoring application that exposes information about a Java based application, Sonic MQ JMS broker, and the underlying OS status. Ruby makes trivial work of parsing sar output, or scraping /proc files. The Sonic management API however is an untyped JMX style API. I first tried to use a Java/Sonic CLI program and have my Ruby code run it with popen3 etc but had challenges making this stable. I then tried the Java Ruby Bridge which was great but had unexplained failures and my Ruby isn't strong enough to diagnose. I then used Ruby to drive a Java servlet wrapper on the JMS api, and then ended up writing a hard-coded specific Java app that logs the subset of attributes I am interested in to a file and I have a decoupled Ruby script that reads this. That is four hacks that each sucked in different ways. Using Ruby to in-process call the Java code is the least sucky approach by far.
Is JRuby ready to have a threaded Ruby app use threaded Java code effectively?
Peter
On Nov 11, 2006, at 6:12 PM, M. Edward (Ed) Borasky wrote:
David Vallner wrote:
M. Edward (Ed) Borasky wrote:
Well ... I know how *I* feel about it:
http://borasky-research.blogspot.com/2006/11/nitty-gritty-of-ruby_11.html
Impose JRuby on the world? I have my doubts Sun would even try - the
time of Java hype marketing is past.Well, the original poster wanted jRuby to be the one true way. I was simply saying that wasn't possible; even Sun couldn't do it. I too doubt if they would try. But Sun is a big enough company to try things that might not necessarily work.
The time of Java hype marketing is past? Maybe, but the language seems to be an 800-pound gorilla in some peoples' minds. I can't imagine Sun *not* doing everything they can to insure that jRuby succeeds and wins business for Sun.
And I don't think JRuby will be as
earthshaking to both the Ruby and Java worlds as some people make it out
to be. By adopting JRuby as the implementation language for the Java
platform, you are also partially dropping the advantages that keeping to
Java has (existing infrastructure, experience, tool support). In the
end, it might be a useful tool on both sides, but I don't see paranoid
managers adopting Ruby en masse just because it has a J prepended to it
- not all of them are that gullible.Again, *I* don't support dropping other implementations of Ruby. If nothing else, Microsoft will make at least one release of at least one Ruby implementation. And I'm sure Matz and Koichi will continue leading the community path.
What I'm *not* sure about is whether Rubinius will flourish. Cardinal seems pretty much dead, but I think there's a lot of energy behind Rubinius.
That the JVM become the primary runtime for Ruby is somehow laughable.
So far, it hasn't become the primary runtime for any major programming
language that isn't Java, evidence would suggest that this remains the
case. It would be foolish for performance reasons if nothing else, a
dedicated optimised VM will do better when treated with Ruby
idiosyncratisms like pervasive use of closures.But we're talking about two different things here -- a community and commercial enterprises. The community can afford to strive for perfection. Commercial enterprises can not. They must *satisfice*, not optimize!
The signal-to-noise ratio of blog topics that concern both Java and Ruby
has been abysmal unless it was about JRuby in specific, I hate to see
random opinionated rants and wishful thinking cloud that topic too.Still, you have to acknowledge that jRuby is now a commercial project funded by a major hardware and software vendor. That's going to draw opinions and rants and wishful thinking and love and hate and arguments and FUD. I'm surprised someone from Microsoft hasn't attacked it publicly yet.
jRuby is an investment. Only time will tell whether that investment will pay off and what the payoffs will be. I don't know enough about the Java runtime (or the CLR or Parrot, for that matter) to predict success or failure. I'm personally much more interested in the open source community efforts. There are many more opportunities for me to create signal there than there are in two corporations, neither of which pays me a dime.
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
Running on Java would of course do bugger all for that. However, I am
one of the proponents of -some- (optional) ahead-of-time contract
checking for Ruby. Static typing is one method of contract checking, and
an easy one to implement, and in optional form wouldn't be rubbing me
the wrong way. YMMV, and it's a vapourware proposition anyway - IIRC, it
was pondered for Ruby 2.0, but there's no sign of that in any material
describing Ruby 1.9 changes, so I'm not holding my breath.
That's good, because it would change Ruby from a beautiful language
into the hell that is Java. There's *no* advantage to the programmer
from explicit static typing, IME. (I've had more problems with
statically typed languages than I've ever had with Perl, PHP, *or*
Ruby.)
Duck typing fans will probably howl over the above comment, but if I've
seen code behaviour do -any- type checking (mostly in the standard lib),
it's based on #is_a?, and not on #respond_to?, so apparently most duck
typing preachers really mean "I don't want to bother with any checks".
This is disingenuous. There are certain things about the behaviours of
intrinsic (core) objects (Array, String, Hash, etc.) which cannot be
distinguished with #respond_to? in any way. If you look at most such
checks, they're to distinguish between those specific types. Aside
from that, there's much more likely to be #respond_to? checks outside
of the core and standard libraries.
My libraries, for example, tend to rarely check the class of something
-- and when I *do* perform checks, it's generally for a #respond_to?
call. I think that's true of
One shouldn't need to perform most checks: they're a performance hit.
If you tell people (through documentation) to send you something that
responds to #<< then you just *use* #<<. If you want to print a custom
message, then you perform the check.
-austin
On 11/11/06, David Vallner <david@vallner.net> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
M. Edward (Ed) Borasky wrote:
<snip>
jRuby is an investment. Only time will tell whether that investment will pay off and what the payoffs will be. I don't know enough about the Java runtime (or the CLR or Parrot, for that matter) to predict success or failure. I'm personally much more interested in the open source community efforts. There are many more opportunities for me to create signal there than there are in two corporations, neither of which pays me a dime.
Hi Ed,
From your post I got the distinct impression that JRuby is no longer an open source project: "I'm personally much more interested in the open source community efforts."
I just want to chime in and inform you that JRuby is still an Open Source project and very much a community effort. Charles and Tom are hired by Sun, but they are by no means the only ones contributing code to JRuby. Would Ruby stop being a community effort if Matz was employed full time by a company to implement it? (I'm not sure if he is or isn't, the question is hypothetical).
What I have seen from Sun's involvement in JRuby this far is only for the benefit of JRuby. More resources and more information to better implement stuff, but no explicit steering towards subjects more interesting for Sun.
I'm not an idealist and realize that Sun's involvement of course is because they think they can benefit from the project, but that doesn't make JRuby less Open Source or community driven.
Regards
--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)
"Yields falsehood when quined" yields falsehood when quined.
Talk about trolling...
M. Edward (Ed) Borasky wrote:
Well, the original poster wanted jRuby to be the one true way. I was simply saying that wasn't possible; even Sun couldn't do it. I too doubt if they would try. But Sun is a big enough company to try things that might not necessarily work.
The time of Java hype marketing is past? Maybe, but the language seems to be an 800-pound gorilla in some peoples' minds. I can't imagine Sun *not* doing everything they can to insure that jRuby succeeds and wins business for Sun.
JRuby could only become the "one true way" if the community decided to move that direction. I have no desire to make that happen; I just want to make JRuby as good as possible. If the end result is what ALL Rubyists actually want out of Ruby, great. I don't expect that will happen. However I know it will be the right answer for a growing number of Rubyists, and certainly the right answer for Ruby in a Java world.
I think the best answer is for Rubyists to avoid thinking about JRuby in terms of Java. JRuby is Ruby, with a different VM underneath. If you could have Ruby on VM X, where X had full native threading, advanced garbage collection and memory management, fast synchronous and asynchronous IO, JITing to native code, runtime optimization, and built-in support for dynlangs, wouldn't you want that?
That's the JVM.
Again, *I* don't support dropping other implementations of Ruby. If nothing else, Microsoft will make at least one release of at least one Ruby implementation. And I'm sure Matz and Koichi will continue leading the community path.
The community path doesn't have to exclude paid developers from Microsoft or Sun. I am as much a part of the community as you are.
What I'm *not* sure about is whether Rubinius will flourish. Cardinal seems pretty much dead, but I think there's a lot of energy behind Rubinius.
There's energy, but not numbers. Rubinius is cool, no doubt about it...I just hope more folks step up to the plate to help contribute time and effort into it.
Cardinal's only problem is that it suffers from Parrot.
But we're talking about two different things here -- a community and commercial enterprises. The community can afford to strive for perfection. Commercial enterprises can not. They must *satisfice*, not optimize!
And perhaps once JRuby runs Rails perfectly, or exceeds YARV performance, or this or that, we'll be moved on to other projects. But there's a lot of potential in sticking with JRuby for the long haul. I realize that, and Sun realizes that. You can FUD all you like, but believe me: Sun is serious about this stuff.
Still, you have to acknowledge that jRuby is now a commercial project funded by a major hardware and software vendor. That's going to draw opinions and rants and wishful thinking and love and hate and arguments and FUD. I'm surprised someone from Microsoft hasn't attacked it publicly yet.
By that logic, all the Apache projects are commercial projects as well, since there are full-time folks from various companies working on them. The same logic could extend to C Ruby, since Matz and Koichi are paid to work on it. Obviously wrong.
And what exactly would MS attack? A five-year-old open-source implementation of Ruby for the JVM, simply because Sun hired two guys to help improve it and bring it to a 1.0 release?
jRuby is an investment. Only time will tell whether that investment will pay off and what the payoffs will be. I don't know enough about the Java runtime (or the CLR or Parrot, for that matter) to predict success or failure. I'm personally much more interested in the open source community efforts. There are many more opportunities for me to create signal there than there are in two corporations, neither of which pays me a dime.
Ola already mentioned that JRuby is as open-source and community-driven as anything. There's a growing community of contributors, Ola is part of the core team, and we're going to add more non-Sun committers soon. Claiming that JRuby is somehow less open or less communal than C Ruby is pretty silly.
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ Welcome to headius.com
headius@headius.com -- charles.nutter@sun.com
Hi --
Running on Java would of course do bugger all for that. However, I am
one of the proponents of -some- (optional) ahead-of-time contract
checking for Ruby. Static typing is one method of contract checking, and
an easy one to implement, and in optional form wouldn't be rubbing me
the wrong way. YMMV, and it's a vapourware proposition anyway - IIRC, it
was pondered for Ruby 2.0, but there's no sign of that in any material
describing Ruby 1.9 changes, so I'm not holding my breath.Duck typing fans will probably howl over the above comment, but if I've
seen code behaviour do -any- type checking (mostly in the standard lib),
it's based on #is_a?, and not on #respond_to?, so apparently most duck
typing preachers really mean "I don't want to bother with any checks".
I can't speak to the preaching and howling, neither being much in my
line; but just in terms of the technical stuff: "duck typing" is a
name for a style of programming that does not branch on an object's
class/module ancestry and which may, but does not always, branch on an
object's type, generally using #respond_to? when it does so.
#respond_to? is not the heart of duck typing, though, nor
consubstantial with it. It's a useful duck-typing tool, sometimes,
but that's about all.
In the past I've described the difference between using and not using
#respond_to? as the difference between "soft" and "hard" duck typing.
By that, I mean that the real business of duck typing is to live as
close to the object, and to the present-time of the sending of the
message, as possible; and respond_to? is a step away from that moment,
therefore arguably a "softening" of the practice. But it's still duck
typing, in the sense that the step away is still directly related to
the goal of sending the object a message.
The flip side of this is that the absence of #respond_to? does not
mean the presence of duck typing.
David
On Sun, 12 Nov 2006, David Vallner wrote:
--
David A. Black | dblack@rubypal.com
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org
Charles Oliver Nutter wrote:
I'll dodge this one by saying this: there are a lot of good VMs out there that could be put to use running Ruby code, and from what I know about Ruby there's nothing that would prevent them from running extremely well. Ruby isn't that idiosyncratic, and most of its idiosyncracies are just syntactic sugar.
Well ... actually there *aren't* a lot of good VMs out there. The JVM and the Microsoft CLR are probably the only two "industrial strength" ones out there.
Parrot? Well ... if they ever get it finished ... if Perl and Python and Ruby all have active teams porting the languages to it ... etc., etc., etc.
Now, if you're willing to limit yourself to Scheme or Forth, there are some good language-specific VMs out there. But there's no marketing muscle behind any of them, so it's strictly a labor of love. There are pieces of these I think a Ruby VM "should" have -- tail recursion and continuations from Scheme and threaded inner interpreters, a stack machine architecture and an inline assembler from Forth. But most of the people working with and on Ruby know C, Java and C# (and Perl, Python and PHP) much better than they know Scheme or Forth.
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
Charles Oliver Nutter wrote:
You seem to imply that folks will either use Ruby or Java, but not both. In JRuby, it's safe to say they'll complement each other. I don't expect that in five years all app servers will be written in Ruby from the ground up. But I do expect they'll use Ruby in surprising and significant ways to tie together other code and components written in Java.
A good example is actually what BEA are doing with Jython in their WLST (Weblogic Scripting Tool, or whatever it means). They allow you to write the configuration scripts for your application servers in Jython, that then hook into the Java side thru JMX. It works pretty well and is nice and flexible. JRuby could obviously be used for similar things.
Hi, new guy here. Enjoying the discussions!
/ Per
Peter Booth wrote:
I am writing a monitoring application that exposes information about a Java based application, Sonic MQ JMS broker, and the underlying OS status. Ruby makes trivial work of parsing sar output, or scraping /proc files.
I'm not sure why you'd want to use both "sar" and "/proc". Everything in "sar" comes out of "/proc" (or some of the other monitoring filesystems in more recent versions of the kernel), Also, how often do you need to take snapshots? Once you get below about once a minute, you start to need to care about the processor and memory impact of the monitoring tool. Yes, it's easier than instrumenting the application/middleware, but instrumenting the application/middleware is the right thing to do.
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
Ola Bini wrote:
M. Edward (Ed) Borasky wrote:
<snip>jRuby is an investment. Only time will tell whether that investment will pay off and what the payoffs will be. I don't know enough about the Java runtime (or the CLR or Parrot, for that matter) to predict success or failure. I'm personally much more interested in the open source community efforts. There are many more opportunities for me to create signal there than there are in two corporations, neither of which pays me a dime.
Hi Ed,
From your post I got the distinct impression that JRuby is no longer an open source project: "I'm personally much more interested in the open source community efforts."
I just want to chime in and inform you that JRuby is still an Open Source project and very much a community effort. Charles and Tom are hired by Sun, but they are by no means the only ones contributing code to JRuby. Would Ruby stop being a community effort if Matz was employed full time by a company to implement it? (I'm not sure if he is or isn't, the question is hypothetical).What I have seen from Sun's involvement in JRuby this far is only for the benefit of JRuby. More resources and more information to better implement stuff, but no explicit steering towards subjects more interesting for Sun.
I'm not an idealist and realize that Sun's involvement of course is because they think they can benefit from the project, but that doesn't make JRuby less Open Source or community driven.
Regards
Ah ... OK. I'm glad to hear that jRuby is indeed a community/open source effort. By the way, speaking of large corporations and open source, Sun has taken some flack about the slow pace of opening up Java technology in general. Given the size of the technology and the number of people who would need to approve it, it's not a surprise to me that it would take so long. But still, in general in the corporate world, many more people are paid to work *with* open source technologies rather than to work *on* them.
So ... how far away are we from an open source JVM?
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.