Purpose of Ruby 1.9?

ruby-talk
21

Keep in mind that Ruby 1.9 is really a new language, Matz and co
decided to release it as a way of driving towards Ruby 2.0 whose
version number would more clearly indicate this, but there are changes
in 1.9, which are deliberately incompatible with Ruby 1.8. Matz has
spent the past few months backing out some of the more radical
experimental changes, but there's no guarantee of backward
compatibility.

So the work to be done is on both sides. Yes, there are, known, and
unknown bugs in Ruby 1.9 which will be worked out by the core team,
but on the other side, work needs to be done by all those tools and
frameworks to 'port' to the new language. The new and removed language
features of 1.9 are not likely to change unless something comes up
which indicates a major mistake in the definition of Ruby 1.9.

It's a community project.

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.

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.

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.

···

On Dec 27, 2007 4:28 AM, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

botp wrote:
> On Dec 27, 2007 7:11 AM, Dave Thomas <dave@pragprog.com> wrote:
>> On Dec 26, 2007, at 4:53 PM, Rick DeNatale wrote:
>>> I'm a little concerned that some folks are jumping on 1.9 as an
>>> immediate replacement for Ruby 1.8, which it isn't.
>> Me too:
>> http://pragdave.blogs.pragprog.com/pragdave/2007/12/ruby-19right-fo.html
>
> will it be "safe" to say that the baptism of fire for ruby1.9 is
> lettting it run/support rails 2.0.2 without errors?
>
> kind regards -botp
>
>
Well ... *after* it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan Davis' wonderful tools, sure, go ahead and fix Rails. :slight_smile:

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

22

I don't believe that can happen..
Ruby programmers like to be on the cutting edge, it seems..

···

On Dec 27, 2007, at 10:04 AM, Rick DeNatale wrote:

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.

23

Keep in mind that Ruby 1.9 is really a new language, Matz and co
decided to release it as a way of driving towards Ruby 2.0 whose
version number would more clearly indicate this, but there are changes
in 1.9, which are deliberately incompatible with Ruby 1.8. Matz has
spent the past few months backing out some of the more radical
experimental changes, but there's no guarantee of backward
compatibility.

Exactly, 1.9.0 was labeled a "development" release, not a stable, not
the replacement for 1.8 from day zero, will take longer to achieve
that goal.

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.

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.

The problem is that these users don't read things, don't research a
bit before start playing with loaded guns, they didn't read the
_development release_ label matz put on his announcement.

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.

Users experimenting with installation from source should be aware of
these risks. Is not Ruby responsibility to "babysit" all the users and
avoid they shoot their foot.

What you requested will also require a "new" release of 1.9.0-0, (note
the zero of patchlevel), and I think is too early to do it (the
complexity and because matz, ko1 and others need to relax a bit).

···

On Dec 27, 12:04 pm, Rick DeNatale <rick.denat...@gmail.com> wrote:

-
Luis Lavena

24

Rick Denatale wrote:

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.

I don't think so. Add a YOU-SHOULD-REALLY.README file which strongly
recommends to use "--prefix" and "--programm-suffix" in "configure".

Wolfgang Nádasi-Donner

···

--
Posted via http://www.ruby-forum.com/\.

25

Rick DeNatale wrote:

Well ... *after* it works on RSpec, rcov, flog, heckle, ZenTest, and all
of Ryan Davis' wonderful tools, sure, go ahead and fix Rails. :slight_smile:

[snip]

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. :slight_smile:

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
current implementations.

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 ...) :wink:

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.

···

On Dec 27, 2007 4:28 AM, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

26

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.

Given the colossal numbers of clueless posts by Rails newbs that
happen all over the Web, I think that this is an extreeeeeeeeeeemely
good idea.

···

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

27

The problem is that these users don't read things

I dont think that is a huge problem. Just point them to the URL of this
thread/mail where someone stated that "it is a new language", which
kinda says all there is to be said about it in a very concise manner.
It's more a ... paradigm shift than a slow gradual change with baby
steps! :slight_smile:

···

--
Posted via http://www.ruby-forum.com/\.