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? 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. > > -- Contribute to RubySpec! @ www.headius.com/rubyspec Charles Oliver Nutter @ headius.blogspot.com Ruby User @ ruby.mn