| |||||||||||
Backward compatibilityBackward compatibilityPosted Jun 26, 2004 1:06 UTC (Sat) by mly (guest, #2171)In reply to: Backward compatibility by giraffedata Parent article: The New Age of Programming
>> I've rarely experienced that ten year old Python programs fail to run >But remember to consider the other direction of compatibility: Have you 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/
(Log in to post comments)
|
|||||||||||