The New Age of Programming [LWN.net]

The New Age of Programming

Posted Jun 24, 2004 21:29 UTC (Thu) by mly (guest, #2171)
Parent article: The New Age of Programming

It seems to me that the article writer makes a serious mistake bundling a lot of diverse languages in two groups like that, and then draw general conclusions about all languages in each group from clearly limited experiences of odd samples in each group. It's only misleading.

While C++ has been defined in standard documents, it took a lot of years to decide on a standard, and more years for compiler vendors to conform. For instance, compilers still don't agree on whether...

for (int i=0; i<5; i++) {
// whatever
}

...means that i is a local variable inside the for-loop block or outside it. Many programmers still avoid C++ beacuse they consider it too difficult to write maintainable cross platform programs with it. Compilers are too different.

It seems to me that people who need to work in cross platform environments often prefer C or Python.

I don't have a lot of experience with Java, but I've certainly heard some horror stories about upgrades and incompatibilities there.

I agree that e.g. Python is developed at a much faster speed than COBOL or C++, but I've rarely experienced that ten year old Python programs fail to run in the latest interpeter. The Python community members maintain a lot of code, and are very reluctant to cause maintenace problems for themselves. I think it's just the same with Perl, Tcl etc.

(Log in to post comments)

Backward compatibility

Posted Jun 25, 2004 18:33 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

>I've rarely experienced that ten year old Python programs fail to run in the latest interpeter.

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 distribute a small amount of software in Perl. I frequently break it by using a new Perl feature that my users' old systems don't have. Neither the interpreter nor the documentation help me know when I'm using a new language feature that my users might not be able to handle.

By contrast, I distribute a large amount of C/libc code, which I test with gcc -ansi. I virtually never have the same problem.

So I will tend to stick to C and Bourne Shell for software that is for the masses.

I think a fundamental point of the article is that in the one camp, you have people who not only can but must use the latest and greatest technology; and in the other, you have people who are stuck in the past, which is sometimes a good place to be.

Backward compatibility

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

>> I've rarely experienced that ten year old Python programs fail to run
>> in the latest interpeter.

>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/

Backward compatibility

Posted Jul 1, 2004 2:41 UTC (Thu) by roelofs (subscriber, #2599) [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?...By contrast, I distribute a large amount of C/libc code, which I test with gcc -ansi. I virtually never have the same problem.

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