Forum: Ruby If you are happy with the direction of Ruby 1.8.7+, respond

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Gregory B. (Guest)
on 2009-02-11 19:14
(Received via mailing list)
I am setting up two threads in the hopes that we can see names
attached to opinions about the decision to break backwards
compatibility between Ruby 1.8.6 and Ruby 1.8.7+
This one is for those who wish that Ruby 1.8 would go *back* to being
1.8.6 compatible in Ruby 1.8.8.   If you agree with this, share your
thoughts or at least a simple '+1'.  If you disagree, please find the
other thread titled 'If you are happy with the direction of Ruby
1.8.7, respond'.  If you are in the middle, I don't know what you
should do... write two posts?

My goal is to survey ruby-talk so that the core Ruby team has a chance
to see what people really want.  I'm curious to see if this is as
one-sided as I think it is.
Gregory B. (Guest)
on 2009-02-11 19:19
(Received via mailing list)
Whoops, regretting this idea already, but I need to correct this:

This thread is for if you are *happy* with the backports from Ruby 1.9
and want to see more.  If you agree, share your thoughts.
If you disagree, please find the 'if you are unhappy with the
direction of 1.8.7+' post.

On Wed, Feb 11, 2009 at 12:13 PM, Gregory B.
Dominik H. (Guest)
on 2009-02-11 19:19
(Received via mailing list)
+1, even though you failed at changing the text of this mail compared
to the other one.
Gregory B. (Guest)
on 2009-02-11 19:23
(Received via mailing list)
On Wed, Feb 11, 2009 at 12:17 PM, Dominik H. 
<removed_email_address@domain.invalid>
wrote:
> +1, even though you failed at changing the text of this mail compared
> to the other one.

Noticed that just after I posted, sorry.
David M. (Guest)
on 2009-02-11 20:00
(Received via mailing list)
I'm writing two posts.

A side effect of 1.8.7 is, it sort of pulls the rug out from under
people wanting to stay on the older, stable version. I really don't see
a reason why 1.8 shouldn't have features like Symbol#to_proc, or
Object#tap, or the other things I like from 1.9 -- even some of the
syntax seems harmless, and unlikely to break anything.

Also, as a user, it seems everything I try works on 1.8.7, while not
everything works on 1.9 yet. So either it really is a gentler upgrade,
or people are feeling compelled to have their gems working on the latest
stable version. So in cases where I can't use 1.9, I can at least get
closer.
John C. (Guest)
on 2009-02-11 22:22
(Received via mailing list)
On Thu, 12 Feb 2009, Gregory B. wrote:

> My goal is to survey ruby-talk so that the core Ruby team has a chance
> to see what people really want.  I'm curious to see if this is as
> one-sided as I think it is.

Always make forward progress. I'm happy to move to 1.91 and beyond
asap.

That's why I have a really good suite of unit tests. To catch most of
that class of breakage.



John C.                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : 
removed_email_address@domain.invalid
New Zealand
Gregory B. (Guest)
on 2009-02-11 22:32
(Received via mailing list)
On Wed, Feb 11, 2009 at 3:18 PM, John C. <removed_email_address@domain.invalid>
wrote:
> On Thu, 12 Feb 2009, Gregory B. wrote:
>
>> My goal is to survey ruby-talk so that the core Ruby team has a chance
>> to see what people really want.  I'm curious to see if this is as
>> one-sided as I think it is.
>
> Always make forward progress. I'm happy to move to 1.91 and beyond
> asap.

This isn't about Ruby 1.9.1.  I'm all for that migration too. (My book
"Ruby Best Practices" is on Ruby 1.9.1 *only*)
I'm talking specifically about the 1.8 branch here.

-greg
Daniel B. (Guest)
on 2009-02-11 22:40
(Received via mailing list)
On Feb 11, 10:12 am, Gregory B. <removed_email_address@domain.invalid> wrote:
> My goal is to survey ruby-talk so that the core Ruby team has a chance
> to see what people really want.  I'm curious to see if this is as
> one-sided as I think it is.

