[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

McGovern Likes JRuby...

Charles Oliver Nutter

11/11/2006 5:45:00 PM

I'm not sure how to feel about this one :)

http://duckdown.blogspot.com/2006/11/thoughts-on-smal...

"...the Ruby community at large should drop their current approach and
embrace the JRuby stuff."

I blogged a response as well:

http://headius.blogspot.com/2006/11/mcgovern-likes-...

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
25 Answers

Joel VanderWerf

11/11/2006 6:27:00 PM

0

Charles Oliver Nutter wrote:
> http://duckdown.blogspot.com/2006/11/thoughts-on-smal...

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

Justin Collins

11/11/2006 6:38:00 PM

0

Joel VanderWerf wrote:
> Charles Oliver Nutter wrote:
>> http://duckdown.blogspot.com/2006/11/thoughts-on-smal...
>
> James McGovern blogged:
>> By the Ruby community acknowledging the greatness of Java

*groans*

Sorry.

-Justin

Charles Oliver Nutter

11/11/2006 7:08:00 PM

0

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! @ www.headius.com/rubyspec
headius@headius.com -- charles.nutter@sun.com

David Vallner

11/11/2006 7:58:00 PM

0

Right, I'm dropping my Java troll hat for a change.

Joel VanderWerf wrote:
> Charles Oliver Nutter wrote:
>> http://duckdown.blogspot.com/2006/11/thoughts-on-smal...
>
> 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

David Vallner

11/11/2006 8:06:00 PM

0

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

M. Edward (Ed) Borasky

11/11/2006 8:55:00 PM

0

Charles Oliver Nutter wrote:
> I'm not sure how to feel about this one :)
>
> http://duckdown.blogspot.com/2006/11/thoughts-on-smal...
>
> "...the Ruby community at large should drop their current approach and
> embrace the JRuby stuff."
>
> I blogged a response as well:
>
> http://headius.blogspot.com/2006/11/mcgovern-likes-...
>
> Let the games begin!
>
Well ... I know how *I* feel about it:

http://borasky-research.blo...2006/11/nitty-gritty-of-ru...



--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

David Vallner

11/11/2006 9:16:00 PM

0

M. Edward (Ed) Borasky wrote:
> Well ... I know how *I* feel about it:
>
> http://borasky-research.blogspot.com/2006/11/nitty-gritty-of-ru...
>

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

M. Edward (Ed) Borasky

11/11/2006 11:13:00 PM

0

David Vallner wrote:
> M. Edward (Ed) Borasky wrote:
>
>> Well ... I know how *I* feel about it:
>>
>> http://borasky-research.blo...2006/11/nitty-gritty-of-ru...
>>
>>
>
> 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.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

Peter Booth

11/12/2006 1:42:00 AM

0

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.blo...2006/11/nitty-...
>>> 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.blo...
>
> If God had meant for carrots to be eaten cooked, He would have
> given rabbits fire.
>
>

M. Edward (Ed) Borasky

11/12/2006 4:31:00 AM

0

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.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.