C/C++ Users Journal April, 2005
Portability is one of those terms that has too many meanings. People argue vehemently, and endlessly, about whether a given programming language or execution platform "is portable." Of course, it is a matter of only partial interest whether the language itself (and its compilers) or the platform itself (and its interpreters) is itself portable. If you can move such things from platform to platform, you increase the availability of the tools you need to write portable programs. And while availability is an important component of a portable solution, it is by no means all of it.
When people say that a language "is portable," what they usually mean is that it makes it easier to write portable programs. And when they say that a program "is portable," they can mean all sorts of things. Here are a few:
I've seen many efforts, over the decades, to make programs more portable. None fits tidily into any of the above categories, but many have had their successes. Let me recite a few.
Fortran was my first programming language, back in the early 1960s. I had access to several different computers, all made by IBM and all with Fortran compilers. I could write great swatches of mathematical calculations (Formula Translations) quite portably, but had no end of trouble with all the different conventions for input/output. So I kept different card decks all around campus and worked hard to keep them in sync. Fortran is now a niche language, but it is still alive because it is so good at the math bits.
C caught on first within Bell Labs, then as a companion to UNIX, and soon after as a language offered by many third-party vendors. It is notorious for letting you shoot yourself in the foot so easily, but it is famous for having spread to so many diverse computers, dragging millions of lines of code in its wake. It annoys people by sprawling across all of the categories listed above, yet somehow supporting portable programming for what many consider to be all the wrong reasons.
Pascal had a brief surge of popularity in the early 1980s, thanks mostly to the UCSD P-System. The language aimed at a stringent form of portability by restricting what you could say, and the P-System interpreter promised to let you execute the same binaries on different CPUs. But the restrictions, in the end, proved not to be a good guarantor of portability. And the interpreter failed to isolate endianness issues, so you couldn't really share binaries all that broadly. Pascal flourished, and continues to endure, thanks more to the extensions made by Borland than to the original language design.
C++ bloomed as programs got too large for more modest languages such as C and Pascal. It has wisely been kept highly compatible with C, and it has also benefited from a successful ISO Standard. C++ is somewhat less portable than C because it stresses compiler technology so hard, but it otherwise shares most of the virtues, and vices, of C.
Java is the latest reincarnation of the Pascal approach. It has more object-oriented features (classes and methods), a better designed interpreter (the JVM), and way more money thrown at it (by Sun and others). The language design seems to be almost a direct repudiation of the changes made in C between the publication of Kernighan & Ritchie and the first C Standard. All those varying data sizes and representations went out the window in the name of increased portability. Unfortunately, in the back door came multithreading and graphics, adding way more portability problems than were banished by tightening up the C heritage. Java is now a niche language, but in a very big niche.
So which of these languages "is portable"? None of them. Which is usable if you need to write portable code? Any of them, with suitable care. That's why the debate continues, vehemently and without end.
P.J. Plauger
Senior Contributing Editor
pjp@plauger.com