Given that I have my own fork, I would say the answer is no, I'm not
happy with the direction of 1.8.x. :)

Regards,

Dan
Pit C. (Guest)
on 2009-02-11 23:23
(Received via mailing list)
2009/2/11 Gregory B. <removed_email_address@domain.invalid>:
> I am setting up two threads in the hopes that we can see names
> attached to opinions about the decision to break backwards
> compatibility between Ruby 1.8.6 and Ruby 1.8.7+

Can you show us some examples of 1.8.6 code that doesn't work in 1.8.7?

Regards,
Pit
Radosław B. (Guest)
on 2009-02-11 23:47
(Received via mailing list)
On Wed, Feb 11, 2009 at 10:21 PM, Pit C. <removed_email_address@domain.invalid>
wrote:
>
h={}
h[{"foo" => 1}] = 100
p h[{"foo" => 1}]

ruby 1.8.6 prints "nil", 1.8.7 prints "100".

--
Pozdrawiam

Rados³aw Bu³at
http://radarek.jogger.pl - mój blog
Pit C. (Guest)
on 2009-02-12 00:03
(Received via mailing list)
2009/2/11 Rados³aw Bu³at <removed_email_address@domain.invalid>:
> h={}
> h[{"foo" => 1}] = 100
> p h[{"foo" => 1}]
>
> ruby 1.8.6 prints "nil", 1.8.7 prints "100".

Ah, you mean Hash#hash. Thanks a lot, I didn't know that. But this is
an example where the 1.8.7 version yields the result most people would
expect, so I see this more like a "feature" fix (not a bug fix,
because it hasn't been an official bug AFAIK). I can't imagine any
code that depends on the behaviour of 1.8.6. Or do you have an
example?

Regards,
Pit
_why (Guest)
on 2009-02-12 00:13
(Received via mailing list)
On Thu, Feb 12, 2009 at 02:12:14AM +0900, Gregory B. wrote:
> I am setting up two threads in the hopes that we can see names
> attached to opinions about the decision to break backwards
> compatibility between Ruby 1.8.6 and Ruby 1.8.7+

Mostly happy. I haven't seen the bogeymen reported by many people in
1.8.7. There is String#chars, but that seemed pretty easy to move
past. If there are crashes, pull out gdb and let's see them. Shoes
has had Ruby 1.8.7 within, since shortly after it was released.

Folks, I'd stay away from the heavy-handed approach with Matz. He
doesn't respond to a mob. And despite all the hype and business that
now revolves around Ruby, it's still the man's language and his life
work.

Sometimes this community feels like one of those marriages where the
lady marries the guy because she thinks she can change the guy.
But the guy's the guy! I don't know.

_why
Tim H. (Guest)
on 2009-02-12 00:27
(Received via mailing list)
_why wrote:
> Folks, I'd stay away from the heavy-handed approach with Matz. He
> doesn't respond to a mob. And despite all the hype and business that
> now revolves around Ruby, it's still the man's language and his life
> work.

+1
Zachary Brown (Guest)
on 2009-02-12 00:43
(Received via mailing list)
On Feb 11, 2009, at 5:11 PM, _why wrote:

> Folks, I'd stay away from the heavy-handed approach with Matz. He
> doesn't respond to a mob. And despite all the hype and business that
> now revolves around Ruby, it's still the man's language and his life
> work.
>
> ...
> _why
>

+1 for either path that is taken.
James G. (Guest)
on 2009-02-12 01:29
(Received via mailing list)
On Feb 11, 2009, at 4:11 PM, _why wrote:

> Folks, I'd stay away from the heavy-handed approach with Matz. He
> doesn't respond to a mob.

I agree with this fully and I don't feel like I've joined a mob.  I'm
not angry or out of control.

I'm saying the new version process scare me.  It's just an FYI for
Matz and the core team.  If they ignore it, well, that's how it
goes.  :)

James Edward G. II
Gregory B. (Guest)
on 2009-02-12 01:37
(Received via mailing list)
On Wed, Feb 11, 2009 at 5:11 PM, _why <removed_email_address@domain.invalid> 
wrote:

