Who Says C is Simple? (2010)

It was decidedly not nearly-optimal a few years later on microprocessors like 8080, z80, 6502, etc., which were highly register starved, 8-bit rather than 16-bit, non-orthogonal instructions and registers, etc.

As for "not to use C for time-critical applications", both then and now people sometimes write critical inner loops in assembly, it's just less common now because compilers are much more sophisticated.

But C was indeed used on "time-critical applications", aside perhaps from inner loops, back in the 70s, certainly on PDP 11s, and sometimes on less ideal microprocessors.

> why would, say, all those NES programmers write all that assembly?

Several reasons. First and foremost, things like that were highly RAM starved by the standards of the day. The PDP-11/70 had 64k of instructions and a separate 64k of data per process, with a total amount of RAM of up to something like a megabyte.

The NES had 2k RAM onboard -- although cartridges could extend that -- and the register starved 6502.

Another big reason is that, in every era, games are always pushing the limits of the hardware, and developers were typically quite willing to code in assembly if they believed it would give them a 20% edge in speed or decrease in space.

But also there was a mythos (that hasn't completely disappeared) that assembly would yield vastly more than 10%-20% speed increase over high level languages of the day, including C, so for most developers, they never even considered anything but assembler.

It also was not uncommon at the time for many of those game programmers to only know assembler, and not any other language except perhaps Basic.

The availability of C compilers for various platforms was not so universal then as it is now, especially on non-Unix systems, and the non-Unix C compilers, when available, were not necessarily at the same level of quality as the Unix C compilers.

Last but not least, C had not yet taken the world by storm, and a lot of those developers and companies had never even heard of C, and the ones that had heard of it were pretty dubious, more often than not.

Specially since some of us were exposed to languages (Modula-2, Turbo Pascal) that were more feature rich than C while allowing similar performance levels on the same systems.

Programs written in C and C++ may have issues because the languages assume the programmer knows what they are doing. This assumption leads to some great solutions to hard problems because the programmer is essentially free to do what they want.

Of course, this assumption, as with most others, doesn't always hold true. This doesn't mean there is a problem with the language. The problem is with the programmer.

If you're going to write something like "return ({goto L; 0;}) && ({L: 5;});", no language is going to save you.

C and C++ are still used today, in part, because modern languages try to restrict the programmer. Rather than assume the programmer knows what they are doing, they assume the programmer is stupid and needs help to cross the road. By assuming stupidity, the restrictions modern languages put in place prohibit certain solutions and as such C and C++ will remain the go-to systems languages.

We do not need new languages. What we need is programmers who won't abuse the languages we already have.

It's a code fragment; it's not in a function body. The way I read it, it was simply to document the type of x. 'x' could be a global for all we know.

Prior to Turbo Pascal there was UCSD Pascal, which was extremely popular but not high performance.

But the whole idea that any high level language could be even close to competitive with assembly was a very radical idea considered laughable by the mainstream, for many years, which I think is the underlying idea here.

Another language worth mentioning is Bliss, a pioneering high level systems programming language roughly contemporary with early C, with high levels of efficiency and optimization, and was famous in some circles but not with the mainstream.

As I recall, that one eventually dropped by the wayside because it was too closely tied to DEC architectures. It may or may not have been ported to others, but it did not have (relatively) easy portability as a feature anyway, unlike the Johnson C compiler, which is often claimed to be the first such.

I wasn't a Turbo Pascal user, but wasn't it, too, tied to the one platform?

Wirth's languages after Pascal, I dunno; everyone heard of them but they were never that widely adopted. I guess I'm unclear on why.