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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-11 18: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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-11 18: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 Brown
47aff267a58c012d222fd4d74f6beb54?d=identicon&s=25 Dominik Honnef (Guest)
on 2009-02-11 18:19
(Received via mailing list)
+1, even though you failed at changing the text of this mail compared
to the other one.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-11 18:23
(Received via mailing list)
On Wed, Feb 11, 2009 at 12:17 PM, Dominik Honnef <dominikho@gmx.net>
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.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-11 19: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.
D812408537ac3a0fa2fec96eb8811559?d=identicon&s=25 John Carter (johncarter)
on 2009-02-11 21:22
(Received via mailing list)
On Thu, 12 Feb 2009, Gregory Brown 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 Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-11 21:32
(Received via mailing list)
On Wed, Feb 11, 2009 at 3:18 PM, John Carter <john.carter@tait.co.nz>
wrote:
> On Thu, 12 Feb 2009, Gregory Brown 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
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (djberg96)
on 2009-02-11 21:40
(Received via mailing list)
On Feb 11, 10:12 am, Gregory Brown <gregory.t.br...@gmail.com> 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
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-11 22:23
(Received via mailing list)
2009/2/11 Gregory Brown <gregory.t.brown@gmail.com>:
> 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
Aaca034456897ccbc8bb14953c4a41c1?d=identicon&s=25 Radosław Bułat (radarek)
on 2009-02-11 22:47
(Received via mailing list)
On Wed, Feb 11, 2009 at 10:21 PM, Pit Capitain <pit.capitain@gmail.com>
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
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-11 23:03
(Received via mailing list)
2009/2/11 Rados³aw Bu³at <radek.bulat@gmail.com>:
> 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
19fdf8bd123216b5056fb856cf1a5771?d=identicon&s=25 _why (Guest)
on 2009-02-11 23:13
(Received via mailing list)
On Thu, Feb 12, 2009 at 02:12:14AM +0900, Gregory Brown 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
3afd3e5e05dc9310c89aa5762cc8dd1d?d=identicon&s=25 Tim Hunter (Guest)
on 2009-02-11 23: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
C482081f2c6c893c26f72f6e31999bcb?d=identicon&s=25 Zachary Brown (Guest)
on 2009-02-11 23: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.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-02-12 00: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 Gray II
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-02-12 00:37
(Received via mailing list)
On Wed, Feb 11, 2009 at 5:11 PM, _why <why@ruby-lang.org> 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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-12 01:20
(Received via mailing list)
On Wed, Feb 11, 2009 at 12:37 PM, Daniel Berger <djberg96@gmail.com>
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.
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-12 11: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
9b905791cbdbb1af35b65e02c3217e23?d=identicon&s=25 Tom Link (Guest)
on 2009-02-12 12: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.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-12 13:58
(Received via mailing list)
On Wed, Feb 11, 2009 at 6:35 PM, Gregory Brown
<gregory.t.brown@gmail.com>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
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-02-12 16:55
(Received via mailing list)
On 2009-02-11, Pit Capitain <pit.capitain@gmail.com> wrote:
> 2009/2/11 Rados?aw Bu?at <radek.bulat@gmail.com>:
>> 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 Henty
53581739a445ad78250a676dabddf55f?d=identicon&s=25 James Coglan (Guest)
on 2009-02-12 17:01
(Received via mailing list)
2009/2/12 Jeremy Henty <onepoint@starurchin.org>

> > 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.
8c0b7725a68e5cf9a0548065db0e139b?d=identicon&s=25 Coey Minear (cminear)
on 2009-02-12 17:16
(Received via mailing list)
Jeremy Henty writes:
 > On 2009-02-11, Pit Capitain <pit.capitain@gmail.com> wrote:
 > > 2009/2/11 Rados?aw Bu?at <radek.bulat@gmail.com>:
 > >> 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 Henty
 >

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 Minear
F47de131a8f372c1a52262ae95a5b5a6?d=identicon&s=25 Prashant Srinivasan (Guest)
on 2009-02-12 18: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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-12 18:55
(Received via mailing list)
On Thu, Feb 12, 2009 at 10:59 AM, James Coglan
<jcoglan@googlemail.com>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
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-12 20: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...
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-02-13 02:20
(Received via mailing list)
On 2009-02-12, James Coglan <jcoglan@googlemail.com> 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 Henty
50b2daf0e7666574579b9edaf8f2b69a?d=identicon&s=25 Pit Capitain (Guest)
on 2009-02-13 09:32
(Received via mailing list)
2009/2/13 Jeremy Henty <onepoint@starurchin.org>:
> 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
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2009-02-13 14: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.
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2009-02-13 20:25
(Received via mailing list)
On 2009-02-13, Pit Capitain <pit.capitain@gmail.com> wrote:
> 2009/2/13 Jeremy Henty <onepoint@starurchin.org>:
>> 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 Henty
2f55791ab9018b4d01fb741fab21843d?d=identicon&s=25 Tony Arcieri (Guest)
on 2009-02-16 04:59
(Received via mailing list)
On Wed, Feb 11, 2009 at 10:12 AM, Gregory Brown
<gregory.t.brown@gmail.com>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.