Who Says C is Simple? (2010) (opens in new tab)

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

There’s an assumption here that it would be impossible to design a language which would make these solutions available without being as error prone. Existing languages may be less capable than C, but that’s only because equally capable languages with less risk haven’t been created (Rust may be a solution, I'm not sure yet).

What exactly do you think can’t be done in a language that is less error-prone?

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

You’re part of the problem. It takes incredible hubris to say something like this, to think that it’s even possible for a human to do this.

Every nontrivial networking program written in C has security holes caused by memory management issues. If you’re going to claim that these errors are caused by bad programmers, then every C programmer is a bad programmer, because every C programmer has written bugs like this. If you’re claiming that bugs caused by C’s error-prone semantics are programmers abusing the language, then using C is equivalent to abusing C. The very best programmers writing C write bugs in C that they wouldn’t write in a language like Rust.

A system which depends on humans being perfect is bound to fail. There’s simply no way you can reasonably debate this fact.

Every other engineering field has redundancy, multiple layers of error checking that catch errors.

Until you see this as a problem then you’re a danger to any mission-critical product you work on. Not understanding that using C is a risk displays a shocking level of naiveté for a professional in this field. I’m not saying C is never a good choice. I write a lot of C myself, but I do so with the awareness that my code is not being checked adequately and that I have to take extreme measures to ensure that my code is well-validated.

In Rust, programmers are also "essentially free to do what they want", you just need to explicitly declare the parts of your code where you know better than the type system. The pertinent difference is Rust is memory-safe by default, and forces you to opt-in to unsafety and undefined behavior so that those pieces of code in particular can be more closely audited.

ISPC is cool, what it helps out with (writing the SIMD kernel) has never really been the bottleneck in my experience.

The data still has to be arranged optimally for the hardware in order for SIMD code to have any benefit (and at this point, writing SIMD code is straightforward). You also still need to be experienced with the capabilities of the hardware if you have any chance of writing good ISPC code (although this is true of C, as well as any shading language).

That said, using it to target SSE and AVX with the same code is attractive.

He means it was nearly-optimal on its original target, the PDP 11.

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.

The behavior is only well defined if the shift amount is strictly less than the width of the operand. If `size_t` is 32 bits, then shifting right by 32 bits is undefined.

I know of three different ways in which platforms implement shifts by greater than the word size.

Googled it. I think he means undefined behavior.

Reading an uninitialized variable is UB.

An uninitialized variable is UB, not implementation-defined. Thus, the compiler is free to treat the variable as though it doesn't have a value at all, or change it's value at will. It's not uncommon for the value of an uninitalized variable to change at strange places in the code that you wouldn't expect, because the compiler initially said "Variable x will be kept in register %eax", but then without a value to initialize it too, it just uses whatever happens to be in %eax at the time. For example, if they compiled this:

    return x == (1 && x);

Into this:

    movl $0, %eax
    andl $1, %eax
    cmpl %eax, %eax
    # Result in %eax

That will (obviously) return 1 every time, because we compare %eax and %eax. The reason for this is that the value of 'x' changes half-way through the computation (Because the computation is done in %eax, which is where 'x' is assumed to be). This is valid because 'x' is uninitalized, so it doesn't have a defined value.

It really only depends on if you define simple as "can only derive simple results."

And, you do realize that one of the simplest languages for compiler writers, lisp, doesn't have to move heaven/earth to make that calculation work out how you want it.

That header trick is a good one.

Ok, we'll put 2010 on it even though it is likely quite a bit older. An upper bound is better than nothing.

But 2010 may just have been when they stopped updating a version number. It looks like early 2000s material to me, based on nothing in particular. There's also this:

When I (George) started to write CIL I thought it was going to take two weeks. Exactly a year has passed since then and I am still fixing bugs in it

The CIL paper was published in 2002. Actually the whole project looks interesting—arguably more so than the currently posted page. It should have its own HN thread sometime. https://news.ycombinator.com/item?id=836735 was a while ago!

FYI the project is still active, https://github.com/cil-project/cil

That website for it hasn't been updated.

But get this, he said Java was HARD. Compared to C?