4 ms·

"C is unreliable" is the wrong way to conceptualize the problem. The argument against C is that it is inefficient. It's not that C programs are broken; it's tha

"C is unreliable" is the wrong way to conceptualize the problem. The argument against C is that it is inefficient. It's not that C programs are broken; it's that if you spend six hours writing C code your code will either do less, or be more broken, than what you would have produced had you spent those six hours writing, e.g., Perl or Javascript or Lisp instead. There's no reason why you can't write correct C code, or correct assembly code for that matter. The challenge is to do so without wasting a lot of time: Any amount of time that you spend consciously thinking about correct memory management or hand-optimizing your opcodes could probably be spent doing something more important, unless you are working on one of the few problems where that kind of optimization is actually the bottleneck. Of course, the flip side of having to think about every layer is that you get to see and potentially tweak every layer. It's nice to work on something transparent. It's nice to know what is going on down there among the sockets and the buffers. I've been thinking about practicing some C for just that reason, and it seems to be why the OP likes C. But I don't anticipate being very efficient when writing my own web server in C. My website will be better if I just install a big pile of other people's C and get on with designing or writing.

coliveira 15y ago
I think it is a mistake to think that you can't be efficient just because you're using C. It all depends on the abstractions you need to write your code. When writing code for the web, using Python is faster not just because of the language, but because there is so much ready to be used. Putting together 10 disparate libraries is much easier in Python/Ruby than it will ever be in C and C++. However, there is a lot of code that either doesn't require all these libraries or where the infrastructure is well established in C (think about kernel drivers for example). In that case, programming in C is not fundamentally harder than in Python, if you have enough experience.
- runako 15y ago
  Your point is valid, but you still miss the larger point you're replying to. Even without libraries, coding in C is going to require more lines of code than coding the same functionality in a higher-level language like Python. And lines of code correlate more or less evenly with time/effort/thought that goes into writing the code. Crucially, this linkage does not depend on whether there are libraries for what you're trying to do or experience level in the language. If coding a particular feature takes 1000 lines of code in C vs. 100 in Python, you'd have to assert that a programmer can write (and maintain) code 10x faster in C than Python. Since roughly the same amount of conceptual energy goes into each line of code, this is tantamount to the assertion that a programmer writing C can think through concepts 10x faster than when the same programmer is writing Python. There's a reason the field invented higher-level languages, and it doesn't entirely have to do with novice programmers.
  - jshowa 15y ago
    Less lines of code does not equal more efficient code. A single C statement has almost a 1:1 correlation between underlying assembly when compiled, where as a single statement in a high level language usually consists of several assembly instructions. I think the overarching point is experience with the language. I for one have seen and written incredibly long and convoluted programs in a high level language which was largely due to a weak understanding of the massive API's that come with it. And it would have taken roughly the same amount of time to read and understand what the API functions do and how to use them as it would in C. In the end, it's all relative and it's totally dependent on experience with the language and what you need for your application.
    - runako 15y ago
      This thread is about efficiency of the coding process, not the execution process. Nobody would argue that an arbitrary high-level language performs as well as the same code written C or hand-tuned assembly. The point of this discussion is that writing C or hand-tuned assembly takes more lines of code (and therefore thought) than writing the same code in a higher-level language. So with this definition of efficiency, less lines of code does equal more efficient code.
  - caf 15y ago
    I find that by far the most time/effort/thought goes into figuring out the overall structure of the algorithm I want to implement. Once I've sketched that out, translating it into lines of code is pretty much just typing.
- tptacek 15y ago
  Regardless of the abstractions you use, buttoning down a C runtime environment so you can be rely on the assumptions behind those abstractions is a chore. There's a pretty famous Mark Dowd Sendmail vulnerability that relies almost entirely on (only- incidentally- sent-) signal timing that I like to use as an example here, but rlimits are another. The problem is, your code will appear to work fine even if you don't complete the chore. It isn't until your program blows up that it'll even occur to you that there was more work to be done.
  - haberman 15y ago
    > There's a pretty famous Mark Dowd Sendmail vulnerability that relies almost entirely on (only- incidentally- sent-) signal timing that I like to use as an example here Would love to see a reference to this.
    - wglb 15y ago
      Try http://www.securityfocus.com/columnists/400 http://www.securityfocus.com/columnists/400
    - epo 15y ago
      The unwillingness to cut and paste "mark dowd sendmail" into google for something you would "love to see" is amusingly typical of lots of the comments on this thread. It's the first result BTW
      - tptacek 15y ago
        I like the second result better than the first, for what it's worth. ;) But come on. While let-me-Google-that-for-you requests are annoying, they are in toto less toxic to threads than comments like yours; at least the lame question generates a factual answer.
      - haberman 15y ago
        FWIW I Googled for "mark dowd signal timing sendmail vulnerability" which led me to http://lwn.net/Articles/176596/ http://lwn.net/Articles/176596/ which didn't look like the right vulnerability and gave me the impression that Mark Dowd does a lot of vulnerability research -- it seemed that finding the exact vulnerability tptacek was talking about might be more complicated than just asking him directly.
