The future of Ruby

ruby-talk
21

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 Haines

···

On Mon, 18 Sep 2006, James Edward Gray II wrote:

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

22

Francis Cianfrocca 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

23

David Morton 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 Morton
Maia Mailguard http://www.maiamailguard.com
mortonda@dgrmm.net

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

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

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

24

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?

1.1 to 1.2 was a sea change in the Java world, so much so that 1.2 was
when the name "Java 2" came above. However from 1.2 through 1.6 (or 6,
as I guess it's supposed to be called) things have stayed very
consistent. Backward compatibility depends also on the complexity of
applications...Sun, like any software developer, has chosen to fix
problems from release to release. More complicated applications are
more likely to be burned by those fixes...but it doesn't necessarily
mean backward-compatibility was broken. It just means that older code
depended on flaws that were later fixed. I don't think you could
reasonably argue that things shouldn't be fixed, though I agree the
definition of a "flaw" is rather subjective.

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.

That has not been my experience. Very large applications often have
trouble upgrading, usually because they depended on or were written
around bugs in the original version. Smaller apps almost always just
work.

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

Java is a signficantly more complicated beast than Ruby, but Sun does
try to make a best effort to backport significant changes. However
many shops refuse to upgrade at all. Ruby also has had a far slower
release cycle, meaning that backporting fixes generally only required
making changes to minor revisions. Have any fixes in 1.8 been
backported to 1.6 recently? I don't think so. However I know many
shops that are still on Java 1.4 (and some on Java 1.3) that can't
reasonably expect to get fixes applied to Java 5 or 6 (1.5/1.6) since
1.4 is now almost five years old.

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.

Stable or slow to evolve? I agree with stable, actually, and most of
the stuff planned for 2.0 I don't even think is all that necessary.
Ruby has never really felt to me like it's missing much, but I may
just be easy to please.

Java has often felt like it's missing things, but when I pair it with
a dynlang like Ruby suddenly it does what it does best very well. Just
like many folks in the Ruby world pair Ruby and C to get the best of
all worlds, I pair Ruby and Java. I think language evolution is highly
overrated in general when there are plenty of languages out there to
fit every task.

···

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

--
Contribute to RubySpec! @ Welcome to headius.com
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn

25

Francis Cianfrocca wrote:

I would stress that strict back-compatibility,
even with bugs, is generally the way to go (except for bugs that open
security holes)

Big -1 there. BC with bugs? Ixnay.

Joe

···

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

26

That would seriously depend on the bug. Some bugs, you know EXACTLY how they're going to react, and if it's relatively minor, why bother running the risk of introducing a different, worse bug in the process of fixing that minor bug? I mean shit, that's just silly. You need to realize that not all bugs need to be fixed, just as not all injuries need a doctor.

···

On 06-09-17, at 21:20, Joe Ruby MUDCRAP-CE wrote:

Francis Cianfrocca wrote:

I would stress that strict back-compatibility,
even with bugs, is generally the way to go (except for bugs that open
security holes)

Big -1 there. BC with bugs? Ixnay.

--
Jeremy Tregunna
jtregunna@blurgle.ca

27

Could you give me an example (perl)? I didn't find it. I'm quite new at

Unfortunately I don't remember the exact program, I remember installing an open source program (something like a network monitor or something) and it wouldn't work on every version.

I also remember hearing that perl 4 to perl 5 had a lot of incompatible changes, just look for a doc on migrating from perl 4 to perl 5.

I've also run into quite a few pieces of software that needed specific versions of java. Oracle being the worst; I still haven't found the right version of java to get it to run.

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.

You must be new here. :slight_smile: The rails team didn't handle the 1.0 to 1.1 upgrade well, and worse, all the web host services upgraded without doing proper testing. Hopefully they have learned their lesson early.... :slight_smile:

The rails framework is still undergoing very rapid development, and so leaving your app in the hands of the system installed version is not a good idea. To help with this, you can either lock your rails app to a specific installed version, or you can install the whole rails tree within your own app, which will keep it from ever being broken by a rails upgrade.

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

···

On Sep 17, 2006, at 2:58 PM, Joan Iglesias wrote:

28

We've been talking about Java which is of course offtopic in a Ruby forum
(but the OP started it by suggesting that Java may be more back-compatible
than Ruby for *no other reason* than it has a large company behind it). As I
noted above, Sun's "guarantee" (which is really just a representation) that
neither they or their licensees will break back-compatibility includes the
disclaimer "unless we fix a serious bug."

A bug that opens a security hole must be fixed asap. If the fix breaks
existing code, that's life in the big city.

A change which breaks existing APIs (either by the violent means of changing
the method signature or the insidious means of changing its behavior) is
hard to characterize as a bug fix, as far as I'm concerned. You have
published a behavior which people now depend on, and if you decide it should
have been designed differently, well, the design flaw is your
responsibility. If you own the API (as Sun does Java), then you're free to
change it, but NOTHING infuriates developers like having working code
suddenly break for no discernible reason. You lose a lot of good will by
doing this, whether you call it a bug-fix or not. Sun, to their credit, well
understand this, and have kept this kind of thing to a minimum over the last
few years. Microsoft (whose entire business depends on locking developers to
their platform) understand this even better than Sun.

To me, a bug fix is when you change the behavior of something to conform to
the published description of how it was supposed to work, not because you
realized you left out a feature. Ruby has done its share of breaking older
code in order to improve APIs and add features, especially in the libraries.
But to go back to the original point, I don't think it's been any worse than
Java.

···

On 9/17/06, Joe Ruby MUDCRAP-CE <joeat303@yahoo.com> wrote:

Francis Cianfrocca wrote:
> I would stress that strict back-compatibility,
> even with bugs, is generally the way to go (except for bugs that open
> security holes)

Big -1 there. BC with bugs? Ixnay.

29

Big -1 there. BC with bugs? Ixnay.

BCWPWAP (Back When Pluto Was A Planet) Joel Spolsky had written this:

It's lenghty and some points have lost their validity, but it is an
interesting read.
One of the most amusing pieces is about special code introduced to
windows to work
around the bug in the game "SimCity" - for BC reasons.

Regards,
Rimantas

···

--
http://rimantas.com/

30

I just grepped for the word deprecated through my Java 1.5 doc, I got
7759 hits, (which is not an awful lot, this is in >> 1M lines of html)
yet I feel to say Java is not breaking backward compatibility is slightly
exaggerated.

Cheers
Robert

P.S.
Maybe there are some false hits like "this will never get deperecated" too
:wink:

R.

···

On 9/17/06, Charles O Nutter <headius@headius.com> wrote:

On 9/17/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> 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?
<SNIP>

--

Contribute to RubySpec! @ Welcome to headius.com
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

31

Devin Mullins wrote:

Francis Cianfrocca 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

There is problem with extensions.
Fixing is easy but boring because it can't be fully automatized.
replace RARRAY(ary)->ptr with RARRAY_PTR(ary)
(could be automatic by hacking C parser)
character is now string so find functions which deal with chars and
rewrite it.
(Finding is easy because it causes TypeError)
What else I forget?

32

Devin Mullins <twifkak@comcast.net> writes:

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

OT: I must be dumb, but if it was that easy, why did Mauricio
Fernandez need almost a page of code to produce a good instance_exec?

···

Devin

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

33

With any large application it's not even so much the language itself
as all the modules that you might be using from third parties. For
all practical purposes CPAN is just as much a part of perl as the core
language, and I can't count all the broken module upgrades I've had to
go through. Ditto for python and ruby modules/libraries. Experience
say's that upgrades break things despite the best intentions,
regardless of the language. Pick a language you like, resign yourself
to the fact that stuff will beak, and move on.

···

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

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

34

Jeremy Tregunna wrote:

···

On 06-09-17, at 21:20, Joe Ruby MUDCRAP-CE wrote:

Francis Cianfrocca wrote:

I would stress that strict back-compatibility,
even with bugs, is generally the way to go (except for bugs that open
security holes)

Big -1 there. BC with bugs? Ixnay.

That would seriously depend on the bug. Some bugs, you know EXACTLY
how they're going to react, and if it's relatively minor, why bother
running the risk of introducing a different, worse bug in the process
of fixing that minor bug? I mean shit, that's just silly. You need to
realize that not all bugs need to be fixed, just as not all injuries
need a doctor.

Seriously? Being paralyzed by the fear of introducing new bugs is
justification for not fixing existing bugs? Now that's silly.

Joe

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

35

...or that fixing all the bugs will actually cause more problems for
your customers than they should otherwise cause. Raymond Chen -- an
excellent read even if you don't like Microsoft -- recently had a
piece about a bug in an embedded version of Samba that was taking
advantage of a bad bug in previous versions of Windows. Fixing it was
a huge problem for Microsoft, because they had customers who depended
on this product with embedded Samba -- and they weren't the type of
customers who could even think about upgrading the embedded software.

Not all bugs are worth the cost of fixing them. Even ones that cause
security holes may not be worth *fixing* as much as *sandboxing* if
you have enough dependent clients.

-austin

···

On 9/17/06, Jeremy Tregunna <jtregunna@blurgle.ca> wrote:

On 06-09-17, at 21:20, Joe Ruby MUDCRAP-CE wrote:
> Francis Cianfrocca wrote:
>> I would stress that strict back-compatibility,
>> even with bugs, is generally the way to go (except for bugs that open
>> security holes)
> Big -1 there. BC with bugs? Ixnay.
That would seriously depend on the bug. Some bugs, you know EXACTLY
how they're going to react, and if it's relatively minor, why bother
running the risk of introducing a different, worse bug in the process
of fixing that minor bug? I mean shit, that's just silly. You need to
realize that not all bugs need to be fixed, just as not all injuries
need a doctor.

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

36

Christian Neukirchen wrote:

OT: I must be dumb, but if it was that easy, why did Mauricio
Fernandez need almost a page of code to produce a good instance_exec?
  

I think the page of code is hidden somewhere in Proc#bind. :wink:

···

--
Florian Frank

37

Christian Neukirchen wrote:

OT: I must be dumb, but if it was that easy, why did Mauricio
Fernandez need almost a page of code to produce a good instance_exec?

AFAIK, you're not dumb. Rails just extracted the fancy logic into Proc#bind (which doesn't come with Ruby). And the Rails instance_exec isn't a good instance_exec, IIRC (and I might not).

