Francis C. 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
On 9/17/06, Francis C. [email protected] 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?
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 06-09-17, at 21:20, Joe R. MUDCRAP-CE wrote:
Francis C. 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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 17, 2006, at 2:58 PM, Joan I. wrote:
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. 
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 M.
Maia Mailguard http://www.maiamailguard.com
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFDg81Uy30ODPkzl0RAsuzAKCxBi/J9ejTfyhWSwwThXjRIv/KsACfYiQq
CPik9hv9AruXstd6ebfbYyI=
=EdkT
-----END PGP SIGNATURE-----
On 06-09-18, at 01:03, Joe R. MUDCRAP-CE wrote:
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.
Jeremy T. wrote:
On 06-09-17, at 21:20, Joe R. MUDCRAP-CE wrote:
Francis C. 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
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
On 9/17/06, Joe R. MUDCRAP-CE [email protected] wrote:
Francis C. 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.
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, Charles O Nutter [email protected] wrote:
On 9/17/06, Francis C. [email protected] 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?
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
R.
–
Contribute to RubySpec! @ www.headius.com/rubyspec
Charles Oliver N. @ headius.blogspot.com
Ruby U. @ 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
Joan I. 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.
Alexandru P. 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.
Quoting Joan I. [email protected]:
way that perl will matein it between Perl 5 and Perl 6.
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.
On 9/17/06, Jeremy T. [email protected] wrote:
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
Devin M. wrote:
endend
(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?
On 9/18/06, Austin Z. [email protected] wrote:
…or that fixing all the bugs will actually cause more problems for
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.
Devin M. [email protected] writes:
endend
(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?
On 9/17/06, Joan I. [email protected] wrote:
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…
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.
Christian N. 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. 
Christian N. 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
On Tue, Sep 19, 2006 at 06:56:24AM +0900, Christian N. 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?
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].