> Folks, I'd stay away from the heavy-handed approach with Matz. He
> doesn't respond to a mob. And despite all the hype and business that
> now revolves around Ruby, it's still the man's language and his life
> work.

Ah, but it's not Matz's issue.  I actually love Ruby 1.9.1,  and every
time I ask Matz about this he says "I don't maintain 1.8".
The issue is not with change, but with change that something that was
previously labeled non-changing in a defacto way .

-greg
M. Edward (Ed) Borasky (Guest)
on 2009-02-12 02:20
(Received via mailing list)
On Wed, Feb 11, 2009 at 12:37 PM, Daniel B. 
<removed_email_address@domain.invalid>
wrote:
> Given that I have my own fork, I would say the answer is no, I'm not
> happy with the direction of 1.8.x. :)

Could you give me a link to that fork?
--
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.
Charles Oliver N. (Guest)
on 2009-02-12 12:27
(Received via mailing list)
_why wrote:
> Folks, I'd stay away from the heavy-handed approach with Matz. He
> doesn't respond to a mob. And despite all the hype and business that
> now revolves around Ruby, it's still the man's language and his life
> work.
>
> Sometimes this community feels like one of those marriages where the
> lady marries the guy because she thinks she can change the guy.
> But the guy's the guy! I don't know.

Unless, of course, the guy can be convinced that he's causing the lady
some sort of pain and seek to change himself. Quietly ignoring the
problem is what *leads* to mobs and divorces. I think what we're doing
here is entirely appropriate: raise concerns, discuss, hope for change
or compromise.

It may be Matz's language, but it's everyone's community.

- Charlie
Tom L. (Guest)
on 2009-02-12 13:50
(Received via mailing list)
> Given that I have my own fork, I would say the answer is no, I'm not
> happy with the direction of 1.8.x. :)

This is the happy thread and I'm happy with 1.8.7 -- well, sort of but
I personally like the changes I know of. I have to say though that I
find the idea to backport even more 1.9 features to 1.8 as strange as
the idea to forget about 1.8.7 and move back to 1.8.6. I'd have
expected 1.8 to be in maintenance mode after 1.9.1 was released.
Rick D. (Guest)
on 2009-02-12 14:58
(Received via mailing list)
On Wed, Feb 11, 2009 at 6:35 PM, Gregory B.
<removed_email_address@domain.invalid>wrote:

> previously labeled non-changing in a defacto way .
>

Right to the point!  I too love Ruby 1.9.1 and Matz! but...

Ruby 1.8 (excluding 1.8.7) and Ruby 1.9 are really two different
languages,
I can deal with that as long as I know, and can control which of the two
I'm
using at any given time for any given application.

Matz ceded maintenance of the "1.8" stream and moved on to 1.9 some time
ago. The 1.8.7 release, rather than simply fixing bugs and maintaining
compatibility, was attracted by "shiny objects" from 1.9 and wreaked
havoc
on some important consumers of Ruby, exacerbated by the eagerness of
downstream package maintainers to keep up without understanding the
ramifications of the breach of the implication of compatibility between
versions with the same minor version number.

Ruby 1.8.6 represents the latest version of the old Ruby language, 1.9.1
is
the latest version of the new Ruby language, Ruby 1.8.7 is a mutant
which
just muddies the waters.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
Jeremy H. (Guest)
on 2009-02-12 17:55
(Received via mailing list)
On 2009-02-11, Pit C. <removed_email_address@domain.invalid> wrote:
> 2009/2/11 Rados?aw Bu?at <removed_email_address@domain.invalid>:
>> h={}
>> h[{"foo" => 1}] = 100
>> p h[{"foo" => 1}]
>>
>> ruby 1.8.6 prints "nil", 1.8.7 prints "100".
>
> Ah, you mean  Hash#hash. Thanks a lot, I didn't  know that. But this
> is an example where the  1.8.7 version yields the result most people
> would expect,

No  it doesn't.   Most people  would expect  1.8.7 to  yield  the same
result as 1.8.6 .  That is the point.

Regards,

