7 ms·

Great article. My personal take on this is that C programs are so damn reliable because there is nothing under the hood, the building blocks are so simple and t

by 0x12 15y ago

Great article. My personal take on this is that C programs are so damn reliable because there is nothing under the hood, the building blocks are so simple and transparent that you can follow the thread of execution with minimal mental overhead. That means that when you lay out your program the most important parts (memory map and failure modes) are clearly visible. IF you are a good programmer. And that's the reason there is an obfuscated C contest, if a C programmer sets his or her mind on being deliberately hard to understand that same power can be used against any future reader of the code. Incompetence goes a long way towards explaining some of C's bad reputation. You can write bad code in any language, but none give you as much rope to hang yourself with as C (and of course, C++).

rohit89 15y ago
Agree. I'd also say that someone who is not a good programmer will find C quite unreliable. Bugs and issues popping up every now and then.
- coliveira 15y ago
  That is why in the "old days" C was used as a language for advanced courses in CS programs. It teaches you to think straight about your code. Nowadays people think it is easier just to write anything and catch exceptions later.
bad_user 15y ago
the building blocks are so simple and transparent that you can follow the thread of execution with minimal mental overhead. I do not agree. I've seen plenty of code that does weird things with pointers, like passing around a reference to a struct's member, then to retrieve the struct decrementing a value from the pointer + casting. Or XOR-ing pointers in doubly-linked lists for compression. And these are just simple examples. I've seen code where I was like "WTF was this guy thinking?". My biggest problem with C is that error handling is non-standard. In case of errors ome functions are returning 0. Some are returning -1. Some are returning > 0. Some are returning a value in an out parameter. Some functions are putting an error in errno. Some functions are resetting errno on each call. Some functions do not reset errno. Also, the Glibc documentation is so incomplete on so many important issues that it isn't even funny. Yes, kernel hackers can surely write good code after years of experience with buggy code that they had to debug. But for the rest of the code, written by mere mortals, I basically get a headache every time I have to take a peek at code somebody else wrote.
- 0x12 15y ago
  > I've seen plenty of code where I was like "WTF was this guy thinking?". Yes, that happens. But I've seen that in COBOL, Perl, Pascal, Java, PHP and in Ruby as well. > In case of errors (s)ome functions are returning 0. Some are returning -1. That's not a feature of the language.
  - bad_user 15y ago
    That's not a feature of the language. Well, yes, but it's kind of nice when you've got exceptions with stack traces attached. Some people don't like exceptions, but I do.
    - 0x12 15y ago
      gdb: where
    - ajross 15y ago
      It is indeed "kind of nice". But the question at hand is whether it's a requirement for writing reliable software. I tend to agree with the posts here that argue that it's not. It saves time for developers, it doesn't meaningfully improve the quality of the end product. Serious C projects tend to come up with this stuff on their own, often with better adapted implementations than the "plain stack trace" you see in higher level environments. Check out the kernel's use of BUG/WARN for a great example of how runtime stack introspection can work in C.
  - mattgreenrocks 15y ago
    No, but C could use more consistent error handling semantics, rather than conflating return values and error codes. Worse still: a combination of a return code and a global error code.
    - praptak 15y ago
      "Worse still: a combination of a return code and a global error code." That's not the worst that exists in C :-) Let me quote a dietlibc developer from http://www.koders.com/c/fid1639C203A2255EB1FA11DC6A68D74FEB2B530F8F.aspx#L14 http://www.koders.com/c/fid1639C203A2255EB1FA11DC6A68D74FEB2... /* Oh boy, this interface sucks so badly, there are no words for it. * Not one, not two, but _three_ error signalling methods! (*h_errnop * nonzero? return value nonzero? *RESULT zero?) The glibc goons * really outdid themselves with this one. */
deepinit_a 15y ago
>Incompetence goes a long way towards explaining some of C's bad reputation Incompetence is REASON for C bad reputation(if any).
trebor 15y ago
I think that in other languages such as Object Pascal it is easier to be a good programmer. I've seen horrible code written in OP, yes, but I think the language itself helps a programmer be better. For one thing there are fewer ways to kill yourself than even in C++, and yet there is little difference in speed between them. I think C is one of these "other languages" because "here be dragons". I watch a lot of people bang out C++ code as if it's totally safe, and fail. I see a lot of people hammer out C# code and say, "to hell with you, you don't even have .NET!" And so on. But today, when a programmer sits down and writes a C program they must sit and think out what they're doing and why—with no abstractions like OO to make an easy solution. There are so many ways to blow your head off in C without knowing you left the opportunity in the program, that it forces a competent programmer to think differently about how they code. And a newbie? Well, if they aren't scared stiff about blowing a hole in their system, they should be! ;D And C doesn't change often, unlike other languages. I'm no C programmer, but I've seen C code for years and translated it into whatever language I'm using at the time. I have tremendous respect for UNIX/Linux, and a great many C-powered programs. Thanks for your work on them, guys and gals.
- rbanffy 15y ago
  > But today, when a programmer sits down and writes a C program they must sit and think out what they're doing and why That's true for any programming language. Sadly, far too often, programmers are unable to afford taking the time needed to think about what they are doing or understanding what happens under the hood of the libraries they link against.
