

The Continuing Relevance of C - tjr
http://www.cs.uiowa.edu/~rjhansen/c_relevance.html

======
astine
I concur with nearly everything he says except one: that Unix could have been
written in assembler as much as it could have been written in C. Unix was
originally written in assembler but they changed it for a reason. Unlike
assembler, C is portable.

C's low levelness not only gives the programmer a needed degree of precision
control, but also makes the language easy to implement elsewhere. There is a
version of gcc for the x86, and for the ppc, and the sparc and the arm, and to
port programs between them, often all you need to do is is set the right
compiler flags and use preprocessor commands wherever necessary. C is
highlevel enough to keep you from having to write architecture specific code,
but low level enough to allow you to do so.

~~~
gcv
I also agree with the article, but I must take exception with your assertion
that C is easy to implement. The ANSI C99 spec came out almost ten years ago,
and most major compilers still barely support it. GCC has a depressing number
of C99 features flagged as broken (<http://gcc.gnu.org/c99status.html>), for
example.

~~~
tjr
GCC has been making progress on C99... part of their problem has been, how
best to implement C99 features that were already part of GCC prior to C99, but
with different syntax?

For Microsoft, I read somewhere several years ago that they had no plans to
support C99, because they viewed C as inconsequential compared to C++. I have
not kept up with Microsoft C compiler development at all, so I don't know if
this is still true or not.

~~~
0x44
It does make sense for Microsoft to deprecate continued development of C, when
one considers their push toward .NET and getting various languages implemented
on it.

------
lisper
You can write operating systems and have low-level control over the hardware
in Lisp too.

~~~
procrastitron
Indeed, the difference here isn't the capabilities of the language, but rather
the quality of support the tool chain offers for the task. None of the tool
chains that I know of offer decent support for building operating systems, but
the C portion of the gnu tool chain offers the least sucky support for it.

A sign of the flaws in the author's argument is that C++ clearly offers just
as much control over the hardware as C. However, an order of magnitude more
OSes are written in C than C++. Anyone who's tried to write one in C++ knows
why; trying to bend the tool chain to support bare-hardware is a daunting
task.

~~~
rjh
Hi. I'm the original author.

As far as I can see, the reason why C++ has never really taken off for OS
design is both historical and technical. When I was working at a major
telecommunications firm, our C++ coding manual dated back to 1985--any
features that weren't stable in C++ as of '85 simply could not be used in
modern code in '99.

Large scale engineering shops are very, very slow to change. Right there's one
major reason why C++ hasn't caught on in the OS level.

The other major reason has to do with the way C++ implements inheritance. The
fragile base class problem is a killer for OS level design. If you want to
dodge that, then your best bet is to write your kernel in the C subset of C++
and eschew C++'s object model.

Finally, there's the issue of portability. C++ didn't even standardize until
1998. Compilers lagged substantially behind the Standard until about 2003.
Using sophisticated C++ features like the STL tended to lock you into one
particular compiler vendor. That's not something an OS designer especially
wants.

I know of several engineering shops that write their code in C, precisely to
get around vendor quality-of-implementation issues in their C++ compilers.
However, despite the fact they write their code in C, they make compiling it
with a C++ compiler part of their software engineering practice, in order to
take advantage of the C++'s compiler's much stronger type checking.

I have yet to see the tool chain be an issue in C++ development. That's not to
say it can't be an issue or that you haven't seen it--only to say I've never
seen it become a substantial issue.

------
anupamkapoor
better title might be "unreasonable effectiveness of c"

