5 ms·

The Continuing Relevance of C

22 points by tjr 19y ago

astine 19y ago
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 19y ago
  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 http://gcc.gnu.org/c99status.html), for example.
  - tjr 19y ago
    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 19y ago
      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 19y ago
You can write operating systems and have low-level control over the hardware in Lisp too.
- procrastitron 19y ago
  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 19y ago
    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 19y ago
better title might be "unreasonable effectiveness of c"

22 points by tjr 19y ago

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 19y ago
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 http://gcc.gnu.org/c99status.html), for example.
- tjr 19y ago
  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 19y ago
    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 19y ago

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

procrastitron 19y ago
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 19y ago
  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 19y ago

better title might be "unreasonable effectiveness of c"