6 ms·

Is it possible to need C and not know it, or if I need it will I know it? Because I can't think of anything I'd use it for. You guys speak of it and other highe

Is it possible to need C and not know it, or if I need it will I know it? Because I can't think of anything I'd use it for. You guys speak of it and other higher level languages as if you use them interchangably for the same tasks.

tptacek 14y ago
I use Ruby for things that deal with the web, for utility programs, and (most often) for software I'm not going to need to support long term, such as clients for bizarro network protocols I encounter on penetration tests. I used to use C for everything else; I'd reach for Go first now, but I still love C. One way to think about C vs. (say) Python is that it's like the relationship between an FPGA and an ASIC: you prototype in a high level language and you write C when you really know exactly what you need your program to do. C is not a great exploratory programming environment, but it is excellent when you have a specific plan.
- lelandbatey 14y ago
  It'd like to thank you for that description. The first analogy that came to mind was play-doh vs marble, but that's a rather blunt one that connotes all sorts of negative things that I don't really mean. Yours description is spot on!
- yuushi 14y ago
  And this is what I don't really understand. Python or Ruby are excellent in the domain you talk about, but I would always, always reach for C++ over C if given the choice. The C++ standard library for me alone makes this such a simple choice. A lot of C code to me just looks horribly ugly these days - stuff like: int compare(const void *a, const void *b) { return *((int*)a) < *((int*)b); } Yuck.
  - tptacek 14y ago
    On the other hand, the mechanism by which that code works is simple to understand and keep in your head at all times, and isn't inelegant. I find that very valuable.
    - yuushi 14y ago
      Except it has absolutely no type safety whatsoever. With modern-style C++, you can do the same thing in exactly 1 line: std::sort(begin(array), end(array), [](int a, int b) { return a < b; }); Versus: qsort(array, MAX_VAL, sizeof(int), compare); With compare as defined before. I mean, sure, it's just sorting and it's a tiny example, but to me it shows a lot about why I prefer C++ over C: typesafety, readability, reduced possibility of buffer overflows, reduced possibility of segfaults based on incorrect element access, speed thanks to code inlining vs function pointers...
      - temujin 14y ago
        Yes, std::sort is better than qsort on simple types, but that's an isolated case. I'm currently working on a major "C++" project where literally the only C++ dependency is std::sort right now.
      - tptacek 14y ago
        I've coded in C since 1993, shipped commercial systems C code from 1996 through ~2004 (with an 3-year C++ interlude in there), and continued to write C code on projects from then today. In that time, the number of bugs I've dealt with due to the lack of type safety on a void* is: zero. Lest you think I'm being cavalier about this, I've been writing professional Ruby since ~2006, and have since then been routinely aggravated by bugs that would have been mitigated by type safety. I buy type safety. But it's a continuum of value, not a core principle of development. In idiomatic C code, void* is a way of dropping in and out of static typing, usually to pass values of arbitrary types to a generic container library or through a callback. The use of void* doesn't surrender type safety throughout the program. Idiomatic C code casts a specific type to void* at the call site of the function that handles generic types, and casts it back to that specific type the moment that library hands it back. Of the arguments C++ devotees marshall against C, I find this one among the fudliest.
        yuushi 14y ago
        I guess we'll just have to agree to disagree then. Perhaps you are a far more conscientious programmer than many out there; the number of buffer overflow exploits would suggest so. C++ doesn't make you immune to such things, but it does give you the tools to make such things less likely to occur. Further, I like compiler-enforced type safety. For when C was created, utilization of void* was a brilliant idea. Language design has moved on since then, and as much as many people really hate template-based C++ code, I honestly welcome it in comparison.
  - krichman 14y ago
    That's strawman C. We could just as easily write hideous C++, Ruby, Python, etc. code and complain about that. Edit: By this I mean; if you want to prefer the C++ libraries, that's fine, but please don't claim C is inherently ugly.
    - yuushi 14y ago
      How is it strawman C? If you want to use qsort, which anyone who has used C for any amount of time has, it's something you've written many times.
      - krichman 14y ago
        I think I misinterpreted your argument as being about the syntax instead of the type system. I would actually prefer the option of a stricter type system in C.

