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 N. 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?
Joel VanderWerf wrote:
Charles Oliver N. 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.
Right, I’m dropping my Java troll hat for a change.
Joel VanderWerf wrote:
Charles Oliver N. 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 V.
Charles Oliver N. 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 V.
Charles Oliver N. wrote:
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.
David V. 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.
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
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 V.
Peter B. 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.
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 11/11/06, David V. [email protected] wrote:
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
M. Edward (Ed) Borasky wrote:
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.
Ola B. (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.
David V. 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.
David V. wrote:
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 N. 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.
Hi –
On Sun, 12 Nov 2006, David V. wrote:
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
Ola B. wrote:
is or isn’t, the question is hypothetical).
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.
Charles Oliver N. 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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs