Summary
For languages and published APIs breaking compatibility has a cost, but so does creeping entropy.

Guido van Rossum recently made the slides from his talk on Python 3000 at ACCU 2006 available for download. I was not at ACCU 2006, but I did see Guido give a practice run of the same talk a few weeks ago at a local ACCU meeting in San Jose. In this talk, Guido discussed the philosophy and features of Python 3000, a major new version of Python that will be developed alongside the current stream of 2.x versions. One of the main bullet points on Python 3000 philosophy is:

• Allow incompatible changes; within reason

When developing new versions of languages and published APIs, maintaining backwards compatibility is usually one of the designer's main concerns. By maximizing backwards compatibility, the designer minimizes the cost for existing users of the language or API to upgrade to the new version. However, with each new release there are invariably changes that would improve the design, but which would break backwards compatibility. Over time, always choosing backwards compatibility over design improvement means that entropy creeps into the language or API. This entropy too has a cost: the language or API becomes more complex and confusing for developers to use.

One of the most basic kinds of breaking change a designer can make in a new version is to remove features that had been deprecated in previous versions. For example, Python 2.2 introduced "new-style" classes, to provide Python with a unified object model with a full meta-model. Old-style classes, which starting with version 2.2 were referred to as "classic" classes, were still supported for backwards compatibility. The intention was that new code, however, should use new-style classes. One of the first thing Guido did on the Python 3000 codebase was remove classic classes. "It felt good to rip them out," he said.

New versions of Java have made breaking changes at the source level too. For example, the introduction of the assert keyword in version 1.4 broke code that used assert as a variable or method name (such as just about any JUnit TestCase, whose calls to assert() needed to be changed to assertEquals()). Nevertheless, my observation is that the Python community has been more willing to accept breaking changes than the Java community. As Guido put it, "Java has a very long backwards compatibility cycle." Many methods in the Java API have been deprecated, but I know of none that have been actually removed. The result is that Java over time has become more and more bloated with historical design artifacts, while Python remains more lean, mean, and clean.

What do you think is the correct tradeoff between backwards compatibility and entropy reduction for Python and Java? Does Python go too far to clean things up from release to release? Does Java not go far enough?

Talk Back!

Have an opinion? Readers have already posted 12 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bill Venners adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala.