> (...) because it was not written in the modern way or it was not very generic or whatever.
Premature generalization is a well known problem and a never-ending source of complexity. I lost count of the times I had to push back on PRs of clueless developers who felt the need to generalize one-liners that pop up twice in the whole project, and for that their proposal was to add a strategy pattern, ultimate replacing two expressions with three classes.
> So why do 99% of real world applications run like garbage?
If you're really interested in the impact of performance issues on everyday life, you need to provide concrete examples instead of putting up unverifiable strawmen.
The truth of the matter is that 99% of real world applications run just fine, and it doesn't pay off to invest in shaving milliseconds here or there. Would it be desirable to have a magic wand to improve some edge cases? Yeah, why not? Is it worth to pay people to spend time with a stopwatch at hand to shave off these milliseconds? Not really. It's all about tradeoffs, and there is no real world payoff in wasting developers' time to shave off that millisecond here or there.
> I realised when I implemented EdDSA for Monocypher that optimisations compound.
I feel you're missing the whole point.
It's immaterial whether anyone can get to optimizations that compound multiplicatively. The whole point is that halving something that costs nothing earns you nothing. That's the whole point. Go ahead and shave off that millisecond. Will anyone actually notice whether you add or remove that penalty? Odds are, not at all.
> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...)
You attempted to present an argument that's a textbook example of an hyperbolic fallacy.
There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time".
This blend of specious reasoning is the reason why the first rule of software optimization is "don't". Proponents of mindlessly going about the 1% edge cases fail to understand that the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing, with a tradeoff of producing unmaintainable code.
The truth of the matter is that in 99% of the cases there is absolutely no good reason to run after these relatively large performance improvements if in the end the user notices absolutely nothing. Moreso if you're writing async code that stays far away from any sort of hot path.
> It definitly is, because despite being mostly C#, outside the graphics engine itself, they have decided it is the right tool for some of their projects.
No, it was not a reasonable remark. Pointing someone else's choice changes nothing. The point that you keep missing is that performance is a key decision factor, one among many, and baseline performance penalties imposed by a particular choice of programing is a factor that adds up to all other choices. If you degrade the performance of your offering without any relevant tradeoff, you're making it harder to justify it's adoption.
Feel free to insist in your personal assertion. Those who care about performance feel strongly about gratuitously pile performance penalties without any meaningful tradeoff to show.
> You were complaining about 1% performance deltas else-thread (...)
You should revisit that corner of the thread to revive your memory. The discussion was about adding an extra 1% performance penalty for reasons, not the importance of a 1% delta either way.
> And yet even the likes of Sony and Nintendo are working in major titles with Unity.
I don't think this is a reasonable remark.
The whole point is that the 1% penalty is added on top of whatever choices "the likes of Sony and Nintendo" make. If they have alternatives that ensure them a performance win just by chosing the right tool to work with Unity, they won't choose the wrong one.
> No, but only in situations where it is user controlled. In other words, tools that empower a user to control what they read is not censorship.
That makes no sense. A paper supplier is not censoring anyone if they can't or won't provide printing paper.
You're somehow conflating not actively supporting a cause with censoring someone. It's ok if you feel yo have something to say to the world, but that does not give you the right to coerce everyone around you to support your personal project.
> This is why arguments justifying censorship by saying "just host it yourself then" are wrong.
That was never the argument.
The argument is that private companies have the right to provide their services in their terms, and if your intended use violates those terms then you also have the right to pick a services that tolerates you and your intended use. Aka gay wedding cakes.
Premature generalization is a well known problem and a never-ending source of complexity. I lost count of the times I had to push back on PRs of clueless developers who felt the need to generalize one-liners that pop up twice in the whole project, and for that their proposal was to add a strategy pattern, ultimate replacing two expressions with three classes.