Given that the original article that this replies to starts with "It [C] works well for what it is, and what it is is a relatively simple layer of indirection a

Given that the original article that this replies to starts with "It [C] works well for what it is, and what it is is a relatively simple layer of indirection atop assembly." I'm not sure "bashing" is an exactly accurate. Given that this reply also starts with "To begin with, I agree with most of the things Eevee wrote", I'm not sure "Let's stop X" is the right title to use, even if it matches the theme of the original article. The reply itself is... a decent alternative viewpoint, to a few of the points made, but I don't think it quite matches the title. And now some counter-counter points: > What’s Wrong with Integer Division? This is the wrong question. The right question is: What's wrong with integer division if and only if both arguments are integers, and ambiguously conflated with floating point division in syntax? I'm sufficiently used to it to not find it a big deal, but that's a poor argument for it's merits in new languages. Nobody thinks integer division shouldn't be an option. > However, the behavior of integer division is very useful. I would argue that in most cases, one expects it to behave just as it does. I've seen even professionals trip up over the semantics of this just regularly enough to be annoying - you read float a = x/y; and assume terrible things about x and y, things that were perhaps even once true. Even if you really did intend to round, you probably assumed unsigned 'round down towards zero' semantics and will have a bug to contend with when x<0 and end up rounding up towards zero. Personally, I haven't found it that difficult to adjust to languages that have a separate integer division operator, or languages requiring an explicit rounding operation, despite a long history of only using languages with C's semantics before them. > Unfortunately, Eevee seems to fall for the extremely common “++ is equivalent with += 1” fallacy. You can see it’s a fallacious statement when, in the end, even the author herself admits that there are things that can’t be implemented in terms of “+= 1“; for instance, incrementing non-random-access iterators. That Eevee herself points out that "++" is not always "+= 1" makes it quite clear that she hasn't "fallen" for any such fallacy. The point is that even including other unmentioned (ab)uses of overloading, there is always a way to rewrite things in an equivalent manner in terms of "+=", "-=", or custom functions - combined with either the abuse of the comma operator, or multiple statements. For the mentioned case of iteration - plenty of other languages have a separate, named function for iteration, even if they allow "++" and "--" to be overloaded. The only real point of debate here is how often the "++" and "--" operators produce concise code, versus how often they produce write-only code.