You are mistaken.

From the article:

> There was no such thing

> as a general-purpose program that was both

> portable across a variety of hardware

> and also efficient enough

> to compete with custom code written for just that hardware.

And that is true. You couldn't run the Burroughs 5000 Master Control Program on a PDP-11, as far as I know, at all, and certainly not efficiently.

Ten years before the birth of C was about 1963. ALGOL-60 lacked a lot of things to compete with C, which is why people in the 1970s switched to C. ALGOL-68 required garbage collection, which wouldn't be reasonably efficient until the invention of generational GC in 1983, and still poses problems for real-time software like device drivers, which is why people usually use C or C++ instead of ALGOL-68 or Java for them.

For some notes on what ALGOL-60 lacked in comparison with C, I recommend reading "Why Pascal is Not My Favorite Programming Language", from 1981: http://www.lysator.liu.se/c/bwk-on-pascal.html. Most of the objections to Pascal also apply to its ancestor ALGOL-60, although ALGOL was intended for real work, not just teaching. ALGOL-60 did have a sort of equivalent of pointer parameters, namely Jensen's Device, but it was dramatically less efficient than pointers. I think (I wasn't around in the 1960s) that ALGOL implementations from different vendors had different nonportable extensions to work around the lack of pointers, and of course the same thing happened with Pascal later.

Burroughs was an immensely innovative company, and all of today's popular programming languages except C, C++, and PHP (JS, Java, C#, Python, Perl, Ruby, Objective-C) owe an enormous debt to Smalltalk, which draws much of its inspiration from the B5000. I do not deprecate the importance of Burroughs! They did indeed write the first OS in a high-level language. But C achieved what they could not.

The measure of C's achievement is that in 2011, on a multiprocessor 32-bit machine with the x86 instruction set and a gigabyte of RAM, I still occasionally run programs originally written in 1981 for a single-processor 16-bit PDP-11 with 64k of RAM per program, and they're still efficient; and I still constantly run software written in the late 1980s, such as parts of the X server and much of GNU coreutils, on single-processor 32-bit 68000s, and much of the optimization done then is still valid. (Though not all of it!)

It was C that first made it practical for people on different architectures to share code on a large scale, for code to outlive the architectures it was written for without suffering a dramatic slowdown, and for people to switch architectures, as Sun did from the 68000-family Sun3 to the SPARC, as everyone eventually did to the i386 we use today, and as we now are to AMD64.

The SNOBOL Implementation Language, SIL, achieved the same thing in 1966 — but only for one program, the SNOBOL interpreter! TeX was another early endeavor in this direction; concurrent with the early evolution of C, Knuth wrote WEB, a literate programming language which compiled into Pascal, in order to get Pascal's portability without suffering from its drawbacks. Among other things, WEB used a single humongous Pascal packed array of char for all of its strings; and that was what Knuth wrote TeX and Metafont in. C's twin sibling Ratfor was a third similar approach, compiling C-like constructs into Fortran rather than assembly. I don't know of anything else that predated the popularity of C.

In effect, C enabled both the birth of the SPARC and its death.

Today we stand at or near the end of the C era, for three reasons.

First, a vast amount of software is being written for which efficiency is of minimal concern. So C's drawbacks — its proneness to subtle bugs, its difficulty of debugging, its limited facilities for abstraction — drive people to more modern languages.

Second, dynamic recompilation has reached a level of performance where it's feasible to use it to emulate another processor architecture at acceptable speeds. Transmeta was one of the most interesting explorations of this concept, but Apple's transition strategy from the PowerPC to the i386 probably had more field-deployed units, and I think some of the currently popular OS virtualization approaches work this way as well. (And of course there's Valgrind, although calling its speed "acceptable" is a bit of a stretch.) So now there are viable alternatives to the recompilation approach.

Third, both computer architectures and compiler optimizations have changed so much in the 40 or so years since C was invented that C is stretched rather thin. Compilers exploiting undefined behavior makes it increasingly difficult to write working code in C, or to recompile old C programs. And, although people largely program GPUs in C, you cannot simply recompile Emacs for your Fermi or your Spartan-II to get it to run faster or use less energy. The C abstract model of computation is an increasingly poor fit to modern hardware, despite the pressure it has exerted on hardware designs for the last 25 years.

๛