The future of Ruby

ruby-talk
1

Hello

I'm studing Ruby and in a short Ruby in Rails for the web development.
I've observed that each verion of Ruby can introduce modifications in
the sintax and behaviour of Ruby. In the other hand I suppose the
comunity develop libraries in the stable release of the moment. The
question is:

What about backward compatibilty? If I write a Ruby program using 1.8.5,
in the future I'll be able to run in using the Ruby 2.0? What about the
libraries developed under 1.8 Ruby?

If I have to develop a professional Ruby program for a company, and one
day I have to update the Ruby's engine, or the ruby's version just
because of a security hole, it would be a bad surprise that nothing
works...

Someone can clarify all this questions please? I would like to program
in Ruby, but not at any price...

Thank you very much!

Joan

···

--
Posted via http://www.ruby-forum.com/.

2

Joan Iglesias wrote:

Hello

I'm studing Ruby and in a short Ruby in Rails for the web development.
I've observed that each verion of Ruby can introduce modifications in
the sintax and behaviour of Ruby. In the other hand I suppose the
comunity develop libraries in the stable release of the moment. The
question is:

What about backward compatibilty? If I write a Ruby program using 1.8.5,
in the future I'll be able to run in using the Ruby 2.0? What about the
libraries developed under 1.8 Ruby?

Language developers have every incentive to maintain backward compatibility.
It is rare to see a new language version that breaks old applications. This
isn't a guarantee, it's a statement of a common-sense principle.

Sometimes a language change takes place to avoid what would otherwise have
been a security hole or a syntactical inconsistency, but these sorts of
changes tend to be rare, small and easily repaired in source.

It would be fatal for a language maintainer to create a new language version
that invalidates a lot of old programs.

···

--
Paul Lutus
http://www.arachnoid.com

3

Hello

I'm studing Ruby and in a short Ruby in Rails for the web development.
I've observed that each verion of Ruby can introduce modifications in
the sintax and behaviour of Ruby. In the other hand I suppose the
comunity develop libraries in the stable release of the moment. The
question is:

What about backward compatibilty? If I write a Ruby program using 1.8.5,
in the future I'll be able to run in using the Ruby 2.0? What about the
libraries developed under 1.8 Ruby?

If I have to develop a professional Ruby program for a company, and one
day I have to update the Ruby's engine, or the ruby's version just
because of a security hole, it would be a bad surprise that nothing
works...

Someone can clarify all this questions please? I would like to program
in Ruby, but not at any price...

Thank you very much!

Joan

--
Posted via http://www.ruby-forum.com/\.

"Ruby2 will be slightly incompatible, the changes will not only
consist of additions but also of syntax improvements (hopefully a
better syntax will result)."

That's from http://wiki.rubygarden.org/Ruby/page/show/Rite\. A new
major version, I think, should be allowed to have some backwards
incompatibilities, so it doesn't have to be suffer from old heritage
(think C++), but minor versions should minimize them.

Paul Lutus wrote:

It would be fatal for a language maintainer to create a new language version
that invalidates a lot of old programs.

Indeed. Ideally features that are to be removed should be deprecated
some time before being removed, so people know that they should
avoid/fix code that uses it.

···

On 9/16/06, Joan Iglesias <joan.iglesias@yahoo.es> wrote:

--
- Simen

4

Joan Iglesias wrote:

Hello

I'm studing Ruby and in a short Ruby in Rails for the web development. I've observed that each verion of Ruby can introduce modifications in the sintax and behaviour of Ruby. In the other hand I suppose the comunity develop libraries in the stable release of the moment. The question is:

What about backward compatibilty? If I write a Ruby program using 1.8.5, in the future I'll be able to run in using the Ruby 2.0? What about the libraries developed under 1.8 Ruby?

If I have to develop a professional Ruby program for a company, and one day I have to update the Ruby's engine, or the ruby's version just because of a security hole, it would be a bad surprise that nothing works...

Someone can clarify all this questions please? I would like to program in Ruby, but not at any price...

Thank you very much!

Generally, only major version increments introduce backwards incompatibilities. By major version I mean the x in x.y.z. Ruby 1.8 will probably be around even after 2.0 is released, and security and bug updates will surely continue for a while.

Cheers,
Daniel Schierbeck

5

In practise you will really quickly adapt to make modifications also
quickly to make a script run again. Comes automagically the more
time you spend with ruby :wink:

···

--
Posted via http://www.ruby-forum.com/.

6

This will be mostly true for Ruby. Matz has defined Ruby 2.0 as new
syntax changes plus a new virtual machine (Rite).

Therefore, when he releases 1.9.1 as a public release version around
Christmas 2007, that will become the new production version with all
of the syntax changes planned for Ruby 2.0, but it will not include by
default the new virtual machine.

So, there will be some incompatibilities with Ruby 1.9 and Ruby 1.8,
but they should not affect most programs at all.

-austin

···

On 9/16/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:

Generally, only major version increments introduce backwards
incompatibilities. By major version I mean the x in x.y.z. Ruby 1.8 will
probably be around even after 2.0 is released, and security and bug
updates will surely continue for a while.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

7

Marc Heiler wrote:

In practise you will really quickly adapt to make modifications also
quickly to make a script run again. Comes automagically the more
time you spend with ruby :wink:

In my case, it's not just a matter of adapt a script. Maybe it can be
not a small program. And if I have to sell my program or in my case my
web program in Ruby and I cannot garantee a long life to the program
with the minimum modifications, I'll not sell it.

I think, Ruby is now suffering to many changes, because it's very young
and because there isn't a big company behind (like in Java), that forces
backward compatibility ALWAYS.

It could be a good idea to mantein backward compatibility in the same
way that perl will matein it between Perl 5 and Perl 6.

http://dev.perl.org/perl6/faq.html

At least to have an option in the compiler or interpreter to specicy the
compatibility requered. Or imagine I have a lot of ruby 1.8 libraies, I
can lose time modifying all the libraries because a change in the
language.

In my case, and mainly because of backward compatibility I choose Perl.
I'm sure that in a near future Ruby will be the choise, but now is Perl
for a lot of reasons:

1- backward compatibility.
2- A big comunity.
3- a very huge amount of modules.
4- fast programming, but in this case you have to take more care of good
programmation.

Thank you

Joan

···

--
Posted via http://www.ruby-forum.com/\.

8

Interesting. I didn't know that.

Did you read this somewhere? Could you share the link?

I *assumed* 1.9.1 would be the first version to ship with YARV.

James Edward Gray II

···

On Sep 17, 2006, at 7:41 AM, Austin Ziegler wrote:

Therefore, when he releases 1.9.1 as a public release version around
Christmas 2007, that will become the new production version with all
of the syntax changes planned for Ruby 2.0, but it will not include by
default the new virtual machine.

9

I think, Ruby is now suffering to many changes, because it's very young
and because there isn't a big company behind (like in Java), that forces
backward compatibility ALWAYS.

I am not sure why do you talk about "suffering" and that particular
changes do you
have in mind? Were you affected by them?

As for language being young: both Java and Ruby were publicly released in 1995.

It could be a good idea to mantein backward compatibility in the same
way that perl will matein it between Perl 5 and Perl 6.

<...>

New major version also is a good chance to shake off some bad legacy, that may
hurt some, but all are better off later.

Regards,
Rimantas

···

--
http://rimantas.com/

10

Java has a long and annoying history of breaking older versions. That's one
of the reasons why companies that ship Java-based products generally require
a specific Java version. And Sun, in their infinite wisdom, made it a
violation of their license to ship a runtime package that you know will work
with your code, so this solution is only available to companies that are
able and willing to pay Sun to make an exception for them.

Microsoft and Intel are the companies that have always been really
aggressive about preserving back-compatibility. And developers have rewarded
them richly for it.

···

On 9/17/06, Joan Iglesias <joan.iglesias@yahoo.es> wrote:

and because there isn't a big company behind (like in Java), that forces
backward compatibility ALWAYS.

11

I was wrong: http://redhanded.hobix.com/cult/rubyKaigi2006.html

-austin

···

On 9/17/06, James Edward Gray II <james@grayproductions.net> wrote:

On Sep 17, 2006, at 7:41 AM, Austin Ziegler wrote:
> Therefore, when he releases 1.9.1 as a public release version around
> Christmas 2007, that will become the new production version with all
> of the syntax changes planned for Ruby 2.0, but it will not include by
> default the new virtual machine.
Interesting. I didn't know that.

Did you read this somewhere? Could you share the link?

I *assumed* 1.9.1 would be the first version to ship with YARV.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

12

Joan Iglesias wrote:

I think, Ruby is now suffering to many changes, because it's very young
and because there isn't a big company behind (like in Java), that forces
backward compatibility ALWAYS.

I have also had incompatibility problems with Java. But unlike Ruby,
the fixes were not easy. We tried to upgrade from 1.4 to 1.5. It broke
at least one of our web apps and I never DID figure out how to fix them.
We ended up staying at 1.4 and just leaving it alone.

I'm not saying that future-proofing a language isn't desirable, but it's
far from guaranteed on any language. I think Ruby has done quite well,
especially since they always state exactly what changed so you don't
have to guess.

···

--
Posted via http://www.ruby-forum.com/\.

13

Quoting Joan Iglesias <joan.iglesias@yahoo.es>:

In my case, it's not just a matter of adapt a script. Maybe it can be
not a small program. And if I have to sell my program or in my case my
web program in Ruby and I cannot garantee a long life to the program
with the minimum modifications, I'll not sell it.

I think, Ruby is now suffering to many changes, because it's very young
and because there isn't a big company behind (like in Java), that forces
backward compatibility ALWAYS.

It could be a good idea to mantein backward compatibility in the same
way that perl will matein it between Perl 5 and Perl 6.

GitHub - Raku/old-design-docs: Raku language design documents

At least to have an option in the compiler or interpreter to specicy the
compatibility requered. Or imagine I have a lot of ruby 1.8 libraies, I
can lose time modifying all the libraries because a change in the
language.

In my case, and mainly because of backward compatibility I choose Perl.
I'm sure that in a near future Ruby will be the choise, but now is Perl
for a lot of reasons:

1- backward compatibility.
2- A big comunity.
3- a very huge amount of modules.
4- fast programming, but in this case you have to take more care of good
programmation.

Thank you

Joan

I'm not at all sure about Perl 5 -> Perl 6, but I had a Perl language change
break a number of my scripts when Perl's Unicode support became "operational".
Specifically, I was using byte constants in compares, and the Perl default
switched from byte semantics to character semantics. So Perl isn't actually
angelic in this arena either.

I don't know if the Perl community sent out warnings about this or not; I've
never been a member of the Perl community, and the Perl version changed only
because the underlying Red Hat version changed. Still, the subset of Perl that
I use is pretty much Perl 4 and will pretty much run on a DOS Perl 4
interpreter. It's old code, and thankfully not a large code base, and
thankfully nearly 100 percent my own, and thankfully not mission-critical.

Lessons learned: join the community, track versions of the software you use,
have frequent code reviews, etc. I don't think your arguments rule out Ruby and
rule in Perl. A more practical assessment based on the number of available Perl
programmers and your own or your colleagues' greater familiarity with Perl is
probably a more compelling argument than the "backward compatibility" argument,
since all software is subject to backward compatibility issues. In any event,
good luck with your project.

14

Rimantas Liubertas wrote:

I think, Ruby is now suffering to many changes, because it's very young
and because there isn't a big company behind (like in Java), that forces
backward compatibility ALWAYS.

I am not sure why do you talk about "suffering" and that particular
changes do you
have in mind? Were you affected by them?

if you have a look to the language modification between 1.6 and 1.8,
there are some. And more modifcations between 1.8 and 2.0.

As you can read in the link above:

"Ruby2 will be slightly incompatible, the changes will not only consist
of additions but also of syntax improvements (hopefully a better syntax
will result)."

In a company that you have to make money by your time, this is not a
good philosophy. Of course I understand that the improvements in the
syntax and all this is good..., I cannot modify my programs so many
times with the risk of making mistakes because of the language...

As for language being young: both Java and Ruby were publicly released
in 1995.

I didn't know.

It could be a good idea to mantein backward compatibility in the same
way that perl will matein it between Perl 5 and Perl 6.

<...>

New major version also is a good chance to shake off some bad legacy,
that may
hurt some, but all are better off later.

Regards,
Rimantas

Regards

Joan

···

--
Posted via http://www.ruby-forum.com/\.

15

Can you please point me to real examples? Java is one of the few
languages I know that has guaranteed backward compatibility. So, I
would really like to hear real examples, otherwise this sounds like
missinforming. And please do not mix backward compatibility with bugs.

./alex

···

On 9/17/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:

On 9/17/06, Joan Iglesias <joan.iglesias@yahoo.es> wrote:
>
> and because there isn't a big company behind (like in Java), that forces
> backward compatibility ALWAYS.

Java has a long and annoying history of breaking older versions.

--
.w( the_mindstorm )p.

of the reasons why companies that ship Java-based products generally require
a specific Java version. And Sun, in their infinite wisdom, made it a
violation of their license to ship a runtime package that you know will work
with your code, so this solution is only available to companies that are
able and willing to pay Sun to make an exception for them.

Microsoft and Intel are the companies that have always been really
aggressive about preserving back-compatibility. And developers have rewarded
them richly for it.

16

You don't need examples from me. Just look to your own experience.
Have you ever tried running Oracle and a version of Tomcat that
requires a different JVM, on the same machine? (Yes, I know it's a bad
idea to run *anything* on the same machine with an Oracle instance,
but that's not my point.) Remember porting your AWT applications from
JDK 1.1 to 1.2?

It's true that Sun represents that they and their licensees will not
break older code so long as you stick to the "core" (java.*) packages.
(Their disclaimer is "unless they fix a serious bug.") In practice,
the experience has been painful. The OP said that he fears Ruby will
suffer back-compatibility problems in part because there is no large
company to provide the guarantee. My point was that the guarantee of a
large company may provide nothing but cold comfort as you modify your
code to deal with their "bug fixes,"
or worse, ship and maintain multiple versions of your code.

In my experience with Ruby, there haven't been all that many cases
where an emergency patch had to be made in order to fix a security
hole or other such urgent problem. I don't have any reason to suppose
that Matz, his team, or the community would make it difficult to patch
back versions of Ruby or its libraries in these cases. (The recent
security-emergency with Rails was very different, and quite badly
handled, but the Rails team is not the same as the Ruby team.)

Having said all this, I would stress that strict back-compatibility,
even with bugs, is generally the way to go (except for bugs that open
security holes), and I would prefer more back-compatibility than Ruby
has generally provided in the past. On the other hand, Ruby (like
Java) now produces major revs so infrequently that it's not a terribly
large problem. For all ends and intents, I consider Ruby to be a
stable language.

···

On 9/17/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:

Can you please point me to real examples? Java is one of the few
languages I know that has guaranteed backward compatibility. So, I
would really like to hear real examples, otherwise this sounds like
missinforming. And please do not mix backward compatibility with bugs.

17

Ahem, there's a lot of us that make money by our time... as a self employed contractor, it's all I have. As such I'd rather use Ruby - I can get more programming done in a given amount of time, which makes the customer happy and yields repeat business.

The changes are rarely big enough cause major problems; It's not like the language suddenly looks like a brand new language; they are not going to introduce python's whitespace rules or anything.

When a new release comes out, you just read through the changelog (someone will make a list of incompatibilities, I'm sure) and then use your tools... search, source code management.

Run a test system with your unit tests. (You do have a formal testing procedure, right?)

Perl has had its own share of backwards compatibility issues. I think it sounds like you are trying to find an excuse to block ruby in your organization.

These same methods should have been employed by everyone who got burned by the 1.1 release of rails. It's not that the changes were all that big, but some simple testing would have eased the transition.

David Morton
Maia Mailguard http://www.maiamailguard.com
mortonda@dgrmm.net

···

On Sep 17, 2006, at 5:43 AM, Joan Iglesias wrote:

In a company that you have to make money by your time, this is not a
good philosophy. Of course I understand that the improvements in the
syntax and all this is good..., I cannot modify my programs so many
times with the risk of making mistakes because of the language...

18

if you have a look to the language modification between 1.6 and 1.8,
there are some.

I've tried several 1.6 scripts in 1.8 and never had to change a single one. Maybe they didn't use the altered parts of the language, but all-in-all I think it was a pretty compatible release.

As you can read in the link above:

"Ruby2 will be slightly incompatible, the changes will not only consist
of additions but also of syntax improvements (hopefully a better syntax
will result)."

In a company that you have to make money by your time, this is not a
good philosophy. Of course I understand that the improvements in the
syntax and all this is good..., I cannot modify my programs so many
times with the risk of making mistakes because of the language...

But you could freeze your working software at Ruby 1.8, right?

1.8 doesn't disappear because 2.0 release. The Ruby team still occasionally patches 1.6 to resolve a security issue.

Honestly, this should really be a non-issue with proper test coverage. You try your tests on Ruby 2.0 and if they are green you're ready to deploy. If not, they should take you straight to the changes.

James Edward Gray II

···

On Sep 17, 2006, at 5:43 AM, Joan Iglesias wrote:

19

Alexandru Popescu wrote:

/ ...

Java has a long and annoying history of breaking older versions.

Can you please point me to real examples? Java is one of the few
languages I know that has guaranteed backward compatibility.

I have to disagree based on long experience. First, Java versions > 1.0
simply and unceremoniously threw out the earlier event handling mechanism.
Since then, there have been any number of app-breaking changes. After many
years of this, I just gave up trying to make my Web apps continue to
operate.

So, I
would really like to hear real examples, otherwise this sounds like
missinforming. And please do not mix backward compatibility with bugs.

Perfectly operable Java apps simply stopped operating, requiring either
substantial rewrites or abandonment. I have a lot of Java apps on my Web
site that I am eventually going to have to throw out, because of creeping
disability brought on by Sun's indifference to rearward compatibility
issues.

···

--
Paul Lutus
http://www.arachnoid.com

20

Francis, unfortunately what you are mentioning as backward
compatibility breaking are NOT valid arguements. You are talking about
some different JVM problems (and that is not SUN - and you were
refering to it), and than different path and classpath possible
problems. Those are not official SUN distributions and their philosphy
may be different from the creators one.

Just to clarify: Sun has kept the backward compatibility and has done
this with major versions too. There may be a single exception: Java
1.1 -> Java 1.2, but even about this I cannot say it for sure, because
I don't remember having API problems or thing like things (but my
memory can be bad after all this time).

best regards,

./alex

···

--
.w( the_mindstorm )p.

PS: I am not associated in any ways with SUN Co. I just like that the
readers are correctly informed.

On 9/17/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:

On 9/17/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> Can you please point me to real examples? Java is one of the few
> languages I know that has guaranteed backward compatibility. So, I
> would really like to hear real examples, otherwise this sounds like
> missinforming. And please do not mix backward compatibility with bugs.
>

You don't need examples from me. Just look to your own experience.
Have you ever tried running Oracle and a version of Tomcat that
requires a different JVM, on the same machine? (Yes, I know it's a bad
idea to run *anything* on the same machine with an Oracle instance,
but that's not my point.) Remember porting your AWT applications from
JDK 1.1 to 1.2?

It's true that Sun represents that they and their licensees will not
break older code so long as you stick to the "core" (java.*) packages.
(Their disclaimer is "unless they fix a serious bug.") In practice,
the experience has been painful. The OP said that he fears Ruby will
suffer back-compatibility problems in part because there is no large
company to provide the guarantee. My point was that the guarantee of a
large company may provide nothing but cold comfort as you modify your
code to deal with their "bug fixes,"
or worse, ship and maintain multiple versions of your code.

In my experience with Ruby, there haven't been all that many cases
where an emergency patch had to be made in order to fix a security
hole or other such urgent problem. I don't have any reason to suppose
that Matz, his team, or the community would make it difficult to patch
back versions of Ruby or its libraries in these cases. (The recent
security-emergency with Rails was very different, and quite badly
handled, but the Rails team is not the same as the Ruby team.)

Having said all this, I would stress that strict back-compatibility,
even with bugs, is generally the way to go (except for bugs that open
security holes), and I would prefer more back-compatibility than Ruby
has generally provided in the past. On the other hand, Ruby (like
Java) now produces major revs so infrequently that it's not a terribly
large problem. For all ends and intents, I consider Ruby to be a
stable language.