[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

the future of Ruby

Joan Iglesias

9/16/2006 6:50:00 PM

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-....
37 Answers

Paul Lutus

9/16/2006 9:22:00 PM

0

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

Simen

9/16/2006 9:42:00 PM

0

On 9/16/06, Joan Iglesias <joan.iglesias@yahoo.es> 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!
>
> Joan
>
> --
> Posted via http://www.ruby-....
>

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

--
- Simen

Daniel Schierbeck

9/16/2006 10:16:00 PM

0

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

Marc Heiler

9/17/2006 8:47:00 AM

0

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


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

Joan Iglesias

9/17/2006 9:50:00 AM

0

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

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/perl...

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

Rimantas Liubertas

9/17/2006 10:00:00 AM

0

> 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://rim...

Joan Iglesias

9/17/2006 10:44:00 AM

0

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

Austin Ziegler

9/17/2006 12:41:00 PM

0

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.

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
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Alexandru Popescu

9/17/2006 1:53:00 PM

0

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.

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.



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

Francis Cianfrocca

9/17/2006 2:53:00 PM

0

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.