Retric 15y ago
There is no single best language for all problems out there. Let's say you have a working program that does something useful over a TCP/IP network but you have zero documentation for it's protocol and yet you still want to communicate with it. Trying to do this in Perl is actually harder than C assuming equivalent understanding of both languages. Yet, doing the same except it's a browser your talking to and suddenly Perl wins. The advantage of higher level languages lies not in the their ability to do everything well but their ability do handle huge projects that do a ridiculous number of things with minimal pain. PS: PG is in love with LISP in large part because he deals with problems well suited to the LISP domain. But, if he had been writing drivers he would have gone in another direction. The real lesson is if you wanted to write a great XML editor use something in the LISP family or something that's closely related to it not that LISP wins on all fronts.
generators 15y ago
I wish, linus get frustrated over kernel.org hacking that happened recently, and take 3 day vacation and roll out a badass webserver ecosystem the same way he did with git some years ago that changed whole vcs scene of the world. Its mind that matters, rest is just tools. #kidding
d0mine 15y ago
It's not that C programs are broken; it's that if you spend six hours writing C code your code will either do less, or be more broken, than what you would have produced had you spent those six hours writing, e.g., Perl or Javascript or Lisp instead. </quote> Python doesn't produce smaller programs compared to C http://plg.uwaterloo.ca/~migod/846/2011-Winter/projects/Simon-LanguageChoiceVCS-report.pdf http://plg.uwaterloo.ca/~migod/846/2011-Winter/projects/Simo...
- bermanoid 15y ago
  That article doesn't debunk the claim very effectively, IMO: of Bazaar, Git, Mercurial, SVN, and CVS, Python-dominated Mercurial is the smallest by a healthy margin (~50k SLoC), whereas the more C heavy CVS, Git, and SVN weigh in at ~2x, 5x, and 8x that amount. Sure, we throw in the almost 100%-Python Bazaar, at 200k, which CVS beats. But CVS vs. any of these other source control systems is not really a fair comparison, IMO, and it's still blown out of the water by Mercurial. I'm not saying that this proves that Python code is smaller (comparing source control systems to each other is completely unfair, since they differ so much in feature set, platform target, and code quality), but it certainly does not disprove it.

coliveira 15y ago

I think it is a mistake to think that you can't be efficient just because you're using C. It all depends on the abstractions you need to write your code. When writing code for the web, using Python is faster not just because of the language, but because there is so much ready to be used. Putting together 10 disparate libraries is much easier in Python/Ruby than it will ever be in C and C++. However, there is a lot of code that either doesn't require all these libraries or where the infrastructure is well established in C (think about kernel drivers for example). In that case, programming in C is not fundamentally harder than in Python, if you have enough experience.

runako 15y ago
Your point is valid, but you still miss the larger point you're replying to. Even without libraries, coding in C is going to require more lines of code than coding the same functionality in a higher-level language like Python. And lines of code correlate more or less evenly with time/effort/thought that goes into writing the code. Crucially, this linkage does not depend on whether there are libraries for what you're trying to do or experience level in the language. If coding a particular feature takes 1000 lines of code in C vs. 100 in Python, you'd have to assert that a programmer can write (and maintain) code 10x faster in C than Python. Since roughly the same amount of conceptual energy goes into each line of code, this is tantamount to the assertion that a programmer writing C can think through concepts 10x faster than when the same programmer is writing Python. There's a reason the field invented higher-level languages, and it doesn't entirely have to do with novice programmers.
- jshowa 15y ago
  Less lines of code does not equal more efficient code. A single C statement has almost a 1:1 correlation between underlying assembly when compiled, where as a single statement in a high level language usually consists of several assembly instructions. I think the overarching point is experience with the language. I for one have seen and written incredibly long and convoluted programs in a high level language which was largely due to a weak understanding of the massive API's that come with it. And it would have taken roughly the same amount of time to read and understand what the API functions do and how to use them as it would in C. In the end, it's all relative and it's totally dependent on experience with the language and what you need for your application.
  - runako 15y ago
    This thread is about efficiency of the coding process, not the execution process. Nobody would argue that an arbitrary high-level language performs as well as the same code written C or hand-tuned assembly. The point of this discussion is that writing C or hand-tuned assembly takes more lines of code (and therefore thought) than writing the same code in a higher-level language. So with this definition of efficiency, less lines of code does equal more efficient code.