wladimir 15y ago
Incompetence goes a long way towards explaining some of C's bad reputation Not just incompetence. Also bad language choice (usually due to legacy). If programmers don't get enough time to properly test and review the code, which needs to be done very thoroughly in C, it's easy for even experienced developers to shoot themselves in the foot. C is very good (let's say irreplacable) for low-level hardware and OS code. This is code that needs to be verified and tested very well. On the other hand, using C for run-of-the-mill business projects or higher-level stuff on a tight deadline can be a very bad idea. It results in a lot of overhead for programmers to think about the details of error handling, buffer sizes, pointers, memory allocation/deallocation and so on, especially getting it right for every function. It is a recipe for screwups. In this case it is very useful to have garbage collection, bounds checking, built-in varlength string handling, and other "luxuries" that modern languages afford you.
- chalst 15y ago
  Right. C with Lua is a nice combination serving a wider range of projects without sacrificing C's approach to low-level correctness.
  - swah 15y ago
    I love Lua, but what stack would allow you to use it in a web project?
    - stonemetal 15y ago
      Mongrel2 has a Lua web framework called tir.
- 16s 15y ago
  Very true. When you have managers shouting "get it out" and over-promising to clients, then any language is a bad choice, but particularly powerful languages that require more careful thought and testing. I love C++ and use it regularly, but when I need to "get stuff out quickly" I'll use something like Python as I can be more reckless with it.
- 15y ago
pacala 15y ago
> the building blocks are so simple and transparent that you can follow the thread of execution with minimal mental overhead. The first fundamental purpose of any programming language is to provide abstraction via functions. This implies that following the thread of execution is never easy and the blocks are never simple. It's pretty much a wash, with special mention for languages in the Hindley-Milner family. The second fundamental purpose of any programming language is to provide specification abstraction via replaceable modules. This is where C fails. It is common practice in C culture to not specify interfaces in depth (we are all good programmers, aren't we?) and the implementation via manual virtual tables makes it painfully difficult to find the specific implementations in the code base.

by 0x12 15y ago

rohit89 15y ago

Agree. I'd also say that someone who is not a good programmer will find C quite unreliable. Bugs and issues popping up every now and then.

coliveira 15y ago
That is why in the "old days" C was used as a language for advanced courses in CS programs. It teaches you to think straight about your code. Nowadays people think it is easier just to write anything and catch exceptions later.

bad_user 15y ago

the building blocks are so simple and transparent that you can follow the thread of execution with minimal mental overhead. I do not agree. I've seen plenty of code that does weird things with pointers, like passing around a reference to a struct's member, then to retrieve the struct decrementing a value from the pointer + casting. Or XOR-ing pointers in doubly-linked lists for compression. And these are just simple examples. I've seen code where I was like "WTF was this guy thinking?". My biggest problem with C is that error handling is non-standard. In case of errors ome functions are returning 0. Some are returning -1. Some are returning > 0. Some are returning a value in an out parameter. Some functions are putting an error in errno. Some functions are resetting errno on each call. Some functions do not reset errno. Also, the Glibc documentation is so incomplete on so many important issues that it isn't even funny. Yes, kernel hackers can surely write good code after years of experience with buggy code that they had to debug. But for the rest of the code, written by mere mortals, I basically get a headache every time I have to take a peek at code somebody else wrote.

0x12 15y ago
> I've seen plenty of code where I was like "WTF was this guy thinking?". Yes, that happens. But I've seen that in COBOL, Perl, Pascal, Java, PHP and in Ruby as well. > In case of errors (s)ome functions are returning 0. Some are returning -1. That's not a feature of the language.
- bad_user 15y ago
  That's not a feature of the language. Well, yes, but it's kind of nice when you've got exceptions with stack traces attached. Some people don't like exceptions, but I do.
  - 0x12 15y ago
    gdb: where
  - ajross 15y ago
    It is indeed "kind of nice". But the question at hand is whether it's a requirement for writing reliable software. I tend to agree with the posts here that argue that it's not. It saves time for developers, it doesn't meaningfully improve the quality of the end product. Serious C projects tend to come up with this stuff on their own, often with better adapted implementations than the "plain stack trace" you see in higher level environments. Check out the kernel's use of BUG/WARN for a great example of how runtime stack introspection can work in C.
