From: Francis Hwang <sera@...>
Date: 2005-02-01T14:13:41+09:00
Subject: Re: Is compatibility important for us?


On Jan 31, 2005, at 11:40 PM, Trans wrote:

> Francis,
>
> Your analysis is clear and consistant but I believe it is shallow. Ruby
> as a language should always be in flux. Dynamic with its creation as it
> is in its nature. Backward compatiability is not strictly neccessary,
> it is nothing more the a vehicle for the user to more easily transition
> to the next update. If you require stability then you should never
> upgrade beyond a teeny. But if you are upgrading to gain features,
> which is the reasonable reason to do so, then you have nothing to
> complain about --you are getting exactly what you are asking for:
> changes.

Not all programmers are operating in an environment in which they have 
complete control of their Ruby dependencies, for example, the case I 
mentioned when I was the programmer for a small e-commerce site on a 
shared server. Although the list of hosting providers who put Ruby on 
their shared servers is growing quickly, I think you'd have to hunt 
really hard for somebody who purposely held back from upgrades to 
1.8.3, etc. Of course, if you had enough resources you could just run a 
dedicated box (I do this at my day job) but not everybody does, so they 
don't.

Your position is that you want Ruby to remain dynamic, and to favor 
innovation over backwards compatibility. As a programmer, I'm largely 
in agreement with that. But as somebody who provides libraries that are 
occasionally aimed at novice users, as somebody who regularly meets 
Ruby novices in the user's group I organize, and as somebody who wants 
to see the number of people making a living with Ruby increase steadily 
every year, I can easily understand how somebody who's thinking of 
advocating for Ruby at his workplace might find this sort of attitude 
about backwards compatibility off-putting.

I also think this doesn't necessarily have to be a simple case of 
either-or. The two don't really have to be in conflict that often, and 
when they do, there are lots of ways to make that conflict less 
painful. For one thing, I still don't have a good sense of how stable 
the standard library APIs are expected to be, and therefore how much I 
can rely on their longevity both as a day-to-day programmer and a 
library maintainer. I also think we could do a better job of 
documenting breaks in new versions--for example, I'm trying to Google 
for a note that explicitly tells me that Marshal formats are 
incompatible going forward from 1.6.8 to 1.8.2, and I'm not finding 
anything outside of the mailing list archives.

Francis Hwang
http://fhwang.net/