6 ms·

The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at

The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one

cycomanic 4y ago
I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.
- waiseristy 4y ago
  I would bet that the vast majority of undefined behavior encountered is when interacting with the standard library though. Which isn’t really the languages fault (But, I also totally concede that a language is inseparable from its std lib in reality)
  - deleted 4y ago
    [deleted]
- Espressosaurus 4y ago
  The number of people I have interviewed that have used C and C++ for years and can't tell me what undefined behavior is is too damned high. I've had one or two, and only one of them could give me a coherent answer of what the compiler is allowed to do if it runs across it. In my experience it's only the language lawyers who actually know what to look out for, and there are damned few of them. Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field.
  - waiseristy 4y ago
    We’ve been really spoiled by modern compilers and operating systems which let you get away with large swaths of undefined behavior. You typically don’t know what is hidden from you
  - simplotek 4y ago
    > Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field. Is it really that fundamental if you can setup your project to throw warnings/errors, and even use static code analysis tools to flag those? I'd argue that it's far worse to work on a project that's not setup to detect those errors than to expect that sort of issue to be handled at the recruiting level.
  - scotty79 4y ago
    > Which is stupid since undefined and unspecified behaviors are hugely important to ... Why are they though? Should they be?
- mpweiher 4y ago
  Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. And it is not forbidden by the standard, though discouraged.
  - the_why_of_y 4y ago
    Following your argument: Use-after-free or double-free is undefined behavior. Therefore a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
    - mpweiher 4y ago
      > Following your argument: It's not an argument, it's an observation and statement of fact. > Use-after-free or double-free is undefined behavior. Yes. > Therefore Why therefore? > a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory. If you think so. It certainly doesn't follow from what I wrote. My point is that if you use a pointer after you freed the memory, you get whatever is in memory that the pointer points at on the machine the code is running on. That is not a "weird and bizarre" implication, it is a plain and straightforward implication given how C is implemented on real machines. It is (obviously, I hope!) outside of the scope of the C standard to say what will be at that memory location at that point, and therefore it is UB. And it being UB, "what you get" may also, for example, be a segfault because the library/OS have decided to unmap that memory. And again, that is also not "weird and bizarre", but perfectly straightforward. ¯\_(ツ)_/¯
    - scotty79 4y ago
      > Use-after-free or double-free is undefined behavior. It's an error even if it's undetectable by the compiler. I understand that nomenclature from few decades ago makes a distinction but nowadays we just call such thing an error.
  - cycomanic 4y ago
mlindner 4y ago
Write a multithreaded program guaranteed to have no data races in C and tell me that C is simple. C _looks_ simple, deceivingly so. As soon as you need to deal with a large project in a corporate environment on a code base aged in double digit years you don't think it's simple anymore. C is incredibly complex, unmanageably so.
- waiseristy 4y ago
  I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. But, I’m not arguing with you. I honestly think that any corporate codebase after double digit years (and seven figure LoC) turns into a completely unmanageable mess. If it isn’t, it’s because of the team culture and pure rigor. Not the language
  - mlindner 4y ago
    > I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. I don't limit my statement to just C. The topic was C however so I mentioned C.
    - waiseristy 4y ago
      I am limiting it to just C though, because I’m responding to an article about the sticking power of C. I’ve worked in a lot of massive and unmaintainable codebases, and I’ve always had the most fun untangling C ones. I don’t know exactly why, but I suspect it’s because at their core they are always plain ol’ simple C.
    - simplotek 4y ago
      > I don't limit my statement to just C. The topic was C however so I mentioned C. Your comment reads like a red herring though. You're not actually trying to argue that C makes thing easier or hard. Your red herring only means that hard problems affecting all languages aren't magically turned into non-issues in C. You can still write a C program that uses threading and is as safe as any other language and end up being a far simpler project, but that means nothing because the subject is still hard. And what would that actually say about C, let alone refute?
sacnoradhq 4y ago
I don't know what you mean by "simple". Little kids don't learn C, they learn Python. C has near universal portability. It's everywhere. That's the most important property.
- sfpotter 4y ago
  I learned C as a little kid, and then learned Python a bit later. C always seemed a lot simpler to me than Python.
- bitwize 4y ago
  And LLVM is nearly everywhere C is; if you have LLVM, you have Rust. I first learned C when I was 11 years old; admittedly I learned BASIC and Z80 assembly before then, and I'm an outlier.
- waiseristy 4y ago
  > The entire language & toolchain is understandable at a fairly core level without too much effort. That’s what I mean by simple. And that’s the reason why it also has universal portability. Cause it’s simple

cycomanic 4y ago