- mattgreenrocks 15y ago
  No, but C could use more consistent error handling semantics, rather than conflating return values and error codes. Worse still: a combination of a return code and a global error code.
  - praptak 15y ago
    "Worse still: a combination of a return code and a global error code." That's not the worst that exists in C :-) Let me quote a dietlibc developer from http://www.koders.com/c/fid1639C203A2255EB1FA11DC6A68D74FEB2B530F8F.aspx#L14 http://www.koders.com/c/fid1639C203A2255EB1FA11DC6A68D74FEB2... /* Oh boy, this interface sucks so badly, there are no words for it. * Not one, not two, but _three_ error signalling methods! (*h_errnop * nonzero? return value nonzero? *RESULT zero?) The glibc goons * really outdid themselves with this one. */

deepinit_a 15y ago

>Incompetence goes a long way towards explaining some of C's bad reputation Incompetence is REASON for C bad reputation(if any).

trebor 15y ago

I think that in other languages such as Object Pascal it is easier to be a good programmer. I've seen horrible code written in OP, yes, but I think the language itself helps a programmer be better. For one thing there are fewer ways to kill yourself than even in C++, and yet there is little difference in speed between them. I think C is one of these "other languages" because "here be dragons". I watch a lot of people bang out C++ code as if it's totally safe, and fail. I see a lot of people hammer out C# code and say, "to hell with you, you don't even have .NET!" And so on. But today, when a programmer sits down and writes a C program they must sit and think out what they're doing and why—with no abstractions like OO to make an easy solution. There are so many ways to blow your head off in C without knowing you left the opportunity in the program, that it forces a competent programmer to think differently about how they code. And a newbie? Well, if they aren't scared stiff about blowing a hole in their system, they should be! ;D And C doesn't change often, unlike other languages. I'm no C programmer, but I've seen C code for years and translated it into whatever language I'm using at the time. I have tremendous respect for UNIX/Linux, and a great many C-powered programs. Thanks for your work on them, guys and gals.

rbanffy 15y ago
> But today, when a programmer sits down and writes a C program they must sit and think out what they're doing and why That's true for any programming language. Sadly, far too often, programmers are unable to afford taking the time needed to think about what they are doing or understanding what happens under the hood of the libraries they link against.

wladimir 15y ago

Incompetence goes a long way towards explaining some of C's bad reputation Not just incompetence. Also bad language choice (usually due to legacy). If programmers don't get enough time to properly test and review the code, which needs to be done very thoroughly in C, it's easy for even experienced developers to shoot themselves in the foot. C is very good (let's say irreplacable) for low-level hardware and OS code. This is code that needs to be verified and tested very well. On the other hand, using C for run-of-the-mill business projects or higher-level stuff on a tight deadline can be a very bad idea. It results in a lot of overhead for programmers to think about the details of error handling, buffer sizes, pointers, memory allocation/deallocation and so on, especially getting it right for every function. It is a recipe for screwups. In this case it is very useful to have garbage collection, bounds checking, built-in varlength string handling, and other "luxuries" that modern languages afford you.

chalst 15y ago
Right. C with Lua is a nice combination serving a wider range of projects without sacrificing C's approach to low-level correctness.
- swah 15y ago
  I love Lua, but what stack would allow you to use it in a web project?
  - stonemetal 15y ago
    Mongrel2 has a Lua web framework called tir.
16s 15y ago
Very true. When you have managers shouting "get it out" and over-promising to clients, then any language is a bad choice, but particularly powerful languages that require more careful thought and testing. I love C++ and use it regularly, but when I need to "get stuff out quickly" I'll use something like Python as I can be more reckless with it.
15y ago

pacala 15y ago

> the building blocks are so simple and transparent that you can follow the thread of execution with minimal mental overhead. The first fundamental purpose of any programming language is to provide abstraction via functions. This implies that following the thread of execution is never easy and the blocks are never simple. It's pretty much a wash, with special mention for languages in the Hindley-Milner family. The second fundamental purpose of any programming language is to provide specification abstraction via replaceable modules. This is where C fails. It is common practice in C culture to not specify interfaces in depth (we are all good programmers, aren't we?) and the implementation via manual virtual tables makes it painfully difficult to find the specific implementations in the code base.