Jeremy H.
James C. (Guest)
on 2009-02-12 18:01
(Received via mailing list)
2009/2/12 Jeremy H. <removed_email_address@domain.invalid>

> > would expect,
>
> No  it doesn't.   Most people  would expect  1.8.7 to  yield  the same
> result as 1.8.6 .  That is the point.



Though I fall on the 'unhappy' side, this change is clearly fine: 1.8.6
behaviour is clearly a bug and should be fixed, that's the point of bug
fix
releases. Relying on buggy behaviour is a bad idea, and so is making
changes
to ostensibly correct behaviour in minor releases.
Coey M. (Guest)
on 2009-02-12 18:16
(Received via mailing list)
Jeremy H. writes:
 > On 2009-02-11, Pit C. <removed_email_address@domain.invalid> wrote:
 > > 2009/2/11 Rados?aw Bu?at <removed_email_address@domain.invalid>:
 > >> h={}
 > >> h[{"foo" => 1}] = 100
 > >> p h[{"foo" => 1}]
 > >>
 > >> ruby 1.8.6 prints "nil", 1.8.7 prints "100".
 > >
 > > Ah, you mean  Hash#hash. Thanks a lot, I didn't  know that. But
this
 > > is an example where the  1.8.7 version yields the result most
people
 > > would expect,
 >
 > No  it doesn't.   Most people  would expect  1.8.7 to  yield  the
same
 > result as 1.8.6 .  That is the point.
 >
 > Regards,
 >
 > Jeremy H.
 >

As I read this, my feeling about what "most people" would expect
should fall into one of two categories:
 - hashes should allow (different) hashes to be used as keys; or
 - hashes should _not_ allow hashes to be used as keys.

If someone feels the first response is correct, then '100' would be
what they expect from Ruby.  If someone feels the second response is
correct, then they would probably expect a SyntaxError or RuntimeError
exception to be thrown.

So from my perspective, having a hash with a hash as a key return
'nil' is a bug (in the example given above, where it was previously
set), and bugs should be fixed, in all versions.  You are arguing from
the third camp of "I'm used to the bug so please don't fix it."

Of course, these are just my opinions.  And in general, I do fall into
the "don't change the API behavior between 1.8.6 and 1.8.7" camp.  But
in this case, I would say the 1.8.6 behavior described is a bug and
should be addressed.


Coey M.
Prashant Srinivasan (Guest)
on 2009-02-12 19:13
(Received via mailing list)
I'm in the happy camp, mostly.  It's fine to add new features to an
upwardly compatible release as long as one doesn't sacrifice the
stability(given this is a "production" release) - i.e., upwardly
compatible does NOT mean that feature set of version x.y.z should be the
same as the feature set of x.y.z+1.  API compatibility across 'teeny'
releases is important, and, is something Matz and others have
professed(in a thread I don't have a pointer handy, but it's on
ruby-core).

 Fixes to bugs, IMO, cannot be counted as making the software
incompatible - if they did, the language implementation would get
nowhere.

 On the other hand, changes to the existing APIs that are not generally
accepted as bugs definitely count as incompatibilities - IMO, it's this
area thats tinged with shades of gray, since I cannot easily tell if
some 'bug fixes' are indeed 'bug fixes' or if they break the
compatibility expectations that the Ruby versioning system sets.(  I
work for a Ruby vendor that, among other things, promises compatibility,
and any mixed bag of fixes + compatibility breakages, if indeed it is
so, is an issue to deal with).

Just my 2 cents,
 -ps
Rick D. (Guest)
on 2009-02-12 19:55
(Received via mailing list)
On Thu, Feb 12, 2009 at 10:59 AM, James C.
<removed_email_address@domain.invalid>wrote:

> > > Ah, you mean  Hash#hash. Thanks a lot, I didn't  know that. But this
> releases. Relying on buggy behaviour is a bad idea, and so is making
> changes
> to ostensibly correct behaviour in minor releases.
>

The problem is that one man's bug is another's breaking change.  Lot's
of
people always found the fact that Strings acted like collections of
character codes rather than characters as a bug.

>ruby -e'p "abc"[0]'
97

