Re: If you are unhappy with the direction of Ruby 1.8.7+, respond

Hi Matz, I'm glad to see that you've entered this fray.

I trust that you know me well enough to know, that while I have strong
opinions, I have no ill-will, particularly to you or your language.

On Fri, Feb 13, 2009 at 3:10 AM, Yukihiro Matsumoto <[e-mail]>wrote:

> Hi,
>
>
>  * Rails had problem from method name conflict.  This was
>    unfortunate, caused by Rails' fragile monkey patching and our bad
>    for lack of thorough Rails test before 1.8.7.  It is fixed now.
>
>  * erb also had a bug in 1.8.7 initial release.  It is fixed now.
>
>  * two other problems are reported (SWIG and hash order), and as far
>    as I understand, they both contain bugs that haven't disclosed for
>    1.8.6 by accident.
>
> I consider them minor and not being worse than previous releases.
> Most of them are addressed already.  Am I missing something?


First, the next  comment is directed to a subset of the Ruby community,
which doesn't  include you Matz,

I know that Rails isn't liked by everyone in the Ruby community, but for
better or worse, it's an important factor to the health of a significant
portion of 'our' community.  Those who don't use Rails or other large Ruby
frameworks over time haven't experienced how we got to the point where these
problems have been addressed.

At this point, it's a little hard to recover the history, but, although
Rails 2.2 is now compatible with Ruby 1.8.7 it has taken work, and new
releases, from both the Ruby team and the Rails team.

Rails users faced with upgrades, need to deal with the evolution of both
Ruby and Rails.  To a large extent Rails over the last year to 18 months has
been even more volatile than Ruby. Porting a Rails app from Rails 1.2.x to
Rails 2.0 (There was no Rails 1.3) was, as the change in major version
number indicates a fairly significant jump.  And Rails made changes in Rails
2.2 which, for applications doing certain complex things with ActiveRecord,
VERY difficult to port.  That's not Ruby's fault, it's just a fact of life.

So there are quite a few Rails Apps, which need to stay on a version of
Rails which is compatible with Ruby 1.8.6, but won't work with Ruby 1.8.7.

|Back then nobody stepped up and said that if code working on 1.8.6
> |broke it is a bug so I just left it at that - the compatibility seemed
> |to be not so great.
>

Of course, none of us is perfect, particularly without the benefit of
hindsight.

As a practitioner and advocate of agile techniques, I like to have a
comprehensive test suite to expose compatibility issues when changes are
made.

Unfortunately in the case of a language like Ruby, it's impossible to have
such a test suite, It would need to draw from a significant portion of the
applications implemented in Ruby, and applications implemented on frameworks
like Rails which are implemented on Ruby, etc. etc.  Not really practical.

If compatibility of 1.8.7 is really "not so great":
>
>  * if it is fixable, we can fix.
>
>  * if it is minor, we can upgrade 1.8.7 (or later) whenever we want,
>    as we did in the past.
>
>  * if upgrading is not affordable for enterprisey people (yes, I
>    understand them; upgrading is costly even when incompatibility is
>    minor),



I'm not sure who you are calling enterprisey people here.  I know that you
have no intent to disparage, but that term does carry a certain meaning of
"the other guys" with some of the Rubyists, (and others) I run into.

To me "enterprisey" means  someone working in a large corporate enterprise,
who is following strategies, architectures and standards, promulgated by
enterprise vendors, like Microsoft, and IBM (to the extent IBM still has the
influence to do this), probably because of edicts handed down from on high
from the executives who play golf with sales reps from those vendors.

I'm pretty sure that such "enterprisey" types make up a very small subset of
the Ruby/Rails community.  We don't have many sales reps who play golf with
corporate executives.

The vast majority of those using Rails are fairly small companies trying to
leverage the almost unique advantages of Ruby and Rails to be able to
quickly deploy into production, and incrementally improve core business
applications.  And the vast majority of Rails developers are either working
for those small companies, or for a small Rails consultancy, or as
independent freelance contractors.


> they can keep using 1.8.6, which is maintained right now.
>
>
Very true, I've got no argument with that, but it's important to understand
that those who are using packaged distributions of Ruby from debian
(including Ubuntu), RedHat, macports etc. have more trouble keeping 1.8.6
because normal system administration has a nasty tendency to replace 1.8.6
with 1.8.x where x > 6 because they don't differentiate versions with
differences in teeny version numbers as backwards incompatible.  While 1.8.7
is backwards compatible with 1.8.6 in theory. Whether or not it really is,
depends on whether or not all of the ancillary ruby code on the particular
system, like Rails, Gems, and local applications have been kept, or brought
up to date.

Savvy developers get around this by eschewing packaged versions and
installing the components of the Rails stack, including Ruby, from source.
But there are a lot of developers who trust the package maintainers, and run
into these issues, and end up blaming Ruby.  We could say "well that's their
problem," if we don't care about the impact on the overall perception of
Ruby.  Perhaps that's the right attitude, but I'm not so sure.

Would it have been better for those with these problems had Ruby 1.8.7 not
included the changes from 1.9 which broke apps and frameworks?  I think that
the answer is clearly yes.

But, for better or worse, it did, and we have to live with the consequences,
that doesn't mean we need to be happy about it.

   As EngineYard raised their hands, the maintenance of 1.8.6 will be
>    kept, even after 1.8.8.

If more evidence of great incompatibility is not shown, I will
> consider it FUD, or FUD-like at most, even though I see no bad
> intention from anyone.
>

I hope that this doesn't come across as FUD, or even FUD-like, I'm just
trying to put a bit more context on why compatibility isn't a black or white
thing, and the sources of real FUD.

The real FUD doesn't come from discussions like this, it comes from those
who either have run into these problems and blame Ruby.  We have no control
over what they say, we can only try to consider the effects of decisions on
the broader community, within the bounds of our human lack of complete
knowledge.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale