The future of Ruby

Ruby
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

2

Joan I. wrote:

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.

3

On 9/16/06, Joan I. [email protected] wrote:

libraries developed under 1.8 Ruby?

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

4

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:

5

Joan I. wrote:

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

6

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

7

Marc H. 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

8

On 9/16/06, Daniel S. [email protected] 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.

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

9

On 9/17/06, Joan I. [email protected] 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. 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.

10

Rimantas L. 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

11

On 9/17/06, Alexandru P. [email protected]
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.

12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 17, 2006, at 5:43 AM, Joan I. 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…

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 M.
Maia Mailguard http://www.maiamailguard.com
[email protected]

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

iD8DBQFFDWZTUy30ODPkzl0RAv+eAJ9bqGiuHs0Z06ur+1g2yFoVG66MKgCgn7+I
84bngsszv/cWzPATE5q27eA=
=oW2r
-----END PGP SIGNATURE-----

13

On 9/17/06, Francis C. [email protected] wrote:

On 9/17/06, Joan I. [email protected] 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.

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

.w( the_mindstorm )p.

14

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

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.

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 G. II

15

On 9/17/06, James Edward G. II [email protected] wrote:

On Sep 17, 2006, at 7:41 AM, Austin Z. 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.

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

-austin

16

On Sep 17, 2006, at 7:41 AM, Austin Z. 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.

James Edward G. II

17

On Mon, 18 Sep 2006, James Edward G. II wrote:

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

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.

Long ago, when 1.8.0 was released, I recall having to make a few changes
to IOWA for it to run under 1.8.0. The effort was modest. I don’t
remember the details; all I remember is that I only had to change a few
lines; it took minutes, and when I was done, in that case, the code ran
on
both 1.8.x and 1.6.8. Since then, I have had no issues on any of the
1.8.x releases. The compatibility issue seems to me to be a very minor
one.

Kirk H.

18

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.

19

David M. wrote:

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

Yes I have.

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.

Could you give me an example (perl)? I didn’t find it. I’m quite new at
this scriping languages, because until now I was a system administrator
(bash). I’m not blocking nothing, because I work as a freelance
consultant, and I would like to give to my clients some king of long
term security in the product that they buy and mantein (in my case).

I have heared your arguments, maybe you are right. I supose changes will
be there allways, it’s a matter of having a very good organitzation to
respond to the changes as soon as possible…

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.

Can you give me a reference to the rails problem, please? Thank you. My
projects, if I use Ruby, will work on Rails.

David M.
Maia Mailguard http://www.maiamailguard.com
[email protected]

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

iD8DBQFFDWZTUy30ODPkzl0RAv+eAJ9bqGiuHs0Z06ur+1g2yFoVG66MKgCgn7+I
84bngsszv/cWzPATE5q27eA=
=oW2r
-----END PGP SIGNATURE-----

20

Francis C. wrote:

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.
Also, once you find an incompatibility, you can write code that works in
both versions. Simple example from Rails:
unless defined? instance_exec # 1.9
def instance_exec(*arguments, &block)
block.bind(self)[*arguments]
end
end
(Runtime #ifdef, if you will.) So you shouldn’t need to maintain
multiple versions of the code.

Devin