fixed by 1.9
 >ruby1.9 -e'p "abc"[0]'
"a"

But there is a lot of Ruby <1.8.7 code whose correct behavior depends on
that "bug" considering it part of the old Ruby language definition.

And there's lots of history of that behavior being defined not as a bug
but
as the way that Ruby works.

The problem with making semantic changes like this, whether they are
pseudo-bugfixes or not, is that it's very hard to sort out ahead of time
what impact they will have on the installed base of code using the
'stable'
version.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
Phlip (Guest)
on 2009-02-12 21:37
(Received via mailing list)
> result as 1.8.6 .  That is the point.
I did not know 1.8.6 returned the counterintuitive result. Hence...
Jeremy H. (Guest)
on 2009-02-13 03:20
(Received via mailing list)
On 2009-02-12, James C. <removed_email_address@domain.invalid> wrote:
>> That is the point.
>
> Though I  fall on the 'unhappy'  side, this change  is clearly fine:
> 1.8.6 behaviour  is clearly  a bug and  should be fixed,  that's the
> point of bug fix releases. Relying on buggy behaviour is a bad idea,
> and so  is making changes  to ostensibly correct behaviour  in minor
> releases.

OK, I accept  your point for this particular  change.  It doesn't hold
for other changes, eg. methods returning Enumerators when they used to
return Arrays.

Regards,

Jeremy H.
Pit C. (Guest)
on 2009-02-13 10:32
(Received via mailing list)
2009/2/13 Jeremy H. <removed_email_address@domain.invalid>:
> OK, I accept  your point for this particular  change.  It doesn't hold
> for other changes, eg. methods returning Enumerators when they used to
> return Arrays.

Jeremy, can you show us an example?

Regards,
Pit
Robert H. (Guest)
on 2009-02-13 15:15
I am indifferent to it, may I post here as well? :-)

My only general complaint would be that I think that some releases may
have more bugs than others. Maybe a year ago, the ruby release candidate
for some 1.9.x version had an irb which segfaulted for me. The later
1.9.x irb didn't segfault anymore. Irb is quite important for me so I
was surprised to see irb has had difficulties.

My wish would be that the amount of bugs is kept to a minimum.
Jeremy H. (Guest)
on 2009-02-13 21:25
(Received via mailing list)
On 2009-02-13, Pit C. <removed_email_address@domain.invalid> wrote:
> 2009/2/13 Jeremy H. <removed_email_address@domain.invalid>:
>> OK, I accept  your point for this particular  change.  It doesn't hold
>> for other changes, eg. methods returning Enumerators when they used to
>> return Arrays.
>
> Jeremy, can you show us an example?

Annoyingly, no.   I was repeating something  I was sure  had been said
elsewhere in these threads, but  despite having trawled around my news
server and  Google groups I  can't find the  post.  So maybe  I *have*
been spreading FUD after all.  :-( My apologies if so.

Regards,

Jeremy H.
Tony A. (Guest)
on 2009-02-16 05:59
(Received via mailing list)
On Wed, Feb 11, 2009 at 10:12 AM, Gregory B.
<removed_email_address@domain.invalid>wrote:

> This one is for those who wish that Ruby 1.8 would go *back* to being
> 1.8.6 compatible in Ruby 1.8.8.   If you agree with this, share your
> thoughts or at least a simple '+1'.  If you disagree, please find the
> other thread titled 'If you are happy with the direction of Ruby
> 1.8.7, respond'.  If you are in the middle, I don't know what you
> should do... write two posts?
>

If you ask me, what the Pythonistas got right that Ruby 1.8.7+ does not
is:

  from __future__ import x

I think it's great that Ruby 1.8.7+ wants to include all these nifty 1.9
features.  But, I don't think they should be "on" by default.

I think it'd be great if certain features (e.g. the 1.9.x enumerators)
were
available if you were to, say, require "future/enumerator" or something.

If that were the case, I'd be on board with backporting everything,
although
changes to the grammar of the language itself might be difficult to
enable
in this manner, and many bring backwards compatibility issues.
This topic is locked and can not be replied to.