The language treadmill

Technology is not a platform, but a treadmill. Readers of a certain age may remember the closing credits of "The Jetsons", in which George Jetson walks their dog astro on a space-age treadmill that runs a bit faster than he would like. The image is not too far off from the technology treadmill.

We're accustomed to thinking of hardware as changing. This year's laptop computer is better (faster, more powerul, more memory) than last year's laptop computer. We consistently improve processors, memory, storage, displays, ... just about everything. Yet the hardware also changes; today's laptop PCs are a far cry from the original IBM PC. Even desktop PCs are different from the original IBM PC. So different, in fact, that they would not be considered "PC compatible" at the time. (Today's USBC-attached displays would not connect, today's USB keyboards would not connect, nor would USB thumb drives. Nothing from today's PC's would connect to an IBM PC model 5150, nor would anything from 1982's IBM PC connect to today's PCs.)

The treadmill includes more that hardware. It also includes software. Operating systems are the most visible software that changes; we deal with them every day. Microsoft has made improvements to each version of Windows, and Windows 10 is different from Windows 3.11 and especially Windows 1.0. Apple changes OS X and that is quite different from the original OS X and much different from the previous Apple OS versions.

The treadmill extends beyond hardware and operating systems. It includes applications (Microsoft Word, for example) and it also includes programming languages.

Programming languages, whether governed by committee (C, C++) or individual (Perl, Python) change over time. Many times, a new version is "backwards compatible", meaning that your old code will work with the new compiler or interpreter. But not always.

Some years ago, I worked on a project that built and maintained a large-ish C++ application which was deployed on Windows and Solaris. The C++ language was chosen because both platforms supported that language; compilers were available for Windows and for Solaris. But the compilers were upgraded on different schedules: Microsoft had their schedule for upgrades to their compiler, and Sun had their (different) schedules for upgrades to their compiler.

Different upgrade schedules could have been a problem, but it wasn't. (Until we made it one. More on that later.) Most updates to the compilers were backwards-compatible, so old code could be moved to the new compiler, recompiled, and the resulting program run immediately.

Most updates worked that way.

One update did not. It was an update to the C++ language, one that changed the way C++ worked and just so happened to break existing code. (The C++ governing committee was reluctant to make the change, but it was necessary and I agree with the reasoning.) So the upgrade required changes to the code. But we couldn't make the changes immediately; we had to wait for both compilers (Microsoft and Solaris) to support the new version of C++.

It turns out that we also had to wait for our managers to allocate time to make the code changes for the new compilers. Our time was allocated for new features to the large-ish application, not to technical improvements that provided no new business features. Thus, our code stayed with the old (soon to be outdated) structures.

Eventually, we saw a chain of events that forced us to update our code. Sun released a new version of the Solaris operating system, and we had to install that to stay current with out licenses. Once installed, we learned that the new operating system supported only the new version of the C++ compiler, and our code immediately broke. We could not compile and build our application on Solaris, nor release it to our production servers (which had been updated to the new Solaris).

This caused a scramble in the development teams. Our managers (who had prevented us from modifying the C++ code and moving to the new C++ compiler) were now anxious for us to make the changes, run tests, and deploy our application to our servers. We did make the changes, but it required us to stop our current work, make changes, run tests, and deploy the applications. Those efforts delayed other work for new features.

This is a cautionary tale, illustrating the need to stay up to date with programming tools. It also shows that programming languages change. Our example was with C++, but other languages change. Python has had two version "tracks" for some time (version 2 and version 3) and development and support of version 2 has come to an end. The future of Python is its version 3. (Do you use Python? Are you using version 3?)

Oracle has released Java version 14. Many businesses still use version 8.

There have been changes to JavaScript, TypeScript, C# (and .NET, on which C# rests), and even SQL. Most of these changes are backwards-compatible, so no code changes are required to move to the new version.

You will eventually move to the new operating system, or compiler, or interpreter. Your code may have to change. The changes can be on your schedule, or on someone else's schedule. My advice: be aware of updates and migrate your programming tools on yours.