Backwards compatibility but not for Python

Programming languages change over time. (So do the natural, human-spoken languages. But let's stick to the programming languages.)

Most languages are designed and changes are carefully constructed to avoid breaking older programs. This is a tradition from the earliest days of programming. New versions of FORTRAN and COBOL were introduced with new features, yet the newer compilers accepted the older programs. (Probably because the customers of the expensive computers would be very mad to learn that an "upgrade" had broken their existing programs.)

Since then, almost every language has followed this tradition. BASIC, Pascal, dBase (and Clipper and XBase), Java, Perl, ... they all strove for (and still strive for) backwards compatibility.

The record is not perfect. A few exceptions do come to mind:

• In the 1990s, multiple releases of Visual Basic broke compatibility with older versions as Microsoft decided to improve the syntax.
• Early versions of Perl changed syntax. Those changes were Larry Wall deciding on improvements to the syntax.
• The C language changed syntax for the addition-assignment and related operators (from =+ to +=) which resolved an ambiguity in the syntax.
• C++ broke compatibility with a scoping change in "for" statements. That was its only such change, to my knowledge.

These exceptions are few. The vast history of programming languages shows compatibility from old to new versions.

But there is one language that is an exception.

That language is Python.

Python has seen a number of changes over time. I should say "Pythons", as there are two paths for Python development: Python 2 and Python 3. Each path has multiple versions (Python 2.4, 2.5, 2.6, and Python 3.4, 3.5, 3.6, etc.).

The Python 3 path was started as the "next generation" of Python interpreters, and it was started with the explicit statement that it would not be compatible with the Python 2 path.

Not only are the two paths different (and incompatible), versions within each path (or at least the Python 3 path) are sometimes incompatible. That is, some things in Python 3.6 are different in Python 3.7.

I should point out that the changes between versions (Python 3.6 and 3.7, or even Python 2 and 3) are small. Most of the language remains the same across versions. If you know Python 2, you will find Python 3 familiar. (The familiarity may cause frustration as you stumble across one of the compatibility-breaking changes, though.)

Should we care? What does it mean for Python? What does it mean for programming in general?

One could argue that changes to a programming language are necessary. The underlying technology changes, and programming languages must "keep up". Thus, changes will happen, either in many small changes or one big change. The latter often is a shift away from one programming language to another. (One could cite the transition from FORTRAN to BASIC as computing changed from batch to interactive, for example.)

But that argument doesn't hold up against other evidence. COBOL, for example, has been popular for transaction processing and remains so. C and C++ have been popular for operating systems, device drivers, and other low-level applications, and remain so. Their backwards-compatible growth has not appreciably diminished their roles in development.

Other languages have gained popularity and remain popular too. Java and C# have strong followings. They, too, have not been hurt by backwards-compatibility.

Python is an opportunity to observe the behavior of the market. We have been working on the assumption that backwards-compatibility is desired by the user base. This assumption may be a false one, and the Python approach may be a good start to observe the true desires of the market. If successful (and Python is successful, so far) then we may see other languages adopt the "break a few things" philosophy for changes.

Of course, there may be some demand for languages that keep compatibility across versions. It may be a subset of the market, something that isn't visible with only one language breaking compatibility, but only visible when more languages change their approach. If that is the case, we may see some languages advertising their backwards-compatibility as a feature.

Who knows? It may be that the market demand for backwards-compatibility may come from Python users. As Python gains popularity (and it is gaining popularity), more and more individuals and organizations build Python projects, they may find Python's approach unappealing.

Let's see what happens!

Windows 8 means a faster treadmill

The release of Windows 8 marks a change in Microsoft's approach to backwards compatibility. Microsoft has shifted its position from "compatible at just about everything" to "things change a lot and your old things may not work".

Windows 8 and its Metro interface re-define the programming of applications. On x86 processors, legacy applications can run in "Windows 7 mode". On ARM processors, legacy applications... cannot run. And while Windows 8 offers Windows 7 mode, Microsoft has made no promise of such a feature in future releases.

With the shift to WinRT and Metro, Microsoft has started a countdown clock for the lives of all Windows applications in existence.

In the past, Microsoft maintained compatibility for just about every application. Even vintage DOS applications would run under Windows XP (and probably still run under Windows 7). That compatibility came at no small expense, not only in development and testing costs, but at opportunity costs. (New development was constrained by the design decisions of previous releases.)

Users, developers, and support teams are on a treadmill, with new technologies and releases arriving faster than before. The good old days of decade-long technology planning have been replaced with a range of two or three years.

People can get upset about the faster pace of the treadmill, but they have nowhere to go.

Apple has "revved" its platform a number of times, changing the processor, the operating system, the user interface, and the device form factor. The folks working on Linux are working on similar changes.

If Microsoft believes that it can be more profitable in a new market, or if it believes that the current market is not profitable, then I believe that they will move to the new market. It's customer's problems with lack of backward compatibility are not Microsoft's problem.

Interestingly, corporations long ago lobbied for shorter depreciation schedules for computing equipment. They successfully got the depreciation for equipment reduced to ... three years. Now Apple and Microsoft seem to be agreeing, indicating that equipment really is obsolete after three years. (Except that they include software in the definition of "equipment".)



I'm not sure that this faster pace is a good thing. I'm also not sure that I like it. But I do know this: it's happening. The question is not how to stop it, or how to avoid it, but how to cope with it. How do we live in a world when technology changes (dramatically) every three or maybe two years?