[ruby-core:19239] Re: [ANN] Ruby 1.9.1 feature freeze

At 16:05 08/10/08, Ryan Davis wrote:
>
>On Sep 30, 2008, at 05:24 , Dave Thomas wrote:
>
>> For example, the deprecations are fine in theory. But think about  
>> how tests are supposed to work. You run them, and they're supposed  
>> to be silent. Maybe a row of dots, but that's it. Any output means  
>> there's a problem.
>
>I think it is a cultural problem. We don't have or even support a  
>culture of deprecation, of shedding dead weight.

I think this is true. Finding out what's dead weight is difficult,
and gets more difficult the bigger our systems get.

>Somehow, the idea of  
>announcing ahead of time that you intend to delete code (with a  
>suitable replacement) _sometime_in_the_future_ sends shockwaves of  
>terror throughout the ruby community.

I think that per se is okay. It wasn't the announcement, it was
the actual replacement that produced the shockwaves. When people
hear something, it goes in through one ear and out through the other.
When they feel it, they start to notice.

The fact that the actual replacement came very close to the feature
freeze deadline definitely didn't help; that should have happened
earlier.

>Personally, I find that rather  
>embarrassing as I see nothing better than to reduce the amount of  
>cruft we have and still maintain functionality.

I'd personally be more interested in new and exciting functionality,
but I'm glad there are people like you who think like this.

>> But now, when I run my tests, I get pages of stuff flying by, saying  
>> stuff is deprecated. To someone who lives by tests, this is  
>> incredibly scary.
>>
>> You might say "change your tests". But I think that's being a little  
>> harsh. Part of being compatible with Test::Unit is providing a  
>> similar user-level experience to it. A minor heart attack the first  
>> time you run is a different experience.
>
>Except... we're talking about a __DOT-OH__ release. If this was 1.6.9  
>I'd completely agree, but this is 1.9.0 and we've had no problems with  
>incompatibilities thus far. Think about the number of tests that are  
>going to fail that expect String#[n] to return an int that are now  
>going to blow up. Somehow that's OK, yet deprecating poorly named API  
>is not? No. Dot-Ohs are where we introduce our incompatibilities.

This is also true, except that, as discussion just very recently
has shown, there is quite some disagreement about what's the best
naming convention, whereas for String#[n], while some people in
some cases be helped if that addressed bytes, it's rather clear
that the new way is the right way once you have understood the
difference between bytes and character.


>And in this case, we're not even talking actual breakage... that's the  
>thing that is killing me. We're talking about 100% compatible API,  
>telling you that you're going to need to change it in the future.

Again, assuming that there would be reasonable agreement about
the direction to go with the names, that would be fine, 

>Yet, somehow, this is a huge thing that is totally freaking everyone  
>out. I just don't get it at all, esp. given how long this has been in  
>the works and how shockingly little feedback there was that whole time.

There is a huge difference between "hey, look at this and try it out"
(just a few people looking at it) and putting it into the mainstream,
replacing something well-known (everybody gets hit, and starts
complaining).

Regards,     Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]