tptacek 14y ago

I use Ruby for things that deal with the web, for utility programs, and (most often) for software I'm not going to need to support long term, such as clients for bizarro network protocols I encounter on penetration tests. I used to use C for everything else; I'd reach for Go first now, but I still love C. One way to think about C vs. (say) Python is that it's like the relationship between an FPGA and an ASIC: you prototype in a high level language and you write C when you really know exactly what you need your program to do. C is not a great exploratory programming environment, but it is excellent when you have a specific plan.

lelandbatey 14y ago
It'd like to thank you for that description. The first analogy that came to mind was play-doh vs marble, but that's a rather blunt one that connotes all sorts of negative things that I don't really mean. Yours description is spot on!
yuushi 14y ago
And this is what I don't really understand. Python or Ruby are excellent in the domain you talk about, but I would always, always reach for C++ over C if given the choice. The C++ standard library for me alone makes this such a simple choice. A lot of C code to me just looks horribly ugly these days - stuff like: int compare(const void *a, const void *b) { return *((int*)a) < *((int*)b); } Yuck.
- tptacek 14y ago
  On the other hand, the mechanism by which that code works is simple to understand and keep in your head at all times, and isn't inelegant. I find that very valuable.
  - yuushi 14y ago
    Except it has absolutely no type safety whatsoever. With modern-style C++, you can do the same thing in exactly 1 line: std::sort(begin(array), end(array), [](int a, int b) { return a < b; }); Versus: qsort(array, MAX_VAL, sizeof(int), compare); With compare as defined before. I mean, sure, it's just sorting and it's a tiny example, but to me it shows a lot about why I prefer C++ over C: typesafety, readability, reduced possibility of buffer overflows, reduced possibility of segfaults based on incorrect element access, speed thanks to code inlining vs function pointers...
    - temujin 14y ago
      Yes, std::sort is better than qsort on simple types, but that's an isolated case. I'm currently working on a major "C++" project where literally the only C++ dependency is std::sort right now.
    - tptacek 14y ago
      I've coded in C since 1993, shipped commercial systems C code from 1996 through ~2004 (with an 3-year C++ interlude in there), and continued to write C code on projects from then today. In that time, the number of bugs I've dealt with due to the lack of type safety on a void* is: zero. Lest you think I'm being cavalier about this, I've been writing professional Ruby since ~2006, and have since then been routinely aggravated by bugs that would have been mitigated by type safety. I buy type safety. But it's a continuum of value, not a core principle of development. In idiomatic C code, void* is a way of dropping in and out of static typing, usually to pass values of arbitrary types to a generic container library or through a callback. The use of void* doesn't surrender type safety throughout the program. Idiomatic C code casts a specific type to void* at the call site of the function that handles generic types, and casts it back to that specific type the moment that library hands it back. Of the arguments C++ devotees marshall against C, I find this one among the fudliest.
      - yuushi 14y ago
        I guess we'll just have to agree to disagree then. Perhaps you are a far more conscientious programmer than many out there; the number of buffer overflow exploits would suggest so. C++ doesn't make you immune to such things, but it does give you the tools to make such things less likely to occur. Further, I like compiler-enforced type safety. For when C was created, utilization of void* was a brilliant idea. Language design has moved on since then, and as much as many people really hate template-based C++ code, I honestly welcome it in comparison.
- krichman 14y ago
  That's strawman C. We could just as easily write hideous C++, Ruby, Python, etc. code and complain about that. Edit: By this I mean; if you want to prefer the C++ libraries, that's fine, but please don't claim C is inherently ugly.
  - yuushi 14y ago
    How is it strawman C? If you want to use qsort, which anyone who has used C for any amount of time has, it's something you've written many times.
    - krichman 14y ago
      I think I misinterpreted your argument as being about the syntax instead of the type system. I would actually prefer the option of a stricter type system in C.