Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN

[Richard Miller <9fans@hamnavoe.com>]

> Best way to save developer time is to program in a HLL and not
> worry about bit fiddling. C is not a HLL.

C was created as a language to do bit fiddling in - a tool for writing
assembly language a bit more productively than doing it by hand.  The
original Unix C compiler was a tool for writing PDP11 assembly
language.  Later when the prospect of Unix on other architectures
began to emerge, the 7th edition Unix "portable C compiler" was a
family of tools for writing assembly language on different machines.

C was designed by and used by systems programmers who were intimately
familiar with their machine's instruction set, and the code generation
was so simple and straightforward that to such programmers it would be
obvious what instructions would correspond to a given bit of C. The
low-level directness of C made it easy to write efficient code, so
there was no need for the compiler itself to try to do clever
"optimisations".

Such a language was and still is just what is needed for writing
device drivers and the lowest layers of OS kernels where things like
memory layout and instruction ordering are important.  It's not such a
good match for writing the more abstract upper layers of an OS, and
even less so for applications programming.  I think it's unfortunate
that C ended up being so widely (mis)used for applications
programming, and by applications programmers who have never learned
assembly language, causing pressure for compilers to be obfuscated
with semantics-perverting "optimisations" and, in an attempt to
compensate for this, the language to be defaced with "features" like
volatile and __attribute__ and whatnot.

I think inferno got it about right: write the kernel in C, and
the applications in a high level language (limbo).