Speaking from a place of long-term frustration with Java, some compiler authors just absolutely hate exposing the ability to hint/force optimizations. Never mind that it might improve performance for N-5 and N+5 major releases, it might be meaningless or unhelpful or difficult to maintain in a release ten years from now, so it must not be exposed today.
I once exposed a "disableXYZOptimization" flag to customers so they could debug a easier without stuff getting scrambled. Paid for my gesture for the next year signing off on release updates, writing user guide entries, bleh.
So it's better to hardcode your specific library name and deal with the same issue after people have reverse engineered it and started depending on it anyway?
The premise of removing the flag is that it's useless or a problem. If it's still causing a big speed boost somewhere then you need to figure something out, but the core scenario here is that it's obsolete.
Assigning blame doesn't do anything for safety, even if you're right. Where I live, by far the safest thing to do is to drive ~4 mph over the limit on all non-residential roads. If you drive below or even right at the limit, you will be tailgated or passed with far greater frequency. That behavior is out of your control, at least on the road. You can push for more consistent enforcement while you're not driving (I'm inclined to do so myself), but while you're behind the wheel, the only behavior you can change is your own.
No disagreement here, but where the literal rubber hits the road, you still have to decide how to act when the ambient semi-aggressive driving population continues to behave in the way that they do. Will you blamelessly be road raged at 50-100% more often than a more moderate driver (who drives at the most popular speed, though it may be over the limit) just because if an accident does happen it will be the road rager's fault?
It's a very frustrating social problem. Obviously we can't let ourselves be held collectively hostage by bad actors in all situations. But I would still predict that there are some situations where the bad actor population is so large and "mildly-bad" that indefinitely giving in to their implicit demands is the right game theoretic choice.
> But I would still predict that there are some situations where the bad actor population is so large and "mildly-bad" that indefinitely giving in to their implicit demands is the right game theoretic choice.
Game theory is quite a big thing, that's for sure. And it's no surprise that actors will tend towards these situations where you're tempted to think "eh, letting them do this bad thing with impunity feels like the right game theoretic choice, because it's right at the limit of not being bad enough to illicit a response." And yet, there's a reason for things like territorial behavior in the animal kingdom, where an animal will defend minor territory disputes at great personal cost even when the cost of losing a small amount of territory seems much smaller.
Well, "People who drive below the posted speed limit (road boulders) are a menace" is not just assigning blame, but severely exaggerated angry claim. Somehow, you have choose fairly calm response to it as the thing to criticize as assigning blame.
And driving in the "slow" lane where every single driver has to go past you to get on/off the road isn't generally safe either. On a 2 lane road you don't have much choice, but on a busy 3 lane road, probably not a great choice either.
There is no year zero according to first-order pedants. Second-order pedants know that there is a year zero in both the astronomical year numbering system and in ISO 8601, so whether or not there is a year zero depends on context.
It's ultimately up to us to decide how to project our relatively young calendar system way back into the past before it was invented. Year zero makes everything nice. Be like astronomers and be like ISO. Choose year zero.
Yes but, is there such a thing as a zeroth-order pedant, someone not pedantic about year ordinality? As a first-order meta-pedant, this would be my claim.
Moreover, I definitely find the ordinality of pedantry more interesting than the pedantry of ordinality.
> It's ultimately up to us to decide how to project our relatively young calendar system way back into the past before it was invented. Year zero makes everything nice. Be like astronomers and be like ISO. Choose year zero.
Or, just to add more fuel to the fire, we could use the Holocene/Human year numbering system to have a year zero and avoid any ambiguity between Gregorian and ISO dates.
If only—I think most US citizens who actually work with units of measurement on a daily basis would love to switch to the metric system. Unfortunately, everyone else wants to keep our “freedom units” (and pennies)
We are all defacto ISO adherents by virtue of our lives being so highly computer-mediated and standardized. I’m fully on board with stating that there absolutely was a year zero, and translating from legacy calendars where necessary.
I vote for a year zero and for using two's complement for representing years before zero (because it makes computing durations that span zero a little easier).
"Eat cells, not substances" is a somewhat similar rule to "limit processed food intake", but the former would seem to encourage both pasta and rice while the latter would discourage pasta if you're being strict about it and rice if you're being extremely strict.
"Reeks" (stinks) not "wreaks" (inflicts). And for any linguistic archaeologists of the future, yes, this is evidence that those two words are audibly indistinguishable in American English in this time period.
It's interesting how many people assume telemetry is just for spying on users and not an honest attempt to actually improve the product. Usability on most FOSS tooling is garbage. Even gems like Blender have incredibly rough edges compared to their commercial counterparts and that's one of the best examples of UX in FOSS. If users are spending a disproportionate amount of time performing operation X, I want to zoom in on operation X and find out what is holding them up and if it can be streamlined. I get that a lot of these metrics can be used more nefariously, but if you want to improve something you've first got to measure it or you have no baseline to determine if your "improvement" actually made a difference.
Telemetry and usage information is not bad in and of itself. It's a perfectly valid tool that can be used to find rough edges on your product and improve them. It's a great way to determine the most commonly used operations. Every developer who has worked on products used by real people inevitably discovers that their users approach their software in ways completely different than intended. Some of these unintended ways represent valid use cases the developer or product owner never anticipated. If you discover these things, you can improve the product by making that operation a first class operation instead of a weird workaround. If you're not collecting metrics, you're only listening to the most noisy parts of your user base who are by definition a small minority.
People are desensitized to claims of possible product improvements because closed-source software says it's collecting telemetry for that reason too, despite the fact it is used for all kinds of nefarious purposes. While it could be possible to get useful information from telemetry, there's no way for the collector to verify anything about popularity without violating your privacy. I don't think there is anything wrong with having an opt-in system for people who want to be involved while leaving everyone else alone. I think AUR and maybe NPM have voting systems. Github also acts as kind of a voting system, with its stars. Package downloads are a good semi-anonymous metric that works without telemetry. It could be gamed, but if someone was enthusiastic enough to game it then maybe their project should be considered active.
I would probably rather nothing logged, but I must say that when working on a language inside a company (rather than open source) and being able to do telemetry is a massive win.