Is compatibility important for us?

[Esteban Manchado Velázquez]

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,

 

[Francis Hwang]

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?

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,

Francis Hwang
http://fhwang.net/

 

[James Britt]

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]

* James Britt <[email protected]> [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-ruby16_18/

 

[Francis Hwang]

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://fhwang.net/

 

[Eric Hodel]

--Apple-Mail-29-71572662
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

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


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 - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-29-71572662
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB/vSQMypVHHlsnwQRAlxlAKCU3C77FYSB8PVm/pJxYeEU3gUbPQCfYd/R
+FFyEYYnSR06BVnt0zMPG9U=
=o48T
-----END PGP SIGNATURE-----

--Apple-Mail-29-71572662--

 

[Francis Hwang]

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://fhwang.net/

 

[Trans]

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]

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/

 

[Dick Davies]

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.

 

[Douglas Livingstone]

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/sevenChristmases.html

Douglas

 

[James G. Britt]

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.

The issues I see are:
* Code that works for version x breaks *without prior warning* when
you upgrade to version x+1. This case is hard to defend, and may have
been the case for Marshal.

* Code that works for version x breaks *as documented* when you
upgrade to version x+1. This case is unpleasant but hardly unique to
Ruby.

* New code requires you to have the latest stable release, and all you
have is latest - n (because you are not root or The Boss or what have
you). Sad, but unless you are paying someone you shouldn't expect
developers to be too concerned with writing new code that runs on
older versions of Ruby. (And I expect this is true in most developer
communities, so nothing scary about Ruby in this regard.)

* A patch is released for some current lib, and it breaks things
*without prior warning*. Even harder to defend than the first case.

* A patch is released for some current lib, and it breaks things *as
documented*. Sometimes required, but there should be a good reason.

The OP was, I believe, concerned with the second case, that too many
applications and libraries require version 1.8.x, and there are
presumably some number of people still living in 1.6 land. I really
don't see this as all that different from other language environments.
Java(tm) 5 comes out, people start taking advantage of the nice new
features, and people stuck on 1.3 or 1.4 are left out in the cold. It
happens, and truthfully those people are no worse off than if those
new apps were never written. (It's probably worse in Javaland; I
recently did work on a j2ee app, and the code had to run on Java 1.3
because the app server still didn't handle 1.4. And this was a
fairly recent version of the app server.)

In Francis' case, I'd change hosting providers if they are updating
software without sufficient warning for customers to check and update
their code. (Ideally, I'd be running my business off a box where I
was root and controlled the environment.)

That's not to excuse any cases where code simply breaks without any
documented warning, but overall I don't see anything happening in the
Ruby development path that is all that different from other languages.
(Look, if you dare, at PHP 5. Older code might break, or, worse,
keep running but with unexpected behavior.)


James

 

[Esteban Manchado Velázquez]

I had this on "postponed", and I just realized. Sorry.

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
[...]

That's it. And even if you do, when you have a big pool of applications
running in production servers, it must be _very_ annoying having to figure out
what changes you need, one by one.

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.

Amen! That's more or less my case right now: I would *love* to use Ruby in
my day job, but I just can't push too much a language that is going to have
"compatibility problems" of this sort. We make lots of small applications, and
upgrading Ruby on a production server would be like hell (and perhaps we would
need it from time to time, e.g. when upgrading from Woody to Sarge), fixing
every Ruby application.

And, w.r.t. the reply from James Britt, he said:

Sad, but unless you are paying someone you shouldn't expect
developers to be too concerned with writing new code that runs on
older versions of Ruby. (And I expect this is true in most developer
communities, so nothing scary about Ruby in this regard.)

Yes, you're right, you can't "expect" developers to do that, but I think
Ruby would gain acceptance if more developers tried to remain compatible.

And I think other languages (read: Perl and probably Python) care _a lot
more_ in that regard. Please don't get me started on PHP, for several reasons
;-)

Oh, BTW, I was concerned with cases two and three (breakage when upgrading
and new code that requires "latest" release).

 

[James Britt]

And, w.r.t. the reply from James Britt, he said:




Yes, you're right, you can't "expect" developers to do that, but I think
Ruby would gain acceptance if more developers tried to remain compatible.

That's, um, crazy. Writing new code and checking that it runs in both
1.6 and 1.8? Then you're basically writing to 1.6. Or else development
takes far more time than it is worth, as you have to make sure that
compatible libraries are available for any 1.8 feature you're using.

I don't quite see how new applications that don't take advantage of new
and improved features in a language are really going to win over more
people.

