Lo, on Monday, December 31, Jeffrey W. Baker did write: (First, a quick note about my credentials. For the last 3.5 years, I've been working as a software developer at a telecommunications company. I do most of my work in C++. However, as an undergraduate, I concentrated on programming language theory and implementation techniques, so I bring both practical experience and theoretical understanding to this issue.)
<SNIP> > I submit -- and this has been my only point all along -- that the > different attributes and qualities of programming languages exist > entirely in our heads. In general, you're correct: type safety, garbage collection, and multiple inheritance are all abstractions that are layered on top of the standard computer hardware. One could approach computing purely from the perspective of the CPU, which performs only a limited set of very simple instructions. In my experience, though, this doesn't get you very far. (I wouldn't want to read an assembly language program that's longer than about 250 lines, and even that's pushing it.) Some of my co-workers seem to be stuck at the level of abstraction that you describe. Their code tends to execute extremely rapidly. However, it is also extremely difficult for other people to read and understand, and it is very sensitive to changes in other (theoretically separate) parts of the system, so it's extremely fragile. As a result, maintenance costs are much higher. In short: extremely low-level views of computing don't scale well. I think Knuth said it best: good programmers must be prepared to function at a whole range of abstraction levels, and they must be prepared to shift between these levels very rapidly. In addition, there have been computers from time to time that provide, in hardware, much more support for advanced languages than is typical among general-purpose computers today. Take a look at the Lisp Machines produced by a number of firms, notably Symbolics. (They were still stored-program computers operating on the von Neumann model, but there are some important differences between these and your standard run-of-the-mill modern RISC machine.) <SNIP> > ...but these are all different ways to arrive at the EXACT same > program. Well, the programs are the same from the point of view that they have the same functionality, yes. However, as I alluded to above, programs are not written in a vacuum. People have to maintain them, and the costs (especially time) associated with this process are not trivial. Given that, it may make some sense to choose a language or development methodology that results in programs that are easier to maintain. > So, this is the only thing I initially meant to say: many programming > techniques can be used by many programmers in many different ways to > arrive at a given result. It is a fallacy to dismiss any of them, even > though they may be out-of-fashion. And it is certainly a fallacy to write > a 500-page screed on the subject. There I disagree. Dismissing a language simply and only because it is out of fashion is certainly pointless. (I must admit, though, I'm a little confused as to why you're applying this to a criticism of C++.) However, there are significant differences between languages, and as my earlier arguments explain, these differences do matter. It *is* possible to express a preference for language X over language Y *and* to support this preference with solid technical reasons. However, for social and political reasons, people prefer to assume that all `high-level languages' are basically equivalent. I highly recommend that you check out Paul Graham's article, _Beating the Averages_: <http://www.paulgraham.com/avg.html>. It explains the logic behind this in a very clear fashion. Richard
