[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Is compatibility important for us?

Esteban Manchado Velázquez

2/1/2005 12:03:00 AM

Hi all,

First of all, I love Ruby and I'm _not_ trolling with this message :-)

Perhaps it's just a matter of Ruby being a young language, but I find it
too common that you have to use newer versions of Ruby for "many" (for some
definition of "many") application/libraries to work.

Of course, I can understand that for large applications, you may want to
rely on "advanced" features/libraries from the newer versions of the Ruby
distribution, but I find it frankly annoying that "many" applications require
a relatively new version of Ruby.

In particular, to use RoR, it seems that you need not only 1.8.x, but 1.8.1
or higher. And, moreover, upgrading the version of RoR breaks applications. Is
it really necessary breaking compatibility? Is this situation that way only
because RoR is < 1.0? David?

The thing is, many people _can't_ (or don't want to) upgrade their Ruby
interpreter, so we're raising the bar here for the adoption of Ruby :-( For
example, people using Debian stable (flames to /dev/null, please) _can't_
upgrade their Ruby interpreters. If they did, they would lose the benefits of
"automatic" security upgrades.

And, of course, that mostly fine for _developers_ who happen to administer
the machines they work on, but when administrator and developer aren't the
same person or don't share the same interests, the administrator usually
doesn't give a #### (insert your favourite four-letter bad word here) about
having a recent Ruby interpreter (WTF?).

So, I wanted to share these thoughts with you all, and wondered what are
your thoughts on this....

Regards,

--
Esteban Manchado Velázquez <zoso@foton.es> - http://ww...
EuropeSwPatentFree - http://EuropeSwPatentFree.his...
27 Answers

Francis Hwang

2/1/2005 12:35:00 AM

0

I'm not a Rails user, so maybe somebody can clarify: Where is that
dependency coming from? Is it one of the Ruby standard libraries?

Regarding the dependency, I suppose it's up to the decision of the
individual library maintainer. Since Ruby 1.8.2 has only been out for
about a month, personally I'd feel a little iffy about making that
requirement for my web framework ... or maybe not, seeing as how
Feedblender requires 1.8.2 because it needs the RSS library built-in.
;)

I think it's fair to say that the Ruby community is still quite small
and expert-heavy, so people releasing libraries are relatively okay
with breaking previous versions because it's assumed that most of their
users won't have a problem keeping track of dependencies. As Ruby grows
and Takes Over All Computing As We Know It, this mix will probably
change, and maintainers of various libraries will feel more gentle
pressure to work harder to maintain backwards compatibility.

Perhaps the time to start feeling that gentle pressure is already upon
us?




On Jan 31, 2005, at 7:03 PM, Esteban Manchado Velázquez wrote:

> Hi all,
>
> First of all, I love Ruby and I'm _not_ trolling with this message
> :-)
>
> Perhaps it's just a matter of Ruby being a young language, but I
> find it
> too common that you have to use newer versions of Ruby for "many" (for
> some
> definition of "many") application/libraries to work.
>
> Of course, I can understand that for large applications, you may
> want to
> rely on "advanced" features/libraries from the newer versions of the
> Ruby
> distribution, but I find it frankly annoying that "many" applications
> require
> a relatively new version of Ruby.
>
> In particular, to use RoR, it seems that you need not only 1.8.x,
> but 1.8.1
> or higher. And, moreover, upgrading the version of RoR breaks
> applications. Is
> it really necessary breaking compatibility? Is this situation that way
> only
> because RoR is < 1.0? David?
>
> The thing is, many people _can't_ (or don't want to) upgrade their
> Ruby
> interpreter, so we're raising the bar here for the adoption of Ruby
> :-( For
> example, people using Debian stable (flames to /dev/null, please)
> _can't_
> upgrade their Ruby interpreters. If they did, they would lose the
> benefits of
> "automatic" security upgrades.
>
> And, of course, that mostly fine for _developers_ who happen to
> administer
> the machines they work on, but when administrator and developer aren't
> the
> same person or don't share the same interests, the administrator
> usually
> doesn't give a #### (insert your favourite four-letter bad word here)
> about
> having a recent Ruby interpreter (WTF?).
>
> So, I wanted to share these thoughts with you all, and wondered
> what are
> your thoughts on this....
>
> Regards,
>
> --
> Esteban Manchado Velázquez <zoso@foton.es> - http://ww...
> EuropeSwPatentFree - http://EuropeSwPatentFree.his...
>
>

Francis Hwang
http://f...

James Britt

2/1/2005 12:37:00 AM

0

Esteban Manchado Velázquez wrote:
> Hi all,
>
> First of all, I love Ruby and I'm _not_ trolling with this message :-)

Good start!

>
> Perhaps it's just a matter of Ruby being a young language, but I find it
> too common that you have to use newer versions of Ruby for "many" (for some
> definition of "many") application/libraries to work.

Well, I'm guessing you mean "many" to mean "a lot, maybe most", or this
wouldn't be an issue.

>
> Of course, I can understand that for large applications, you may want to
> rely on "advanced" features/libraries from the newer versions of the Ruby
> distribution, but I find it frankly annoying that "many" applications require
> a relatively new version of Ruby.

I can understand that, though for many Rubyists 1.8.2 has a been a long
time coming, and people have been working and playing with 1.7 , 1.8.x,
and previews of 1.8.2 prior to the final release. There is a good
chance that new features or fixes are in 1.8 precisely because of this,
and the people pushing for these changes tend to be the same ones
writing a good many applications.

>
> In particular, to use RoR, it seems that you need not only 1.8.x, but 1.8.1
> or higher. And, moreover, upgrading the version of RoR breaks applications. Is
> it really necessary breaking compatibility? Is this situation that way only
> because RoR is < 1.0? David?

What breaks, other than Rails apps, if you update your version of Rails?

(I can't speak for David, but I believe that if an application or
framework is pre version 1 then all bets are off, until there comes a
release candidate or something along those lines. I also think David
and Co. have been very good about minimizing breakage, and explaining
the steps to take to fix said breakage.)

>
> The thing is, many people _can't_ (or don't want to) upgrade their Ruby
> interpreter, so we're raising the bar here for the adoption of Ruby :-( For
> example, people using Debian stable (flames to /dev/null, please) _can't_
> upgrade their Ruby interpreters. If they did, they would lose the benefits of
> "automatic" security upgrades.

I'd be interested in some rough figures, as my limited impression is
that getting and installing Ruby is dead simple, so the main barriers
would be personal choice or company policy, and that most Rubyists
exercise the option to update when there is a new stable version.

>
> And, of course, that mostly fine for _developers_ who happen to administer
> the machines they work on, but when administrator and developer aren't the
> same person or don't share the same interests, the administrator usually
> doesn't give a #### (insert your favourite four-letter bad word here) about
> having a recent Ruby interpreter (WTF?).
>
> So, I wanted to share these thoughts with you all, and wondered what are
> your thoughts on this....

There's a certain chicken-and-egg thing here. Some apps would be harder
to write and distribute if they relied on Ruby 1.6; they might not ever
get written, so the motivation to get Ruby would be less. I think the
adoption of Ruby is driven by a combination of language features (which
have improved with each version) and available apps and libs (the number
of which grows more plentiful with each version of Ruby). It can be a
drag to have to forgo using new shiny apps because they mandate Ruby
1.8.2 but, overall, more people are benefiting this way.

Question for the group: Is there a lib or something that one could
install to boost a default 1.6 Ruby installation into behaving as if it
were 1.8? A shim of some sort, one that doesn't require you to be root?

James

Dick Davies

2/1/2005 1:10:00 AM

0

* James Britt <jamesUNDERBARb@neurogami.com> [0237 00:37]:

to OP: I feel your pain (netbsd didn't have 1.8 until very
recently), but the latest 1.8 really is a big change from 1.6.
It saves a lot of bother (for the developer and the users) to
have the extra libraries available.

And it's really not a lot of work to build from source, only takes
about 15 minutes. You can play with that while nagging your distro
maintainer to upgrade :)

> Question for the group: Is there a lib or something that one could
> install to boost a default 1.6 Ruby installation into behaving as if it
> were 1.8? A shim of some sort, one that doesn't require you to be root?