Does anyone expect that new PHP applications will not take advantage of
PHP5? Or when Perl 6 comes out new Perl apps won't leverage things
unique to Perl 6, and require Perl 6?

Overall, Ruby will attract more users as the number of new kickass
applications grows, and that number will grow faster if people aren't
ensuring that their code runs on ruby.previous_version

(BTW, did you intend to say "Ruby would gain *more* acceptance if more
developers tried to remain compatible"? Because Ruby is clearly gaining
not just acceptance, but active usage, despite any compatibility issues.)

And I think other languages (read: Perl and probably Python) care _a lot
more_ in that regard. Please don't get me started on PHP, for several reasons
;-)

I'm curious how one might quantify this. Maybe look for some sampling of
new applications written after the latest version of P* came out, and
see if they run on an earlier major version?

I'm pretty sure the last time I installed Blender or Zope or something
Python-based they were quite specific about having a current Python.
But I haven't made a habit of installing Python apps so my sample space
is small.

I guess the other test is to find early P* apps and see if they still
run on current versions of their respective interpreters. (Not sure if
I have any perl 4 code anyplace though. Might be on some Winchester
drive in the closet, next to the eight-track tapes and Pong.)


James

 

[Douglas Livingstone]

Please don't get me started on PHP, for several reasons
Anything with OO won't work

 

[Thomas Fini Hansen]

* James Britt <[email protected]> [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

It might not be that simple. I would love to get 1.8 on our production
server (opens the door to rails), but whenever I've tried the
backports, the combination of new Ruby, mod_ruby and old (ie, stable)
Apache has failed horribly (the Apache process just hangs on files
that use Ruby). I've even tried compiling from the Debian source
package, without luck (I doubt that I would have more luck with the
original source).

On a test server it works marvellously using Apache 2 (though, I had to
compile Ruby and mod_ruby from the Debian sources for some reason),
but then PHP is a problem, which is a nogo as we got rather a lot of
PHP running on the production server.

(Aside: now there's a sad tale, PHP holding back Ruby. Apparently PHP,
in contrast to mod_ruby, mod_perl and mod_python, has serious problems
with threading in the new Apache.. But I digress.)

All these interdependencies means that we're still stuck on 1.6 on the
production server.

Of course I understand why people code for 1.8, I'd do the same if
offered the chance. But do bear in mind that we can't all upgrade to
the latest and greatest all the time, so if backwards compatibility
can be attained with a bit of effort, it would be much appreciated.

 

[Esteban Manchado Velázquez]

That's, um, crazy. Writing new code and checking that it runs in both
1.6 and 1.8? Then you're basically writing to 1.6.

Yes, that is what I mean. Are there really so much performance-boosting
features in Ruby 1.8 (the language; I guess the libraries should be easy to
upgrade.... if they work in Ruby 1.6) that going to 1.6 for _some_ important
libraries sound crazy? It not telling everyone to not use new lenguage
features (sorry if it sounded like that), I'm simply saying that keeping some
important libraries/applications compatible with Ruby 1.6 would probably make
Ruby stronger in the eyes of many bussinesses.

I don't quite see how new applications that don't take advantage of new
and improved features in a language are really going to win over more
people.

Letting more people use them, reducing maintenance costs, and thus making
more people see Ruby as a viable alternative.

Does anyone expect that new PHP applications will not take advantage of
PHP5? Or when Perl 6 comes out new Perl apps won't leverage things
unique to Perl 6, and require Perl 6?

PHP usually has _many_ (incompatible) changes when they bump the major
version, so I don't think we can compare here. Ditto with Perl 6. I guess that
your comparisons are fine for the Ruby 1.x -> Ruby 2.x transition, but not for
1.6 -> 1.8. I think that we should compare the 1.6 -> 1.8 transition with
Perl's 5.6 -> 5.8 or with Python's 2.2 -> 2.3. But it really is a matter of
opinion.

Overall, Ruby will attract more users as the number of new kickass
applications grows, and that number will grow faster if people aren't
ensuring that their code runs on ruby.previous_version

I wouldn't be so sure. I mean, of course kickass applications make us
having a lot more attention/acceptance, but when trying to push a new,
"obscure" (in the sense of not having gallizion developers out there) language
in your workplace, it's a big plus if you don't have many additional
maintenance costs.

I mean, the compatibility thing is _not_ a problem if you actively want to
use Ruby, or if you are a Ruby shop anyway, because you've already seen the
light ;-) But if you are in a situation where you need to maintain your own
compiled version of the interpreter separately from the rest of the system,
just to "test" a new language, and (you/your boss) are not even sure if you're
finally going to develop in Ruby, I guess many bussinesses will simply not use
it.

