Backward compatibility

Posted Jun 26, 2004 1:06 UTC (Sat) by mly (guest, #2171) [Link]

>But remember to consider the other direction of compatibility: Have you
>seen a recent Python program fail to run on a ten year old interpreter?

I don't think I've heard of anyone still using a ten year old Python interpreter, but sure, a program using new Python 2.3 features won't run on a RedHat 7 box with Python 1.5.2 for instance.

You have the same kind of problem with C++. For some reason, C++ was placed in the same camp as C. There is now COBOL for .NET and OO COBOL. I'm pretty sure programs written for these systems won't run on any old IBM either. The only Pascal dialect in wide use is Delphi's Object Pascal. How compatible with anything else is that? If the article autor wanted to say that recently invented features can't always be used on old platforms, I agree, but the bundling of languages into two groups like that has little to do with this problem.

If you rely on any third party libraries, you probably have the same issue with C. At least if the libaries don't come as pure ANSI C source code with no dependencies on other system components. The typical C way to avoid this is not to use third party libraries. Instead every programmer reinvents the wheel and writes his own undocumented libraries for everything. (I'm only exaggerating a little here. ;)

It all depends on who your target users are, what kind of features you need, and how you deploy your software. It's only for certain subsets of computer users you can expect C source code and shell scripts to be useful as a deliverables.

You can't really expect a Python runtime environment to be installed everywhere anyway. You certainly can't ship simple Python scripts to the typical windows user, and expect them to run them. One approach for Python applications is to deliver the runtime environment and needed libraries with the application, and install it in a special location for just this program. (Disk is cheap, right?)

In a Linux environment you might expect people to be able to get Python if they don't have it. If you develop your programs using Python 1.5.2 and avoid a tiny number of things that changed since then (assert and yield became keywords) you should be pretty safe. That's still a much less primitive tool than ANSI C and shell script.

The problems in deploying software in a constructive way can't be solved in such as simplistic way as to divide programming languages into two broad groups and to select anything from one of the groups. For an insightful analysis of this problem I recommend Luke Hohmann's Beyond Software Architecture: Creating and Sustaining Winning Solutions http://www.amazon.com/exec/obidos/ASIN/0201775948/

Posted Jul 1, 2004 2:41 UTC (Thu) by roelofs (subscriber, #2599) [Link]

But 10 years ago, there were still a lot of pre-ANSI compilers floating around. SunOS, for example, shipped with a bundled compiler ("cc"), so a lot of people never bothered to install gcc. Maybe I'm stretching things a bit, but then again, maybe you are, too. ;-) Shift that 10-year window back a few years, and you'll land right in the middle of the K&R/ANSI changeover.

(Believe it or not, this exact issue came up recently: should Info-ZIP finally toss out K&R compatibility--which has some serious uglification issues--or nuke it in favor of more readable code? I favor the latter, but some folks think any sacrifice of portability is bad.)

Greg