Devin

38

For the sake of future googlers...

Getting a more or less working implementation is easy, but things become harder if
you try to make it:
* thread-safe
* work with immediate objects
* work with frozen objects
* bounded-space (i.e. not leak memory on each call)
...
[And anticipating such corner cases is even harder :)]

As said elsewhere in this thread, Rails' version relies on Proc#bind, defined as

class Proc #:nodoc:
  def bind(object)
    block, time = self, Time.now
    (class << object; self end).class_eval do
      method_name = "__bind_#{time.to_i}_#{time.usec}"
      define_method(method_name, &block)
      method = instance_method(method_name)
      remove_method(method_name)
      method
    end.bind(object)
  end
end

This implementation
* is not strictly thread-safe (in practice, it will be, since I doubt Ruby
  will switch contexts in under 1us on any machine)
* doesn't work with immediate (Fixnums, etc.) nor frozen objects
* leaks memory [1] (around 70 bytes per #instance_exec call)

I've analyzed several #instance_exec implementations [2] and written a
thread-safe, bounded-space one that works with frozen and immediate objects [3].

1. http://eigenclass.org/hiki.rb?ruby+symbols+memleak
2. http://eigenclass.org/hiki.rb?instance_exec
3. http://eigenclass.org/hiki.rb?bounded+space+instance_exec

···

On Tue, Sep 19, 2006 at 06:56:24AM +0900, Christian Neukirchen wrote:

Devin Mullins <twifkak@comcast.net> writes:
> 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.

OT: I must be dumb, but if it was that easy, why did Mauricio
Fernandez need almost a page of code to produce a good instance_exec?

--
Mauricio Fernandez - http://eigenclass.org - singular Ruby

39

Jeremy Tregunna wrote:

Francis Cianfrocca wrote:

I would stress that strict back-compatibility,
even with bugs, is generally the way to go (except for bugs that open
security holes)

Big -1 there. BC with bugs? Ixnay.

That would seriously depend on the bug. Some bugs, you know EXACTLY
how they're going to react, and if it's relatively minor, why bother
running the risk of introducing a different, worse bug in the process
of fixing that minor bug? I mean shit, that's just silly. You need to
realize that not all bugs need to be fixed, just as not all injuries
need a doctor.

Seriously? Being paralyzed by the fear of introducing new bugs is
justification for not fixing existing bugs? Now that's silly.

If you're trying to maintain compatibility with previous versions of your software, or the bug is low impact, the risk outweighs the benefit.

···

On 06-09-18, at 01:03, Joe Ruby MUDCRAP-CE wrote:

On 06-09-17, at 21:20, Joe Ruby MUDCRAP-CE wrote:

Joe

--
Jeremy Tregunna
jtregunna@blurgle.ca

40

Quite right. Another thing that we haven't stressed enough is the role
of the community in freely-licensed open-source products like Ruby
(and unlike Java). If there are serious bugs that really should be
fixed, all of the source and revision history is wide open, and anyone
with an incentive (namely, anyone who has to run a back version of
Ruby for whatever reason) can backpatch if they really need to. The
dynamic in this case favors correctness, even for back-versions. On
the other hand, with software that is encumbered by closed-source
and/or license restrictions, like Java and certainly like anything
Microsoft writes, then the decision to fix bugs, even major security
holes, is literally an economic one. The dynamics do not necessarily
favor back-compatibility. So you could argue that the risk is even
higher with corporate-sponsored products.

I know the "official" versions of Java will soon be open-source. But
they won't be available under a BSD-style license anytime soon, so far
as I am aware.

···

On 9/18/06, Austin Ziegler <halostatue@gmail.com> wrote:
> ...or that fixing all the bugs will actually cause more problems for

your customers than they should otherwise cause. Raymond Chen -- an
excellent read even if you don't like Microsoft -- recently had a
piece about a bug in an embedded version of Samba that was taking
advantage of a bad bug in previous versions of Windows. Fixing it was
a huge problem for Microsoft, because they had customers who depended
on this product with embedded Samba -- and they weren't the type of
customers who could even think about upgrading the embedded software.

Not all bugs are worth the cost of fixing them. Even ones that cause
security holes may not be worth *fixing* as much as *sandboxing* if
you have enough dependent clients.