And I'm not saying that if they finally checked out Ruby, the maintenance
thing would surpass the performance/satisfaction/whatever boost... just saying
that easing more people "checking out" Ruby in their workplace would be good.
I guess you think that we're better off taking advantage of new features than
trying to maintain compatibility, but...

(BTW, did you intend to say "Ruby would gain *more* acceptance if more
developers tried to remain compatible"? Because Ruby is clearly gaining
not just acceptance, but active usage, despite any compatibility issues.)

Yes, sorry. Obviously Ruby is gaining a lot of attention, in part thanks to
the great web frameworks written in Ruby.

I'm curious how one might quantify this. Maybe look for some sampling of
new applications written after the latest version of P* came out, and
see if they run on an earlier major version?

I'm pretty sure the last time I installed Blender or Zope or something
Python-based they were quite specific about having a current Python.

Perhaps yes. Perhaps I should not have included Python in the list.

But, the only application/library that I recall it had problems with Perl
5.6 is Request Tracker, and then again, it worked, but had some problems with
character set conversion (well, until some version, when they finally dropped
Perl 5.6 support altogether, IIRC). Every Perl application and especially,
library, that I recall installing in the past few years, worked just fine in
Perl 5.6.

So, perhaps the only language/community that maintains that sort of
compatibility is Perl, but is what I use (partly), and I'm used to that, and I
find that a good thing

Regards,

 

[Austin Ziegler]

Yes, that is what I mean. Are there really so much performance-
boosting features in Ruby 1.8 (the language; I guess the libraries
should be easy to upgrade.... if they work in Ruby 1.6) that going
to 1.6 for _some_ important libraries sound crazy? It not telling
everyone to not use new lenguage features (sorry if it sounded
like that), I'm simply saying that keeping some important
libraries/applications compatible with Ruby 1.6 would probably
make Ruby stronger in the eyes of many bussinesses.

Yes. One of the main features in Ruby 1.8 over 1.6 was the
following:

h = Hash.new { |h, k| h[k] = [] }
h[ne] << two

Before this feature, a lot of code would have had to look like:

((h ||= {})[ne] ||= []) << :two

Possibly on split lines, but the behaviour is far more easy to
manage now.

Also, the library differences are important because they *do* behave
differently and there are *more* of them. In many ways, I think that
the Ruby 1.6 -> 1.8 upgrade is closer to Perl 4 -> 5 (or perhaps the
numbering from Perl 5.005 -> Perl 5.6) than a smaller upgrade. Matz
has ambitious goals for Ruby 2.0 which limit the version numbering.

-austin

 

[Ian Hobson]

Yes, that is what I mean. Are there really so much performance-boosting
features in Ruby 1.8 (the language; I guess the libraries should be easy to
upgrade.... if they work in Ruby 1.6) that going to 1.6 for _some_
important libraries sound crazy? It not telling everyone to not use new
lenguage features (sorry if it sounded like that), I'm simply saying that
keeping some important libraries/applications compatible with Ruby 1.6
would probably make Ruby stronger in the eyes of many bussinesses.

It may be what you meant, but I don't think this is the important point.

New code should NOT break old applications. Period.

I would like to leave that period there, but I accept that incompatible
changes are necessary some times. They should be few and far between, well
documented.

Curt's recent OnLamp article on rails was seriously weakened when, 5 days
after it published, RAILS 0.9.5 was released and the examples refused to run.

How many people, like me, have or will play with rails, only to find it did
not work. Yet they were reading VERY recent stuff? How many will conclude
that Rails was not yet ready for serious consideration?

(I am aware that rails is pre 1.0 - but it was broken by a mixture of changes,
mostly in post 1.0 releases).

If new code breaks old apps, people with production code, will not (can not,
dare not) trust Ruby - they do not have the time to redevelop their app (in a
hurry) every time someone uses gems and updates a library.

The issue is not that I should write my code to work on 1.6 and 1.8.0 and
1.8.1 and 1.8.2. The issue is that my legacy app written in 1.6 should still
run properly when I update to later versions.

Regards

Ian

 

[Ian Hobson]

The issue is not that I should write my code to work on 1.6 and 1.8.0 and
1.8.1 and 1.8.2.  The issue is that my legacy app written in 1.6 should
still run properly  when I update to later versions.

^^^^^^^^^^^^^^^^^^^^^^

whoops - I meant to write "when you or any other user, upgrade to later
versions".

Ian