4 ms·
On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the sam
by Kranar 3y ago
On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here.
- PH95VuimJjqBqy 3y agothat's how you get companies to stop upgrading and eventually end up sitting on a 20 y/o version of C++. 2nd and 3rd order thinking is a thing.
- Kranar 3y agoIf a company won't update because it really needs to depend on whether one bool compares greater to another then by all means they can stick to using 20 year old version of C++. Other companies with modern engineering disciplines that don't write hacky code like that can benefit from a sane and sensible compiler instead of being dragged down.
- PH95VuimJjqBqy 3y agoIf you can't understand how the expense of doing that may be onerous on a business then you shouldn't be let anywhere near decision making.
- Kranar 3y agoToo late for that, I am in a decision making position at a quant firm with very strict engineering standards and I absolutely stand by my decision that businesses that write code that compares booleans together like that should not be in a position to hold back other businesses that don't. They can continue using 20 year old compilers and quit making the language worse for the rest of us who have put in the effort and cost of writing modern software.
- PH95VuimJjqBqy 3y agoIt's always easy to make a decision when you're not the one paying the cost for it, or don't imagine you will be. In fact, one of the red flags for decision makers is the inability to understand the above tenet.
- Kranar 3y agoI agree, asking everyone else to pay the cost of writing error prone code because they refuse to adapt but yet feel entitled to use new compilers is a big red flag and poor technical decision making that offloads the cost on the rest of the community. I'm glad we managed to get that out of the way. Companies that wish to stick with their existing and deprecated coding standards can stick to their existing and deprecated compilers, allowing those of is who wish to have safe and modern tools the freedom to make progress without their baggage holding us back.
- PH95VuimJjqBqy 3y agooh snap guys, do you see what he did there in his parley? The way he took my point and pretended I was saying something else and that I really agreed with him. That technique so got me that he won! This is most definitely the paragon that should be helping us decide which large swathe of people to fuck over.
- saghm 3y ago> On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here. My point is that "it's okay to turn something into a compiler error" is vague and I don't know where the line is actually drawn. I don't think the boundary between acceptable and unacceptable breakage is obvious, which is why I explicitly gave an example that I knew for sure was outside it. I don't think the idea that reasonable people might disagree about what level of breakage is acceptable particularly radical, so I think it's worth not immediately assuming I'm participating in bad faith.
- Kranar 3y agoThis is the sort of ideological thinking that holds back progress and it's something people have complained about in particular with the C++ standardization process. You always have these purists who think that because a solution doesn't solve the problem for every single use case, that we can't put forth solutions that solve the problem for 90% of use cases. The entire article that Herb Sutter is writing is really a push to fix the 90% of safety problems in C++ without coming up with an ideologically pure solution that tries to solve all of C++'s safety problems. If someone puts forth a proposal that a fairly awkward and easily misunderstood and error prone expression like "bool > bool" should produce a compiler error, and your response is that if we do that, we may as well just change all of C++'s syntax so that one could rename rustc to g++ and it just works, then you are participating in bad faith as opposed to presenting a sensible argument that reasonable people can actually discuss and make some kind of meaningful progress.
- saghm 3y ago> If someone puts forth a proposal that a fairly awkward and easily misunderstood and error prone expression like "bool > bool" should produce a compiler error, and your response is that if we do that, we may as well just change all of C++'s syntax so that one could rename rustc to g++ and it just work My first comment gave and example followed by saying "I don't think that's what anyone here is talking about", and my most recent response reiterated that I considered my example as explicitly being outside the boundary of what anyone would consider acceptable. It feels like you're going through great lengths to try to present it as something I actually recommended when I've been quite clear that I don't think it's anywhere close to reasonable. I've been quite clear that I'm not proposing anything; on the contrary, I'm _asking_ about how to decide whether something is a breaking change that's worth it or not because I'm not at all an expert in C++ and I don't pretend to be. The only "ideological thinking that holds back progress" due from "purists" going on here is your insistence that I should be disqualified from asking questions because I happened to try to use a hypothetical example that you didn't like.