Rick DeNatale wrote:
On Dec 27, 2007 4:28 AM, M. Edward (Ed) Borasky [email protected] wrote:
Well … after it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan D.’ wonderful tools, sure, go ahead and fix Rails.
On the whole, I think that this is a good thing, Ruby 1.9 gives the
community a stepping stone on the path to Ruby 2.0. I’d hate to see
Ruby suffer the fate of, say PHP, which has had some difficulties in
getting it’s community to move to the latest version of the language.
Or Perl 6, which apparently will never be adopted.
Some of us have been keeping an eye on the evolution of 1.9 for some
time before 1.9.0 we’ve been the scouts, with 1.9.0 we’re starting to
see more early adopters, or pioneers, start the journey to Ruby 2.0.
The danger is unwitting pioneers won’t have gotten the message about
the role of 1.9 in relation to 1.8 (and 2.0) and will load up their
Conestoga wagons without realizing the real possibility of getting
arrows in their back.
Well, sure … I haven’t done much with Ruby 1.9 outside of performance
testing till now because:
a. Performance testing is my thing, and
b. 99 44/100 of the code I personally write will work in all of the
The context of my post was:
a. I don’t really care whether Rails ever runs with 1.9, or even 2.0. It
runs with MRI, it runs with jRuby, and a moderate amount of tweaking can
get either of them past the “throw hardware at it” method of performance
tuning. People are earning a decent living as Rails programmers, and
they don’t need 1.9 any more than they need to upgrade from RHEL 4 to
RHEL 5 if RHEL 4 is working for them.
b. What I do care about is the other thing Ruby is really good at –
behavior/test driven development, meta-programming, domain-specific
languages, pragmatic programming, continuous integration, etc. And the
people who built these tools are the very pioneers we “settlers” are
counting on to make Ruby 1.9 and Ruby 2.0 successful in this domain. So
anything we can do to make their job easier is worth doing. (Like
going back to MinGW on Windows …)
What concerns me is that I’m seeing postings from folks, not only
here, but places like the Textmate mailing list, who have installed
Ruby 1.9 from source, and found that existing code using, and
expecting the ruby command to map to Ruby 1.8 is breaking.
I posted a suggestion to ruby-core that perhaps the Ruby 1.9 tarball
should be set up so that BY DEFAULT, it installs as ruby1.9 instead of
ruby, so that unwitting installers don’t get their Ruby1.8
installation replaced by default.
Yeah, that makes sense, given that it is a “development” release. It
would also make the job of Linux distro package management systems a lot
easier, so we’d see Ruby 1.9 show up in Fedora, Debian/Ubuntu and Gentoo
a lot sooner. Right now, they have limited manpower and can’t cope with
all the extra work associated with having two versions of Ruby, even
though they all have provisions for it.