[tananaev]

With modern tools it should be pretty easy to build scalable solutions. I take premature optimization as going out of your way to optimize something that's already reasonable. Not that you should write really bad code as a starting point.

[Sammi]

The problem is that that this term gets misused to say the opposite of what it was intended for.

It's particularly the kind of people who like to say "hur hur don't prematurely optimize" that don't bother writing decent software to begin with and use the term as an excuse to write poor performing code.

Instead of optimizing their code, these people end up making excuses so they can pessimize it instead.

[Shorel]

To me that's the people who write desktop software in Electron. Hate that.

[bartread]

I believe use of Electron is known as premature deoptimisation and if it had been a thing when Knuth coined the original phrase I'm sure he would have come up with that term too. Use of Electron to deliver software is popular and works but that doesn't make it any less of an abomination.

I'm actually considering, for the first time since 2013/14 when I worked on a Visual Studio extension, creating a piece of desktop software - and a piece of cross-platform desktop software at that. Given that Microsoft's desktop story has descended into a chaotic mishmash of somewhat conflicting stories, and given it will be a cold day in hell before I choose Electron as the solution to any problem I might have, most likely I will roll with Qt + Rust, or at least Qt + something.

20-odd years ago I might have opted for Java + Swing because I'd done a lot of it and, in fairness to Swing, it's not a bad UI toolkit and widget set. These days I simply prefer the svelte footprint and lower resource reuqirements of a native binary - ideally statically linked too, but I'll live with the dynamic linking Qt's licensing necessitates.

[Shorel]

I am testing Slint for exactly the same thing. An alternative to Qt/wxWidgets.

It is written in Rust.

[bartread]

Slint? Interesting: I will have to investigate.

[Sammi]

I'm going to put a huge `depends` on this one. If it's for a small widget you click on once in a while, but it stays loaded as a full Electron app all the time, then yeah it's terrible. If it's a full time front and center application like VS Code, then Electron earns it's keep. The more often you interact with the app the more willing you will be to put up with the headroom that Electron requires in order to get the real benefits that Electron provides.

[pydry]

In my career Ive seen about 1000 instances of somebody trying to optimize something prematurely.

Usually those people also have a good old whinge about the premature optimization quote being wrong or misinterpreted and general attitudes to software efficiency.

Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path.

[YZF]

In my career I've seen endless examples of hopelessly badly designed software where no amount of optimization can turn it into anything other than a piece of garbage. Slow, bloated and inefficient.

Ascertain an issue is too late for bad software. The technical term is polishing a turd.

Not that what you're describing doesn't happen, people trying to make something irrelevant fast, but that's not the big problem we face as an industry. The problem is bad software.

[wredcoll]

Hurray, bad software is bad, we did it! Just don't write bad code!

[YZF]

Before you write code you design (and/or architect) a system (formally or informally).

There's too little appreciation today for a well designed system. And the "premature optimization" line is often used to justify not thinking about things because, hey, that's premature. Just throw something together.

[wredcoll]

Like everything else there's nuance and a range of appropriate behaviors. It's probably worth spending some time beforehand designing the next mars rover's software but it's real easy to get, say, the design of an ai based program editor wrong if you aren't getting user feedback.

[Jensson]

> Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path.

Many things need to be optimized before you can easily profile them, so at this stage its already too late and your software will forever be slow.

[hunterpayne]

"Not once have I ever seen somebody try to derail a process of "ascertain speed is an issue that should be tackled" -> "profile" -> fix the hot path."

That's because your boss will never in a 1000 years hire the type of dev who can do that. And even if you did, there will be team members who will fight those fixes tooth and nail. And yes, I have a very cynical view of some devs but they earned that through some of the pettiest behavior I have ever seen.

[wredcoll]

Man, what are you talking about? Speed optimizations after shipping software happens constantly in everything from video games in C to ui libraries in js and everything in between.

People write some code, test it, ship it, then get some ideas that its too slow and make it faster.

The nice thing about doing it with shipped code is you can actually measure where time is spent insyead of guessing.

[cstoner]

Yeah, I interpret "premature optimization" as taking a request that takes 500ms and focusing on saving a couple ms by refactoring logic to avoid a SQL JOIN or something.

Your users are not going to notice. Sure, it's faster but it's not focused on the problem.