7 ms·

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 w

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.

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.