[ruby-talk:11254] Re: Summary: RCR #U002 - proper new name for indexes

Aleksi Niemela wrote:

# On Wed, 21 Feb 2001, Conrad Schneiker wrote:
# 
# > James T. Vradelis wrote:
# > # then I'd volunteer to fix whatever that breaks.
# > 
# > Fixing libraries is the easy part--that is just the lookout tower on 
the
# > mountain of Ruby code in the world. And most of the rest of that code
# > people don't want to hand over to strangers to fix. 
# 
# Good point.
# 
# > Indeed, they don't want it broken in the first place. And they don't
# > want the door opened to repeated breaks for other good ideas. This
# > is an unfortunate fact of life that must be a high priority decision
# > criteria if Ruby is to become widely regarded as a serious
# > development programming language.
# 
# I think things are regular enough, if we just keep them that way in
# the future too. The usual story is
# 
#   major version update probably breaks some code
#   minor version update shouldn't

From what I've seen over the last year+ is that the usual story is to
never knowingly break code. And now there is the added incentive not
to invalidate books (published or in the works). 

# If you have production system which runs fine, you _dont_ want to
# upgrade to a newer version. Because if you do, and it happens to be a
# major revision then you have to accept the fact life you might have to
# update your source code too. You have to accept the fact of life you
# might have to update your source code even when doing minor upgrades.

You omitted to quote the most important reasons for not breaking code, 
which is that (for a great many people) it is a big disincentive to use 
Ruby for production programming. 

# No gains without potential pains.

This is a slogan, not a reason, and there are lots of obvious
counterexamples. But if you are one of those people who believe that
the main path of progress is suffering, why not suffer the pain of
backwards compatibility like Perl, Python, and Java mostly do?

# I agree we should minimize even major release griefs, but I think it's
# completely understandable to have them. No one forces anyone to take
# updates.

But if you are continually creating disincentives to use the latest and
greatest stuff, you are also creating major disincentives to use Ruby
in the first place.

# OTOH, if upgrading to a newer version proves to be too difficult but
# still wants the candies there's a way. This is open source after
# all. Just wrap up your own 1.6.2_with_1.7_gc version by backlogging
# 1.7 enhancements into earlier part of source tree. If it's useful
# enough you'll get many fans by giving out it to other people having
# same problems.

This is not the sort of recommendation that makes Ruby a viable sell to 
management relative to (say) Perl or Python or Java. If I were in such a 
management position and read your post and thought it was the standard 
policy, there is no way I would let people use Ruby for major projects. 

In years past, I was willing, able, and allowed to use Perl on a lot of 
stuff because (among other reasons) we could count on stuff that ran once 
to keep on running without having to worry that an upgrade would break 
stuff. (At least as long as you didn't try to use experimental features or 
very tricky stuff that was never previously clearly specified--which 
aren't the sorts of Ruby changes we are talking about.)

I  am all for backwards-incompatible language changes, but if you want 
Ruby to overtake Python and Perl, such changes should all be combined 
together and should only occur about once a decade or so, when you have a 
Perl4 to Perl5 sort of transition.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)