In the theoretical sense, the notion of backwards compatibility in programming languages is sound. However, when we try and apply this theory on a universal scale we begin to see a number of tiny breakdowns that point towards the reality that the concept of backwards compatible software languages, at least from a universal perspective, is a myth.
One of the most notorious of languages to embrace the concept of preserving backwards compatibility is Java. However, Java does not absolutely preserve backwards compatibility, despite their claims. The most prominent example of this is in the upgrade from J2SE 1.4 to 1.5. Anyone use ‘enum’ as a variable name in their code? If so you broke. Perhaps I am misinterpreting the true meaning of backwards compatible, but this does not seem to fit.
However, just because your application falls into the realm of a backwards compatible one doesn’t mean that you are set. Any application that uses a third party library that proves to not be backwards compatible is doomed as well. Unless there is a new version of your library that integrates with the upgraded language, you have the ability to fix the library, or have a substitute library you can use, your upgrade is doomed.
The concept of backwards compatibility is a good one, however everything should be in moderation. When the adherence to this rule comes at the cost of the proper implementation of language features, as Bruce Eckel discusses, it can be argued that the notion of backwards compatibility is more of a long term bane than blessing. If the features of the language upgrades are good enough people will upgrade, regardless of whether they have to do a little more work. One look to the recent Ruby or Python additions are proof of this.