I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.

waiseristy 4y ago
I would bet that the vast majority of undefined behavior encountered is when interacting with the standard library though. Which isn’t really the languages fault (But, I also totally concede that a language is inseparable from its std lib in reality)
- deleted 4y ago
  [deleted]
Espressosaurus 4y ago
The number of people I have interviewed that have used C and C++ for years and can't tell me what undefined behavior is is too damned high. I've had one or two, and only one of them could give me a coherent answer of what the compiler is allowed to do if it runs across it. In my experience it's only the language lawyers who actually know what to look out for, and there are damned few of them. Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field.
- waiseristy 4y ago
  We’ve been really spoiled by modern compilers and operating systems which let you get away with large swaths of undefined behavior. You typically don’t know what is hidden from you
- simplotek 4y ago
  > Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field. Is it really that fundamental if you can setup your project to throw warnings/errors, and even use static code analysis tools to flag those? I'd argue that it's far worse to work on a project that's not setup to detect those errors than to expect that sort of issue to be handled at the recruiting level.
- scotty79 4y ago
  > Which is stupid since undefined and unspecified behaviors are hugely important to ... Why are they though? Should they be?
mpweiher 4y ago
Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. And it is not forbidden by the standard, though discouraged.
- the_why_of_y 4y ago
  Following your argument: Use-after-free or double-free is undefined behavior. Therefore a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
  - mpweiher 4y ago
    > Following your argument: It's not an argument, it's an observation and statement of fact. > Use-after-free or double-free is undefined behavior. Yes. > Therefore Why therefore? > a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory. If you think so. It certainly doesn't follow from what I wrote. My point is that if you use a pointer after you freed the memory, you get whatever is in memory that the pointer points at on the machine the code is running on. That is not a "weird and bizarre" implication, it is a plain and straightforward implication given how C is implemented on real machines. It is (obviously, I hope!) outside of the scope of the C standard to say what will be at that memory location at that point, and therefore it is UB. And it being UB, "what you get" may also, for example, be a segfault because the library/OS have decided to unmap that memory. And again, that is also not "weird and bizarre", but perfectly straightforward. ¯\_(ツ)_/¯
  - scotty79 4y ago
    > Use-after-free or double-free is undefined behavior. It's an error even if it's undetectable by the compiler. I understand that nomenclature from few decades ago makes a distinction but nowadays we just call such thing an error.
- cycomanic 4y ago

mlindner 4y ago

Write a multithreaded program guaranteed to have no data races in C and tell me that C is simple. C _looks_ simple, deceivingly so. As soon as you need to deal with a large project in a corporate environment on a code base aged in double digit years you don't think it's simple anymore. C is incredibly complex, unmanageably so.

waiseristy 4y ago
I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. But, I’m not arguing with you. I honestly think that any corporate codebase after double digit years (and seven figure LoC) turns into a completely unmanageable mess. If it isn’t, it’s because of the team culture and pure rigor. Not the language
- mlindner 4y ago
  > I would be interested to see someone write a program in any language (other than ones specifically designed to combat this, rust…) using threading and guarantee it to be data/race safe. I don't limit my statement to just C. The topic was C however so I mentioned C.
  - waiseristy 4y ago
    I am limiting it to just C though, because I’m responding to an article about the sticking power of C. I’ve worked in a lot of massive and unmaintainable codebases, and I’ve always had the most fun untangling C ones. I don’t know exactly why, but I suspect it’s because at their core they are always plain ol’ simple C.
  - simplotek 4y ago
    > I don't limit my statement to just C. The topic was C however so I mentioned C. Your comment reads like a red herring though. You're not actually trying to argue that C makes thing easier or hard. Your red herring only means that hard problems affecting all languages aren't magically turned into non-issues in C. You can still write a C program that uses threading and is as safe as any other language and end up being a far simpler project, but that means nothing because the subject is still hard. And what would that actually say about C, let alone refute?

sacnoradhq 4y ago

I don't know what you mean by "simple". Little kids don't learn C, they learn Python. C has near universal portability. It's everywhere. That's the most important property.

sfpotter 4y ago
I learned C as a little kid, and then learned Python a bit later. C always seemed a lot simpler to me than Python.
bitwize 4y ago
And LLVM is nearly everywhere C is; if you have LLVM, you have Rust. I first learned C when I was 11 years old; admittedly I learned BASIC and Z80 assembly before then, and I'm an outlier.
waiseristy 4y ago
> The entire language & toolchain is understandable at a fairly core level without too much effort. That’s what I mean by simple. And that’s the reason why it also has universal portability. Cause it’s simple