the future of Ruby

[Jeremy Tregunna]

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.

 

[David Morton]

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

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.

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

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
(e-mail address removed)



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

iD8DBQFFDg81Uy30ODPkzl0RAsuzAKCxBi/J9ejTfyhWSwwThXjRIv/KsACfYiQq
CPik9hv9AruXstd6ebfbYyI=
=EdkT
-----END PGP SIGNATURE-----

 

[Joe Ruby MUDCRAP-CE]

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

 

[Jeremy Tregunna]

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.

 

[Rimantas Liubertas]

Big -1 there. BC with bugs? Ixnay.

BCWPWAP (Back When Pluto Was A Planet) Joel Spolsky had written this:
http://www.joelonsoftware.com/articles/APIWar.html
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

 

[William Crawford]

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.

 

[neleai]

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?

 

[znmeb]

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

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.

 

[Austin Ziegler]

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.

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

 

[Francis Cianfrocca]

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

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.

 

[Florian Frank]

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.

 

[snacktime]

Yes I have.


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

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.

 

[Devin Mullins]

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

 

[Mauricio Fernandez]

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?

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