You're saying "well okay it could negatively impact business".
I'm replying "that doesn't mean anything, and sometimes negatively impacting business is very good".
It's not enough to just say something. You need to explain WHY. So what? Who cares? If you don't answer that, I'm sorry, you don't have an argument and anyone wise would choose to not listen to you.
It's bad for business. Okay let's assume that's true. So what? What's the big idea? What's the cost versus the benefit?
This is an oxymoron.
Tell me, how many Venezuelans abroad were able to vote? How many were kept out of the country because the borders were closed? How many were threatened or intimidated into voting for Maduro? How many votes were cast using false ID? How many were confused by the ballot which had 13 options to vote for Maduro? How many polling stations were closed at the last minute?
Yes, you can frame this as "bad for business". Contrary to what all the armchair economists online will say, you should never just do what's good for business. If we did we would be seeing crimes against humanity. And we do, just not here.
Its always a balancing act. Often what's good for business isn't good, and what's bad for business isn't bad. You need more robust reasoning than that. Because if that's all you're relying on to form your opinions, you have no substance.
To be clear this is also inflammatory rhetoric disguised as what some would have you think is ‘common sense’.
Size has nothing to do with it. Just because a company is large doesn't mean it needs to start making poor business decisions.
> corporate death penalty
That's a bit extreme. If you want to be seen as objective, this kind of inflammatory rhetoric will only work against you.
If you're asking why people use pre-increment by default instead of post-increment, it's mostly historical. The early C compilers on resource-constrained platforms such as early DOS were not good at optimization; on those, pre-increment would be reliably translated to a simple ADD or INC, whereas code for post-increment might generate an extra copy even if it wasn't actually used.
For C++ this was even worse with iterators, because now it depended on the compiler's ability to inline its implementation of postfix ++, and then prove that all the copies produced by that implementation have no side effects to optimize it to the same degree as prefix ++ could. Depending on the type of the underlying value, this may not even be possible in general.
The other reason is that all other unary operators in C are prefix rather than postfix, and mixing unary prefix with unary postfix in a single expression produces code that is easy to misunderstand. E.g. *p++ is *(p++), not (*p)++, even though the latter feels more natural, reading it left-to-right as usual. OTOH *++p vs ++*p is unambiguous.
You get it!