6 ms·

The question I have is whether committee members are sufficiently representative of programmers in the trenches, and whether committee members are sufficiently

by tytso 11y ago

The question I have is whether committee members are sufficiently representative of programmers in the trenches, and whether committee members are sufficiently informed about the impact of their saying, "great, sounds awesome".

DannyBee 11y ago
Sometimes yes, sometimes no. But in some sense, it doesn't matter. They are the ones defining C. If people don't like it, they should create Cgood or whatever. This has been tried before, and it has never caught on. I'm not worried. If the programmers in the trenches really hate it so much, C will eventually die off in favor of something better :)
- aidenn0 11y ago
  To be fair Cgood doesn't catch on because no compiler vendors implement it, and the C standards committe is at least somewhat beholden to the compiler vendors because if the compiler vendors en-masse decided not to implement their standard, then the standard isn't worth the paper it's printed on.
  - DannyBee 11y ago
    This is entirely true, but at the same time: Compiler vendors are people, and in fact, if you don't like that set of people, there are plenty of vendors who have forks :) IE if you don't like gcc 4.8's treatment of behavior, it's not like there aren't 50 different arm forks from different vendors you can use, with or without their SOC's. Yet none of these vendors have apparently heard enough from customers that they have made what are pretty simple patches.
    - WalterBright 11y ago
      It's really, really hard to sell someone on a non-standard implementation of a popular language like C. For example, I've had customers beg me to add an extension to C. I implement it, and present it to them. They refuse to use it - because then their code would be dependent on a non-Standard feature. The solution (for me, anyway) was to create an entirely new language. The changes that nobody wanted in C (not because they were bad, but because they were non-Standard) found plenty of traction and users in D.
      - aidenn0 11y ago
        This is a very good observation. The exception is strict subsets though; there are plenty of people using MISRA, and that's an extremely restrictive subset of C. Similarly this would be a dialect of C that is identical in behavior for conforming C programs, rather than C with some extensions.
      - DannyBee 11y ago
        Sure, but that's also a fine outcome - everyone decides language X sucks and moves to language Y. If that language Y guarantees things nicer than language X, you've solved the problem :-)
- xg15 11y ago
  > This is entirely true, but at the same time: Compiler vendors are people, and in fact, if you don't like that set of people, there are plenty of vendors who have forks :) With all due respect, but that sounds a bit like "if you don't like this particular law, you're always free to try a coup/revolution/run your own country". I don't know much about the situation in standardized C, but I would argue that the point of standards is to reduce fragmentation and discuss language features in a way that all implementation can benefit from it. Demanding that you break the standard if you don't like a part of it kind of defeats that point, I think. A different (and IMO more sensible) approach is shown by the WHATWG developing HTML5. Even though input primarily comes from browser vendors (which would be the equivalent to compiler vendors here), there is a rather strict requirement that new features must break a little as possible existing usage of HTML and should never introduce new security vulnerabilities. (Where those requirements collide, the second one takes precedence). This is done by extensive studies of how HTML is used "in the wild".
  - DannyBee 11y ago
    "With all due respect, but that sounds a bit like "if you don't like this particular law, you're always free to try a coup/revolution/run your own country". " IMHO, it's closer to, if you don't like SF, you can move to any of the cities around it :) "Demanding that you break the standard if you don't like a part of it kind of defeats that point, I think." Which, humorously, is precisely what Anton wants in some cases. "A different (and IMO more sensible) approach is shown by the WHATWG developing HTML5. Even though input primarily comes from browser vendors (which would be the equivalent to compiler vendors here), there is a rather strict requirement that new features must break a little as possible existing usage of HTML and should never introduce new security vulnerabilities. (Where those requirements collide, the second one takes precedence). This is done by extensive studies of how HTML is used "in the wild"." This is in actuality, how most of C/C++ is developed. With a bit more formality due to it being an international standard. The truth is this code has pretty much never had defined behavior.

by tytso 11y ago

DannyBee 11y ago

Sometimes yes, sometimes no. But in some sense, it doesn't matter. They are the ones defining C. If people don't like it, they should create Cgood or whatever. This has been tried before, and it has never caught on. I'm not worried. If the programmers in the trenches really hate it so much, C will eventually die off in favor of something better :)

aidenn0 11y ago
To be fair Cgood doesn't catch on because no compiler vendors implement it, and the C standards committe is at least somewhat beholden to the compiler vendors because if the compiler vendors en-masse decided not to implement their standard, then the standard isn't worth the paper it's printed on.
- DannyBee 11y ago
  This is entirely true, but at the same time: Compiler vendors are people, and in fact, if you don't like that set of people, there are plenty of vendors who have forks :) IE if you don't like gcc 4.8's treatment of behavior, it's not like there aren't 50 different arm forks from different vendors you can use, with or without their SOC's. Yet none of these vendors have apparently heard enough from customers that they have made what are pretty simple patches.
  - WalterBright 11y ago
    It's really, really hard to sell someone on a non-standard implementation of a popular language like C. For example, I've had customers beg me to add an extension to C. I implement it, and present it to them. They refuse to use it - because then their code would be dependent on a non-Standard feature. The solution (for me, anyway) was to create an entirely new language. The changes that nobody wanted in C (not because they were bad, but because they were non-Standard) found plenty of traction and users in D.
    - aidenn0 11y ago
      This is a very good observation. The exception is strict subsets though; there are plenty of people using MISRA, and that's an extremely restrictive subset of C. Similarly this would be a dialect of C that is identical in behavior for conforming C programs, rather than C with some extensions.
    - DannyBee 11y ago
      Sure, but that's also a fine outcome - everyone decides language X sucks and moves to language Y. If that language Y guarantees things nicer than language X, you've solved the problem :-)
xg15 11y ago
> This is entirely true, but at the same time: Compiler vendors are people, and in fact, if you don't like that set of people, there are plenty of vendors who have forks :) With all due respect, but that sounds a bit like "if you don't like this particular law, you're always free to try a coup/revolution/run your own country". I don't know much about the situation in standardized C, but I would argue that the point of standards is to reduce fragmentation and discuss language features in a way that all implementation can benefit from it. Demanding that you break the standard if you don't like a part of it kind of defeats that point, I think. A different (and IMO more sensible) approach is shown by the WHATWG developing HTML5. Even though input primarily comes from browser vendors (which would be the equivalent to compiler vendors here), there is a rather strict requirement that new features must break a little as possible existing usage of HTML and should never introduce new security vulnerabilities. (Where those requirements collide, the second one takes precedence). This is done by extensive studies of how HTML is used "in the wild".
- DannyBee 11y ago
  "With all due respect, but that sounds a bit like "if you don't like this particular law, you're always free to try a coup/revolution/run your own country". " IMHO, it's closer to, if you don't like SF, you can move to any of the cities around it :) "Demanding that you break the standard if you don't like a part of it kind of defeats that point, I think." Which, humorously, is precisely what Anton wants in some cases. "A different (and IMO more sensible) approach is shown by the WHATWG developing HTML5. Even though input primarily comes from browser vendors (which would be the equivalent to compiler vendors here), there is a rather strict requirement that new features must break a little as possible existing usage of HTML and should never introduce new security vulnerabilities. (Where those requirements collide, the second one takes precedence). This is done by extensive studies of how HTML is used "in the wild"." This is in actuality, how most of C/C++ is developed. With a bit more formality due to it being an international standard. The truth is this code has pretty much never had defined behavior.