- caf 15y ago
  I find that by far the most time/effort/thought goes into figuring out the overall structure of the algorithm I want to implement. Once I've sketched that out, translating it into lines of code is pretty much just typing.
tptacek 15y ago
Regardless of the abstractions you use, buttoning down a C runtime environment so you can be rely on the assumptions behind those abstractions is a chore. There's a pretty famous Mark Dowd Sendmail vulnerability that relies almost entirely on (only- incidentally- sent-) signal timing that I like to use as an example here, but rlimits are another. The problem is, your code will appear to work fine even if you don't complete the chore. It isn't until your program blows up that it'll even occur to you that there was more work to be done.
- haberman 15y ago
  > There's a pretty famous Mark Dowd Sendmail vulnerability that relies almost entirely on (only- incidentally- sent-) signal timing that I like to use as an example here Would love to see a reference to this.
  - wglb 15y ago
    Try http://www.securityfocus.com/columnists/400 http://www.securityfocus.com/columnists/400
  - epo 15y ago
    The unwillingness to cut and paste "mark dowd sendmail" into google for something you would "love to see" is amusingly typical of lots of the comments on this thread. It's the first result BTW
    - tptacek 15y ago
      I like the second result better than the first, for what it's worth. ;) But come on. While let-me-Google-that-for-you requests are annoying, they are in toto less toxic to threads than comments like yours; at least the lame question generates a factual answer.
    - haberman 15y ago
      FWIW I Googled for "mark dowd signal timing sendmail vulnerability" which led me to http://lwn.net/Articles/176596/ http://lwn.net/Articles/176596/ which didn't look like the right vulnerability and gave me the impression that Mark Dowd does a lot of vulnerability research -- it seemed that finding the exact vulnerability tptacek was talking about might be more complicated than just asking him directly.

Retric 15y ago

There is no single best language for all problems out there. Let's say you have a working program that does something useful over a TCP/IP network but you have zero documentation for it's protocol and yet you still want to communicate with it. Trying to do this in Perl is actually harder than C assuming equivalent understanding of both languages. Yet, doing the same except it's a browser your talking to and suddenly Perl wins. The advantage of higher level languages lies not in the their ability to do everything well but their ability do handle huge projects that do a ridiculous number of things with minimal pain. PS: PG is in love with LISP in large part because he deals with problems well suited to the LISP domain. But, if he had been writing drivers he would have gone in another direction. The real lesson is if you wanted to write a great XML editor use something in the LISP family or something that's closely related to it not that LISP wins on all fronts.

generators 15y ago

I wish, linus get frustrated over kernel.org hacking that happened recently, and take 3 day vacation and roll out a badass webserver ecosystem the same way he did with git some years ago that changed whole vcs scene of the world. Its mind that matters, rest is just tools. #kidding

d0mine 15y ago

It's not that C programs are broken; it's that if you spend six hours writing C code your code will either do less, or be more broken, than what you would have produced had you spent those six hours writing, e.g., Perl or Javascript or Lisp instead. </quote> Python doesn't produce smaller programs compared to C http://plg.uwaterloo.ca/~migod/846/2011-Winter/projects/Simon-LanguageChoiceVCS-report.pdf http://plg.uwaterloo.ca/~migod/846/2011-Winter/projects/Simo...

bermanoid 15y ago
That article doesn't debunk the claim very effectively, IMO: of Bazaar, Git, Mercurial, SVN, and CVS, Python-dominated Mercurial is the smallest by a healthy margin (~50k SLoC), whereas the more C heavy CVS, Git, and SVN weigh in at ~2x, 5x, and 8x that amount. Sure, we throw in the almost 100%-Python Bazaar, at 200k, which CVS beats. But CVS vs. any of these other source control systems is not really a fair comparison, IMO, and it's still blown out of the water by Mercurial. I'm not saying that this proves that Python code is smaller (comparing source control systems to each other is completely unfair, since they differ so much in feature set, platform target, and code quality), but it certainly does not disprove it.