There's ruby-shim :)

http://raa.ruby-lang.org/project/shim-...

--
'I should have been a plumber.'
-- Albert Einstein
Rasputin :: Jack of All Trades - Master of Nuns

Francis Hwang

2/1/2005 2:21:00 AM

0


On Jan 31, 2005, at 7:37 PM, James Britt wrote:

> I can understand that, though for many Rubyists 1.8.2 has a been a
> long time coming, and people have been working and playing with 1.7 ,
> 1.8.x, and previews of 1.8.2 prior to the final release. There is a
> good chance that new features or fixes are in 1.8 precisely because of
> this, and the people pushing for these changes tend to be the same
> ones writing a good many applications.

But "been a long time coming" is not the same thing as "has been
released for some time." 1.8.2 has only been out for about one month,
so if you're a fairly conservative adopter, it's reasonable to expect
that you might still be back at the last stable version.

Though now, for some reason, I forget: When was the last stable version
before 1.8.2? Was this 1.8.0? I can't find this online.

> I'd be interested in some rough figures, as my limited impression is
> that getting and installing Ruby is dead simple, so the main barriers
> would be personal choice or company policy, and that most Rubyists
> exercise the option to update when there is a new stable version.

What about compatibility with previous versions in the std lib? I wrote
a Ruby-driven e-commerce site in 2002, using Ruby 1.6, and those
versions of Marshal and Eruby. When the host upgraded to 1.8.2, the
site fell down like a ton of bricks, because those libraries were
massively backwards incompatible. Luckily, I was available to fix it
posthaste, but if I had been, say, on vacation, or no longer working
with that company, they would have been screwed.

I don't say this to complain, but just to point out that Ruby is still
probably quite a bit less stable than other languages, like Perl or
Java. Now, we're adding amazing libraries and frameworks at a
blistering rate, so I think this is sort of the natural consequence of
high-speed innovation. But if we want Ruby to get wider adoption, we
have to be prepared for the fact that not everybody is an early
adopter, and they will stay out of the fray if they sense that diving
in will consign them to spend too much time worrying about their
dependencies.

Francis Hwang
http://f...

Eric Hodel

2/1/2005 3:17:00 AM

0

On 31 Jan 2005, at 18:21, Francis Hwang wrote:

> On Jan 31, 2005, at 7:37 PM, James Britt wrote:
>
>> I can understand that, though for many Rubyists 1.8.2 has a been a
>> long time coming, and people have been working and playing with 1.7 ,
>> 1.8.x, and previews of 1.8.2 prior to the final release. There is a
>> good chance that new features or fixes are in 1.8 precisely because
>> of this, and the people pushing for these changes tend to be the same
>> ones writing a good many applications.
>
> But "been a long time coming" is not the same thing as "has been
> released for some time." 1.8.2 has only been out for about one month,
> so if you're a fairly conservative adopter, it's reasonable to expect
> that you might still be back at the last stable version.
>
> Though now, for some reason, I forget: When was the last stable
> version before 1.8.2? Was this 1.8.0? I can't find this online.

1.8.1

>> I'd be interested in some rough figures, as my limited impression is
>> that getting and installing Ruby is dead simple, so the main barriers
>> would be personal choice or company policy, and that most Rubyists
>> exercise the option to update when there is a new stable version.
>
> What about compatibility with previous versions in the std lib? I
> wrote a Ruby-driven e-commerce site in 2002, using Ruby 1.6, and those
> versions of Marshal and Eruby. When the host upgraded to 1.8.2, the
> site fell down like a ton of bricks, because those libraries were
> massively backwards incompatible. Luckily, I was available to fix it
> posthaste, but if I had been, say, on vacation, or no longer working
> with that company, they would have been screwed.

Marshal format has always been tied to Ruby version, but care has been
taken to make it as compatible as possible. Unfortunately, a good
alternative format for persisting data didn't exist for very long in
the 1.6 series.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Francis Hwang

2/1/2005 3:37:00 AM

0


On Jan 31, 2005, at 10:16 PM, Eric Hodel wrote:

> On 31 Jan 2005, at 18:21, Francis Hwang wrote:
>> What about compatibility with previous versions in the std lib? I
>> wrote a Ruby-driven e-commerce site in 2002, using Ruby 1.6, and
>> those versions of Marshal and Eruby. When the host upgraded to 1.8.2,
>> the site fell down like a ton of bricks, because those libraries were
>> massively backwards incompatible. Luckily, I was available to fix it
>> posthaste, but if I had been, say, on vacation, or no longer working
>> with that company, they would have been screwed.
>
> Marshal format has always been tied to Ruby version, but care has been
> taken to make it as compatible as possible. Unfortunately, a good
> alternative format for persisting data didn't exist for very long in
> the 1.6 series.

Sure. And since I'm not smart enough to have programmed the Marshal lib
in the first place, I'm not complaining. But I'm an exception, as are
most of the regulars here on ruby-talk. There are, believe it or not,
lots and lots of programmers who really don't want to spend a lot of
time managing dependencies and worrying about upgrades. Some of these
programmers, in fact, almost never compile from source or have access
to root on the machines they use. And they have no way of looking into
Ruby and its standard libs, and knowing what parts of the ever-growing
API will work in a year, and what will break without warning, and so
some of them are going to keep muddling away in Java or Perl or
whatever.

Now, maybe that's a price we're willing to pay to keep up a certain
rate of progress; maintaining backwards compatibility certainly can
slow down development and API improvement. But if that's the case, we
should be ready for Ruby to stay a fringe language. And we should pay
other programmers the respect of letting them know that when they're
considering getting into Ruby.

Francis Hwang
http://f...

Trans

2/1/2005 4:38:00 AM

0

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.

Now changes can still come in non-back breaking formations. And too
many concurrent changes would be too hard to keep pace of, let alone
become familiar. Nonetheless, the leaders of Ruby, Matz most among
them, seem to spend a great deal of time worrying about compatibilty.
Perhaps too much.

Forgive the aside, "Matz, if ever there was something you really wanted
to do to this lanuage, but were too afraid because of the pressures of
backward compatability, I would want you to throw your back to the wind
and just do it! Believe me when I tell you, I trust you. You brought us
this far. Have you not?"

But to the point at hand, I can only recommed an attempt at
establishing stronger communites around older versions. 1.4.* and 1.6.*
as we do the latest 1.8.* and 1.9 dev. Perhaps even rotating mailing
lists. I don't know about you, but the mailing list archives are
getting pretty full. Would mailing lists dedicated to older versions be
useful? Really, would they?

I suspect it is too difficult a task for lack of real interest. I know
about such things. But even small groups have value. Nonethelss my
guess is that most people really want the upgrades, even if they
readily complain about the difficulites of dealing with them.
respectfully,
T

Francis Hwang

2/1/2005 5:14:00 AM

0


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://f...

Dick Davies

2/1/2005 12:33:00 PM

0

* Francis Hwang <sera@fhwang.net> [0221 02:21]:

> What about compatibility with previous versions in the std lib? I wrote
> a Ruby-driven e-commerce site in 2002, using Ruby 1.6, and those
> versions of Marshal and Eruby. When the host upgraded to 1.8.2, the
> site fell down like a ton of bricks, because those libraries were
> massively backwards incompatible. Luckily, I was available to fix it
> posthaste, but if I had been, say, on vacation, or no longer working
> with that company, they would have been screwed.

But surely if they'd made that bump when you were away they'd only have
themselves to blame. This isn't really any different to a 1.1.8 -> Java2
upgrade in essence.

If the breakage wasn't documented in the release notes, that's another
matter, of course.


--
'Everyone's always in favour of saving Hitler's brain, but when you put it
in the body of a Great White shark suddenly you've gone too far..'
-- Prof. Farnsworth
Rasputin :: Jack of All Trades - Master of Nuns

Douglas Livingstone

2/1/2005 3:05:00 PM

0

> Though now, for some reason, I forget: When was the last stable version
> before 1.8.2? Was this 1.8.0? I can't find this online.

You might fing this interesting:
http://redhanded.hobix.com/cult/sevenChrist...

Douglas