Is compatibility important for us?

[James Britt]

...
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).

While Rails is quite good, and deserving of attention, it may be a
mistake to try to hype it to the masses, precisely because it has not
reached version 1.0. No matter how large the blinking sign shouts,
"Beta! Beta! Things may change and break!", some people will use it and
then complain that things changed and things broke. Go figure.

On the other hand, apparently large, busy sites are being built in Rails
right now. And DHH has been very good at alerting people to breakage
and what to do to alleviate it. So the issues may not be so bad for so
many people.

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.

I think most people agree with that as a general goal, with the
understanding that there arise occasions where some breakage is
required. These cases should be well-documented and treated quite
seriously.

But the OP also appeared distressed that many new applications (e.g.,
Rails) required 1.8, and that new apps not running with old versions of
Ruby was perhaps a significant problem; opinions vary.

James

 

[David Heinemeier Hansson]

On the other hand, apparently large, busy sites are being built in

Rails right now. And DHH has been very good at alerting people to
breakage and what to do to alleviate it. So the issues may not be so
bad for so many people.

Rails had a huge change going from 0.8.x to 0.9.x. It required a whole
manual to do that upgrade. It also improved the framework dramatically
(Thomas Luekte cut 1,500 lines of code from his Snowdevil e-commerce
application taking it from 7.5 to 6 KLOC).

Since the release of 0.9.0, though, updates to Rails have caused less
than 10 lines of code change to existing applications. And they've been
spelled out in the release notes.

Luckily, it's incredibly easy not even to bother with those changes if
you have a finished application. Just lock it to a particular set of
gems or to a particular SVN revision if you're using svn:externals.

Rails have not yet entered maintenance state. So currently, having a
cleaner API for the future is more important than avoiding any kind of
backwards compatibility breakage. If you'd rather work with a framework
that reverses that value statement, I believe there are plenty to
choose from.

It is my ever humble opinion that choosing Rails is well-worth
migrating 10 lines of code to move through the 0.9.x releases. So I
found statements like "Rails shouldn't be promoted before 1.0" half-way
funny and half-way insulting. I'd argue that if nothing else, the time
freed up from not having to do many of the tasks Rails intends to
relieve you off should provide plenty of buffer to 1) stay informed of
documented breakage between releases and 2) apply the outlined fixes.

But the OP also appeared distressed that many new applications (e.g.,
Rails) required 1.8, and that new apps not running with old versions
of Ruby was perhaps a significant problem; opinions vary.

I can only speak for myself personally, but I'm not interested in
working with a 2 year-old version of Ruby in order to make it easier
for some potential users to stay put because they can't upgrade for
various reasons. Languages, frameworks, and applications are constantly
faced with decisions that might decrease their market potential. As
long as they're chosen consciously, it's part of the bargain.

Hence, I choose consciously to officially support only the latest
stable release of Ruby for Rails. Given that releases are a year in
between, this is a reasonable trade-off for me to make. This doesn't
mean that Rails won't necessarily work with 1.8.1. Just that I'm not
taking any special efforts to make it so. And that if your bug isn't
possible to replicate on the latest Ruby version, then I'd happily
accept a non-intrusive patch, but that's the extend of the service.

And I must admit that by the rate of growth experienced in the Rails
community, I'm not currently looking for leverages to increase that
growth by accepting more responsibilities, such as stricter
non-breakage obedience.
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

 

[James Britt]

David Heinemeier Hansson wrote:
...

It is my ever humble opinion that choosing Rails is well-worth migrating
10 lines of code to move through the 0.9.x releases. So I found
statements like "Rails shouldn't be promoted before 1.0" half-way funny
and half-way insulting. I'd argue that if nothing else, the time freed
up from not having to do many of the tasks Rails intends to relieve you
off should provide plenty of buffer to 1) stay informed of documented
breakage between releases and 2) apply the outlined fixes.

I don't think anyone has said that Rails shouldn't be promoted before
1.0. But there is a (perhaps small) audience for whom any code change
mandated by a version upgrade will be viewed as a significant flaw.
Even when there is clear documentation explaining this.

I'm just inclined to say, "Oh well," because no matter how hard one
tries to alert people to the risks of pre-1.0 software, somebody
someplace will just not listen.

Still, reading through the OnLAMP Rails article, I don't see anything
that warning people that Rails is pre-1.0 and that there is a risk of
compatibility issues moving towards 1.0. So maybe people learning about
Rails from that article have a right to complain.

