> You're presuming to speak for @miltondts, while contradicting what they said.

I am presuming to speak for nobody except myself, by responding to your arguments.

> The argument at the top of the thread was that good implementations are to blame for perf decay.

I don't see that anywhere in the thread. If, by "good implementations", you mean "scalability, portability and clean code" - then you're wrong, because implementations that are highly inefficient are not "good", regardless if they're any of those other things too.

>> It should be pretty obvious that many features should have no perceptible performance impact if they're not actively being used.

> That's true, and irrelevant.

It's completely relevant, because the topic is "performance", and your argument is that the performance losses are caused by added features.

> It's also true that feature bloat is the number one cause of software slowing down. It doesn't have to be all or most features, it's still a fact.

...a claim which is so vague as to be unprovable, and for which you have provided absolutely no evidence whatsoever - so, no, it's not "still a fact".

Meanwhile, I can make any number of arguments from first principles as to why there's no good engineering reason why many of the added features of modern-day programs should cause the massive increase in used resources over their older equivalents.

I'm willing to bet that you cannot point out more than two or three features in Discord, Spotify, Teams, Atom, Slack, or other similarly bloated applications that actually necessitate their ridiculous resource consumption. As in, O(n) for space and time use. (hint: none of these programs are solving the traveling salesman problem)

> I've lost track of your point. Software is bigger? I agree. Some software is bloated and uses resources it doesn't really need? I agree.

Perhaps I should have stated my point more clearly: the main reason that modern programs are inefficient is because they're implemented with inefficient technologies, most relevantly Electron (and webtech more generally), and not because the added features that they bring are intrinsically computationally expensive.

> You're arguing with everything I say, but don't seem to be trying to have a conversation or to understand or give any benefit of the doubt.

A "debate" is different than a "conversation", and this isn't surprising. I'm not trying to have a conversation, I'm trying to debate points that you're making. Not everything can or should be a "conversation". Moreover, there's no "benefit of the doubt" to give - I'm not assuming that you're being malicious, I'm just asking for actual empirical evidence and/or argument from first principles - neither of which you're giving.

> Does this example support your argument about engineering failures somehow? I opened my Chrome task manager just now and my downloads tracker is consuming exactly 0 cycles. Have you seen Spotify shuffle consuming CPU? If not, why did you bring it up?

It should be pretty obvious that I brought those examples up to illustrate examples of features that should not use resources while not actively being used.

> Many features do have reasons to use resources. Caching is a feature that always uses memory when not in use, and caching is absolutely ubiquitous. Rendering is a feature that uses CPU even when the user isn't asking for anything. Speculative downloads, background processes, pre-computation, event driven callbacks, timers... the list of things ("features") your OS and browsers and applications intentionally do when you're not looking is very, very long.

None of these are "features" - these are all implementation details. A "feature" is the downloads page in Chrome, or the shuffle feature in Spotify.

> Naming a couple of cherry-picked features that don't use a lot of resources is not particularly compelling.

You haven't been able to name a single actual feature that has a technically valid reason to use significant resources simply by being added to a host program, let alone one that's relevant to the highly-inefficient applications that everyone throws around (Discord, Spotify, Teams, Atom, Slack). My features, while individual examples, are miles better than the literal nothing that you have provided.

And, for emphasis: I'm willing to bet that you cannot point out more than two or three features in Discord, Spotify, Teams, Atom, Slack, or other similarly bloated applications that actually necessitate their ridiculous resource consumption. As in, with big-O notation for space and time use. (hint: none of these programs are solving the traveling salesman problem)