2 ms·
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 thin
by 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 agoQuick 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 agoAh ha! It's all good, happens to the best of us.