3 ms·

HN seems to think this is a dumb question but I disagree, and I think the people replying are misunderstanding what Aaron meant. You're correct, it's not phrase

HN seems to think this is a dumb question but I disagree, and I think the people replying are misunderstanding what Aaron meant. You're correct, it's not phrased very clearly. Aaron is getting at the idea that most code is effectively documentation about business logic, but a small amount of code is about making a platform-specific library or executable: this code is an implementation detail that's less important. If you look at the work involved in creating a C89 program that won't compile in modern C, only a tiny fraction of that work involves anything specific to C89. It's almost all about solving some real-world problem in C generally, with the details about C23 compliance being an implementation detail. Aaron seems to view porting a non-compliant C program as loosely equivalent to a security bugfix that changes some low-level details of certain implementations, but doesn't have much impact on the overall code. It might be annoying to fix your K&R declarations / etc, but it won't undo the hard work you did in parsing HTTP headers. An extreme but illustrative example of this idea: Donald Knuth still maintains TeX in WEB, which is a dialect of Pascal84. He hasn't moved to CWEB or a fancier modern language. I think he's correct: although Pascal84 is fussy and old-fashioned, it is also completely specified, fully stable, and uses a generic ALGOL syntax widely applicable to many modern languages. So the work of translating Pascal84 to modern C can be done with a computer (web2c): TeX's actual WEB source code serves as a complete specification that can easily be translated to a specific implementation. The WEB code is important, but the 1/2/2024 binary output from web2c > gcc is an implementation which is not very important.

steveklabnik 3y ago
I find this interpretation interesting, because I would agree with your sibling commentors, though I also agree with you that this isn't a dumb question. I think that you are answering "this is what Aaron wants to change," whereas others are answering "this is what the current principle means." That is, I think the principle is about compilers and their implementations vs code that users write. The full text from the Charter (covered in the post but not in your parents' question): > 1. Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. > > On the other hand, no one implementation was held up as the exemplar by which to define C: It is assumed that all existing implementations must change somewhat to conform to the Standard. This reads very clearly to me. However, > Aaron seems to view porting a non-compliant C program as loosely equivalent to a security bugfix that changes some low-level details of certain implementations, but doesn't have much impact on the overall code. It might be annoying to fix your K&R declarations / etc, but it won't undo the hard work you did in parsing HTTP headers. I do think you're getting at something here, which is the change Aaron is advocating for. I think it's a bit more subtle than that though: most people think of C as being 100% backwards compatible. But that's not really true. Famously, for example, C++ removed the gets function outright. I think Aaron isn't arguing that backwards compatibility should be thrown out entirely, but that the committee should build in a formal process for deprecation and eventual removal, and that that is better than the status quo. And that this power should be used wisely, not making changes that would be a burden on users for little gain. Just that it is okay to give users a little burden for big gains, rather than the current status of "basically no burden at all, but also improvements are difficult."
- nicklecompte 3y ago
  Quick comment, I just made a dumb mistake - I had read the post last night when it was posted and came back to the discussion in the comments. I forgot which parts where the charter vs. which parts were Aaron's comments! So I was summarizing Aaron's gist, and in particular his comments about wanting to avoid a Python 2/3 schism. This was a case of "big burden for big gains," the burden being so large that developers didn't want to harm their hard-earned business logic implementation because 2to3 missed an edge case in a dict comparison.
  - steveklabnik 3y ago
    Ah ha! It's all good, happens to the best of us.

steveklabnik 3y ago

I find this interpretation interesting, because I would agree with your sibling commentors, though I also agree with you that this isn't a dumb question. I think that you are answering "this is what Aaron wants to change," whereas others are answering "this is what the current principle means." That is, I think the principle is about compilers and their implementations vs code that users write. The full text from the Charter (covered in the post but not in your parents' question): > 1. Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. > > On the other hand, no one implementation was held up as the exemplar by which to define C: It is assumed that all existing implementations must change somewhat to conform to the Standard. This reads very clearly to me. However, > Aaron seems to view porting a non-compliant C program as loosely equivalent to a security bugfix that changes some low-level details of certain implementations, but doesn't have much impact on the overall code. It might be annoying to fix your K&R declarations / etc, but it won't undo the hard work you did in parsing HTTP headers. I do think you're getting at something here, which is the change Aaron is advocating for. I think it's a bit more subtle than that though: most people think of C as being 100% backwards compatible. But that's not really true. Famously, for example, C++ removed the gets function outright. I think Aaron isn't arguing that backwards compatibility should be thrown out entirely, but that the committee should build in a formal process for deprecation and eventual removal, and that that is better than the status quo. And that this power should be used wisely, not making changes that would be a burden on users for little gain. Just that it is okay to give users a little burden for big gains, rather than the current status of "basically no burden at all, but also improvements are difficult."

nicklecompte 3y ago
Quick comment, I just made a dumb mistake - I had read the post last night when it was posted and came back to the discussion in the comments. I forgot which parts where the charter vs. which parts were Aaron's comments! So I was summarizing Aaron's gist, and in particular his comments about wanting to avoid a Python 2/3 schism. This was a case of "big burden for big gains," the burden being so large that developers didn't want to harm their hard-earned business logic implementation because 2to3 missed an edge case in a dict comparison.
- steveklabnik 3y ago
  Ah ha! It's all good, happens to the best of us.