5 ms·

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 alre

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 5mo ago
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 5mo ago
  To me that's the people who write desktop software in Electron. Hate that.
  - bartread 5mo ago
    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 5mo ago
      I am testing Slint for exactly the same thing. An alternative to Qt/wxWidgets. It is written in Rust.
      - bartread 5mo ago
        Slint? Interesting: I will have to investigate.
  - Sammi 5mo ago
    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 5mo ago
  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.
  - Jensson 5mo ago
    > 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 5mo ago
    "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 5mo ago
      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.
  - YZF 5mo ago
    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.
cstoner 5mo ago
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.

Sammi 5mo ago

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 5mo ago
To me that's the people who write desktop software in Electron. Hate that.
- bartread 5mo ago
  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 5mo ago
    I am testing Slint for exactly the same thing. An alternative to Qt/wxWidgets. It is written in Rust.
    - bartread 5mo ago
      Slint? Interesting: I will have to investigate.
- Sammi 5mo ago
  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 5mo ago
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.
- Jensson 5mo ago
  > 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 5mo ago
  "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 5mo ago
    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.
- YZF 5mo ago
  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.

cstoner 5mo ago

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.