I can only speak for myself personally, but I'm not interested in
working with a 2 year-old version of Ruby in order to make it easier for
some potential users to stay put because they can't upgrade for various
reasons. Languages, frameworks, and applications are constantly faced
with decisions that might decrease their market potential. As long as
they're chosen consciously, it's part of the bargain.
...


And I must admit that by the rate of growth experienced in the Rails
community, I'm not currently looking for leverages to increase that
growth by accepting more responsibilities, such as stricter non-breakage
obedience.

This is the trade-off path that probably most developers pick. If it is
going to take me X hours or days or weeks longer to release something,
there better be some reasonable payoff, and I just don't see the gain in
users stuck on old version of Ruby to be worth it.

Anyone who thinks otherwise can take any existing GPL'ed Ruby app and
back-port it.

James

 

[Francis Hwang]

I can imagine being on the fence about Rails, and Ruby in general, and
coming to the OnLAMP article, trying the examples, seeing that they
break because the API has changed, and being turned off by this. So
maybe that's something that needs to be addressed, not necessarily by
changing the way libraries are coded, but at least in communications.

I think David makes a pretty decent argument when he says

This is a decent tradeoff, I think, even for Ruby itself. So maybe
that's one of the talking points to use here: "Yeah, Ruby's moving
quickly and APIs are a little less stable than in, say, Java. But
you're going to save so much time in your day-to-day programming that
keeping up with API changes won't be that hard." That's certainly been
the case for my Ruby usage.

Which makes me think that most of Ruby's growth is going to come from
people leaving Java and PHP, not from (cough) people leaving Python. I
suppose the success of Rails has already proven that, though.

Francis Hwang
http://fhwang.net/

 

[David Heinemeier Hansson]

Which makes me think that most of Ruby's growth is going to come from

people leaving Java and PHP, not from (cough) people leaving Python. I
suppose the success of Rails has already proven that, though.

I'm definitely seeing a ton more people come over from PHP and Java
than from Python or Perl. This is natural, of course, considering that
a lot more web development is happening in PHP and Java, but I also
think it's because the perceived difference is big enough.

Pythonists and Perlers probably doesn't feel that Ruby (on or off
Rails) is sufficiently different from what they're currently doing to
warrant stepping down the expert ladder.
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

 

[Adrian Howard]

On 7 Feb 2005, at 00:43, David Heinemeier Hansson wrote:
[snip]

Pythonists and Perlers probably doesn't feel that Ruby (on or off
Rails) is sufficiently different from what they're currently doing to
warrant stepping down the expert ladder.

[snip]

That's odd. I've know a lot of people who're spending time playing with
Ruby from the Perl world.

In general I've found that Perl folk usually like Ruby since it's much
closer to Perl's TMTOWTDI attitude (which may be why some Python folk
dislike it?) and fills all the nasty OO holes while we wait for Perl 6
to arrive

Cheers,

Adrian

 

[Booker C. Bense]

-----BEGIN PGP SIGNED MESSAGE-----

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

_ Perl was not always this way. There was a big change from
version 4 to 5 and even the very minor change from 5.6 to
5.8 things broke... I think it's a bit unfair to compare
an essentially fixed language like perl5 that has minor bugfix
releases to ruby. When Ruby gets to version 5, I imagine things
will be much more stable.

_ There is no free lunch... I understand your point, but I don't
see any real answer. Until people can make a living at writing
Ruby libraries, they have no incentive for backwards
compatiblity. There's a definite chicken and egg problem here,
but at least it's not the bad old days when you had to recompile
perl or tcl from scratch to use a new library.

_ To me it seems like there has been a very large leap in
functionality from 1.6 to 1.8 and that a sort of bootstrap
level has been reached. It really should have been a 2.0
release, but since Ruby 2.0 has very special meaning that's
not in the cards. I would hope that things stablize
in the future, but it's still early days and Ruby is certainly
no worse in this regard than any other language I've seen
develop.

_ Booker C. Bense


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBQhOX/GTWTAjn5N/lAQGlLwP+O+CVupU3CszaSI55AZTmNGL42TsJUJF8
pcocjE80aU92hMI1foognmEN6Hx7Ghf6nvlDUnC4GLft6G85T89w2Se9LressOWa
sBwkxHPgMTTdw6oGiYIQ6hyZ6tq25YTQEsdkTJmSpHnEJPcDwxjZTvgTNWXz1v2b
jdv5dqlRGbk=
=UK2g
-----END PGP SIGNATURE-----