12 ms·

Taking C Seriously

127 points by tomh 15y ago

zeteo 15y ago
>C was developed between 1969 and 1973, making it nearly 40 years old [...] C ha[s] already made an exceptionally good start on a century-long reign In all fairness, development continued past 1973. Most C programmers today would have some trouble even reading the code from the 1978 first edition of K&R; and the void* pointer, that the author refers to later in the article, was a part of ANSI C (~1990).
- DiabloD3 15y ago
  Development on C hasn't stopped. C1x is coming soon (probably 2012 or 13), and has a lot of interesting enhancements including bounds checking.
  - cygx 15y ago
    According to Herb Sutter's obit for Dennis Ritchie ( http://herbsutter.com/2011/10/12/dennis-ritchie/ http://herbsutter.com/2011/10/12/dennis-ritchie/ ), C1x already passed its final ballot, so all that's missing is an official announcement. It would be nice to know if there are any changes from the April draft, though...
  - comex 15y ago
    Bounds checking is just for library functions, and there isn't something like automatic array bounds checking, right? Still, whoa - > #define cbrt(X) _Generic((X), long double: cbrtl, \ > default: cbrt, \ > float: cbrtf)(X) Fun stuff.
- LukeShu 15y ago
  Definitely. Occasionally I'll run across some code in an old program (eg: Emacs), and be utterly unable to read it, because it's an older dialect of C (that I'm surprised most compilers still accept). I'll have to dig out a copy of K&R first edition just to read the code.
jonathansizz 15y ago
Those TIOBE numbers (linked to in the article) are quite interesting. As well as C refusing to go away, there's a noticeable surge for C#, Objective-C and Lua, and a substantial erosion in the popularity of trendy languages like Python and Ruby.
- malkia 15y ago
  Lua is small and embeddable. You can run multiple independent instance of it in the same process. The lua table is a very useful data structure. Then you have luajit - also a small, easy to embed solution, that approaches standard "C" written code, and it's main weakness, from what I understood (Mike Pall had a post about it) is it's garbage collector. On top of that, ffi bindings make "C" calls extremely fast, when the jit is active, and not very bad when the interpretter runs (but slower). And the lua/luajit license allows you to embed it in your application, without the need to share source code. Mike Pall is working on ppc, arm versions (and I think there might be already ppc jit). Not last to forget - awesome community (comp.lang.lua).
  - strait 15y ago
    Using LuaJIT with minimal FFI C code to optimize, seems to be the best way forward in maximizing both performance and maintainability. What would be really interesting is to see someone highlight specific cases where this approach ultimately fails to measure up in performance with using pure C. I would think that the LuaJIT approach would be tens of times more maintainable for a sufficiently large application, so it's really imperative here that we ask 'Why not?'
    - malkia 15y ago
      You can always find cases where it would fail. And that's ok. For what it's doing, and what it allows it's simply unbelievable (at least to me) how it succeeds in doing it (I understand very little of compilers, and little of interpretters). One area which is not easy translatable is OpenMP (www.openmp.org), inlined assembly, and SSE packed floats. But that's okay, and even then there is probably a better alternative - a language more suited to such tasks, instead of "C" - OpenCL (www.khronos.org) or DirectCompute. But for general coding, it's very very good.
derleth 15y ago
The problem is, nothing in this article even begins to address the actual criticism people have of C, instead saying that it's possible to write good C code and that Java is a memory hog. The first is true, the second is debatable, both as to whether it's the case and whether it matters. For example, read this: http://www.jwz.org/doc/gc.html http://www.jwz.org/doc/gc.html > In a large application, a good garbage collector is more efficient than malloc/free. My point isn't necessarily to disagree with the article, but to point out that the article has practically nothing to disagree with. It has no substance.
- pshc 15y ago
  Yeah, the article is just praise of the minimalist C style I guess. To elaborate, the actual problem with C is that you have to deal with ownership semantics manually. In languages with things like uniqueness typing or automatic reference counting that problem goes away. Common to all these languages and all GCed languages is the need for memory management--clearing references or maps or just generally indicating (with the language's particular idioms) its lifetime. Sometimes in a GCed language all that ownership gets untangled for you for free, but this may actually be a maintainability hazard. A trivial change might suddenly start retaining objects forever. See Haskell, where a seeming perfect program may suddenly gain space leaks upon mere removal of, say, a print statement. Some GC implementations might be faster in practice if they can move around memory and improve cache locality and reduce fragmentation. On the other hand, some introduce long collection pauses (often an issue with C# on XNA for example), and the default malloc() on many systems is very slow and tends to fragment. But "sufficiently smart" GCs avoid these issues. Ideally the solution is a hybrid approach: for data with obvious lifetime (bound to a scope or a certain area of the program execution) you want to actually show those intentions in the code or types. For short-lived objects that you're working with or object graphs you want garbage collection. This is what generational GC simulates, but I always find it asinine to fiddle around with references (possibly having to null out) and deal with non-deterministic deallocation when the lifetime is clear. Sigh. One day.
  - cageface 15y ago
    Every time I think about writing anything substantial in C I think about manual memory management and error handling via error codes and I quickly shelve the idea.
DiabloD3 15y ago
I'm confused. Did C stop being taken seriously at some point? C is the only language that you can truly get things done without having to fight the language every step of the way. I can't say the same of... well, any other language I've used in the past 5 years.
- garenp 15y ago
  Perhaps a better title would have been "Don't take C for granted."
- Blunt 15y ago
  agreed. and if you do any sort of embedded work, you must know C and C++. If history is any predictor of the future, chips will continue to get smaller and the "embedded" development world, I think, will proliforate and demand coders to know C and C++ at least for the next several years until fancy tools/compilers argue things like Java and C# code bloat doesn't matter because a 4Gig embedded system will be the norm... ahem..
  - gte910h 15y ago
    There is a huge swing against C++ in the embedded world since 2007 or so. ABI issues, etc. Not saying it disappeared, but there is now a bifurcation between C and C++ programmers.
- bonch 15y ago
  > I'm confused. Did C stop being taken seriously at some point? On social news sites, bashing C has been trendy for years. Bashing C++ was also trendy, but that has diminished somewhat since the new standard, and I suspect the same will happen for C. Basically, if something seems new and shiny, people like it more.
garyhalverson 15y ago
Whoa, that page is hard on the eyes....I didn't get far in that article, but I think C has continued to live on as well as a foundation that has spawned other great languages. I don't see it (or variations of it) going away anytime soon.
cageface 15y ago
Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away.
- lgeek 15y ago
  >I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. How about the Linux kernel?
  - Andys 15y ago
    And all the BSDs.
- pvarangot 15y ago
  The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used. And this came without thinking about it... surely in two more minutes or by going to ohloh I could fire a couple more large bodies of non-trivial low-level C code at you.
  - burgerbrain 15y ago
    "Subversion" And don't forget Git! ;)
  - comex 15y ago
    > The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used. Please pick gcc to mention or, indeed, any other C program ever written, before libbfd ;)
jeffreymcmanus 15y ago
Saying that "TIOBE rankings are at least the best system we currently have" for gauging uptake of a programming language is like saying that astrology is the best system we have for predicting the future.
- thisrod 15y ago
  It would be interesting - but a lot of work - to add "time to modify" and "time to debug" metrics. Each task would come with a modification, and an error to make in implementing the original task. You'd recruit undergraduates, who hadn't used the language before. Some would be given the original program to modify, others the broken version to fix. You'd measure how long they took to do it. This way, language communities that gamed the machine benchmarks would pay a price on the human ones.
  - derleth 15y ago
    Yes, because untrained undergraduates are the programming workforce in every industry, especially aerospace and medical device makers.
    - Roboprog 15y ago
      Hello, "Enterprise"? Beam me up, there's no intelligent life here.

127 points by tomh 15y ago

zeteo 15y ago

>C was developed between 1969 and 1973, making it nearly 40 years old [...] C ha[s] already made an exceptionally good start on a century-long reign In all fairness, development continued past 1973. Most C programmers today would have some trouble even reading the code from the 1978 first edition of K&R; and the void* pointer, that the author refers to later in the article, was a part of ANSI C (~1990).

DiabloD3 15y ago
Development on C hasn't stopped. C1x is coming soon (probably 2012 or 13), and has a lot of interesting enhancements including bounds checking.
- cygx 15y ago
  According to Herb Sutter's obit for Dennis Ritchie ( http://herbsutter.com/2011/10/12/dennis-ritchie/ http://herbsutter.com/2011/10/12/dennis-ritchie/ ), C1x already passed its final ballot, so all that's missing is an official announcement. It would be nice to know if there are any changes from the April draft, though...
- comex 15y ago
  Bounds checking is just for library functions, and there isn't something like automatic array bounds checking, right? Still, whoa - > #define cbrt(X) _Generic((X), long double: cbrtl, \ > default: cbrt, \ > float: cbrtf)(X) Fun stuff.
LukeShu 15y ago
Definitely. Occasionally I'll run across some code in an old program (eg: Emacs), and be utterly unable to read it, because it's an older dialect of C (that I'm surprised most compilers still accept). I'll have to dig out a copy of K&R first edition just to read the code.

jonathansizz 15y ago

Those TIOBE numbers (linked to in the article) are quite interesting. As well as C refusing to go away, there's a noticeable surge for C#, Objective-C and Lua, and a substantial erosion in the popularity of trendy languages like Python and Ruby.

malkia 15y ago
Lua is small and embeddable. You can run multiple independent instance of it in the same process. The lua table is a very useful data structure. Then you have luajit - also a small, easy to embed solution, that approaches standard "C" written code, and it's main weakness, from what I understood (Mike Pall had a post about it) is it's garbage collector. On top of that, ffi bindings make "C" calls extremely fast, when the jit is active, and not very bad when the interpretter runs (but slower). And the lua/luajit license allows you to embed it in your application, without the need to share source code. Mike Pall is working on ppc, arm versions (and I think there might be already ppc jit). Not last to forget - awesome community (comp.lang.lua).
- strait 15y ago
  Using LuaJIT with minimal FFI C code to optimize, seems to be the best way forward in maximizing both performance and maintainability. What would be really interesting is to see someone highlight specific cases where this approach ultimately fails to measure up in performance with using pure C. I would think that the LuaJIT approach would be tens of times more maintainable for a sufficiently large application, so it's really imperative here that we ask 'Why not?'
  - malkia 15y ago
    You can always find cases where it would fail. And that's ok. For what it's doing, and what it allows it's simply unbelievable (at least to me) how it succeeds in doing it (I understand very little of compilers, and little of interpretters). One area which is not easy translatable is OpenMP (www.openmp.org), inlined assembly, and SSE packed floats. But that's okay, and even then there is probably a better alternative - a language more suited to such tasks, instead of "C" - OpenCL (www.khronos.org) or DirectCompute. But for general coding, it's very very good.

derleth 15y ago

The problem is, nothing in this article even begins to address the actual criticism people have of C, instead saying that it's possible to write good C code and that Java is a memory hog. The first is true, the second is debatable, both as to whether it's the case and whether it matters. For example, read this: http://www.jwz.org/doc/gc.html http://www.jwz.org/doc/gc.html > In a large application, a good garbage collector is more efficient than malloc/free. My point isn't necessarily to disagree with the article, but to point out that the article has practically nothing to disagree with. It has no substance.

pshc 15y ago
Yeah, the article is just praise of the minimalist C style I guess. To elaborate, the actual problem with C is that you have to deal with ownership semantics manually. In languages with things like uniqueness typing or automatic reference counting that problem goes away. Common to all these languages and all GCed languages is the need for memory management--clearing references or maps or just generally indicating (with the language's particular idioms) its lifetime. Sometimes in a GCed language all that ownership gets untangled for you for free, but this may actually be a maintainability hazard. A trivial change might suddenly start retaining objects forever. See Haskell, where a seeming perfect program may suddenly gain space leaks upon mere removal of, say, a print statement. Some GC implementations might be faster in practice if they can move around memory and improve cache locality and reduce fragmentation. On the other hand, some introduce long collection pauses (often an issue with C# on XNA for example), and the default malloc() on many systems is very slow and tends to fragment. But "sufficiently smart" GCs avoid these issues. Ideally the solution is a hybrid approach: for data with obvious lifetime (bound to a scope or a certain area of the program execution) you want to actually show those intentions in the code or types. For short-lived objects that you're working with or object graphs you want garbage collection. This is what generational GC simulates, but I always find it asinine to fiddle around with references (possibly having to null out) and deal with non-deterministic deallocation when the lifetime is clear. Sigh. One day.
- cageface 15y ago
  Every time I think about writing anything substantial in C I think about manual memory management and error handling via error codes and I quickly shelve the idea.

DiabloD3 15y ago

I'm confused. Did C stop being taken seriously at some point? C is the only language that you can truly get things done without having to fight the language every step of the way. I can't say the same of... well, any other language I've used in the past 5 years.

garenp 15y ago
Perhaps a better title would have been "Don't take C for granted."
Blunt 15y ago
agreed. and if you do any sort of embedded work, you must know C and C++. If history is any predictor of the future, chips will continue to get smaller and the "embedded" development world, I think, will proliforate and demand coders to know C and C++ at least for the next several years until fancy tools/compilers argue things like Java and C# code bloat doesn't matter because a 4Gig embedded system will be the norm... ahem..
- gte910h 15y ago
  There is a huge swing against C++ in the embedded world since 2007 or so. ABI issues, etc. Not saying it disappeared, but there is now a bifurcation between C and C++ programmers.
bonch 15y ago
> I'm confused. Did C stop being taken seriously at some point? On social news sites, bashing C has been trendy for years. Bashing C++ was also trendy, but that has diminished somewhat since the new standard, and I suspect the same will happen for C. Basically, if something seems new and shiny, people like it more.

garyhalverson 15y ago

Whoa, that page is hard on the eyes....I didn't get far in that article, but I think C has continued to live on as well as a foundation that has spawned other great languages. I don't see it (or variations of it) going away anytime soon.

cageface 15y ago

Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away.

lgeek 15y ago
>I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. How about the Linux kernel?
- Andys 15y ago
  And all the BSDs.
pvarangot 15y ago
The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used. And this came without thinking about it... surely in two more minutes or by going to ohloh I could fire a couple more large bodies of non-trivial low-level C code at you.
- burgerbrain 15y ago
  "Subversion" And don't forget Git! ;)
- comex 15y ago
  > The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used. Please pick gcc to mention or, indeed, any other C program ever written, before libbfd ;)

jeffreymcmanus 15y ago

Saying that "TIOBE rankings are at least the best system we currently have" for gauging uptake of a programming language is like saying that astrology is the best system we have for predicting the future.

thisrod 15y ago
It would be interesting - but a lot of work - to add "time to modify" and "time to debug" metrics. Each task would come with a modification, and an error to make in implementing the original task. You'd recruit undergraduates, who hadn't used the language before. Some would be given the original program to modify, others the broken version to fix. You'd measure how long they took to do it. This way, language communities that gamed the machine benchmarks would pay a price on the human ones.
- derleth 15y ago
  Yes, because untrained undergraduates are the programming workforce in every industry, especially aerospace and medical device makers.
  - Roboprog 15y ago
    Hello, "Enterprise"? Beam me up, there's no intelligent life here.