8 ms·
> Nobody writes slow programs on purpose, but people are very willing to trade it off for things that are more important in the grand scheme of things Wait, of
by zamfi 6y ago
> Nobody writes slow programs on purpose, but people are very willing to trade it off for things that are more important in the grand scheme of things
Wait, of course they write slow programs on purpose, because "premature optimization is the root of all evil," right? A developer might use Electron because it's "fast enough" and halves your development time, and "fast enough" is always a perceptual metric, and not a technical one.
Faster hardware means even less optimization is needed before something is shippable -- great for developers! -- and a recipe for software continuing to feel just as slow as before, because we only optimize until it's "fast enough".
And despite the M1, or any of the advances of the last decade, the perceptual line that is "fast enough" hasn't changed.
EDIT: Yes of course Knuth was talking about optimizing noncritical paths, but the sprit he’s espousing lives on in system design: use electron, or something else that makes your product more maintainable and easier to understand (because you didn’t build your own bespoke cross-platform app scaffold, and electron is well-documented, etc.), until you’re sure you can’t anymore. Well, the bar for “can’t” is raised every time there’s more cpu to support rapid, maintainable, “nonoptimal” development, and here we are.
- Apocryphon 6y agoOne wonders if VC-funded startups or "move fast and break things" firms like Facebook or Uber (as opposed to say '90s Microsoft or Sun or IBM or Bell Labs) becoming the vanguard advancing the cutting edge of some categories of software has created perverse incentives that reward this behavior. A cultural shift in Silicon Valley software development.
- ATsch 6y agoPeople used to talk about Java in the same way people talk about electron now so I feel like that's a definite no.
- nalekberov 6y agoPrograms written in Java runs on top JVM. On the other hand programs written for Electron comes bundled with Chromium. And we all know how it manages memory.
- mapgrep 6y agoThe JVM is fast today after 25 years of optimization and some serious improvements in the underlying processors (even with the Moore’s law failure of maybe half that period). It was not fast at all when the Java hype was peaking in the late 90s. I knew a dotcom era startup that replaced a bunch of Perl with Java and my friends complained it had fewer features and was much slower.
- Apocryphon 6y agoOne wonders how fast Electron will be in 25 years, if it lasts that long.
- nalekberov 6y agoJava's selling point was portability, and did it very well, it was faster than programs written in interpreted languages, well it was and still is slightly slower than programs written in C and likes. Programs written on Electron rely solely on web technologies, I always avoid these programs, one simple chat application eats up to half a GB of memory, no I am not going to increase my machine's memory in order to run those programs.
- sudosysgen 6y agoThe relative penalty for using Java over C is so much smaller than Electron over Java or Electron over C
- Turing_Machine 6y agoFor cases on the edge, the penalty for not using Electron is that you don't get to use the software at all, because the developer doesn't have the personnel or budget to port it to multiple platforms. Real software that does a job you need it to do is much better than hypothetical software that will do the same job faster.
- sudosysgen 6y agoThat's not really true. There's very few software that wouldn't exist if it weren't for Electron. You don't need to port Electron tier-software. This was a solved issue long ago. Code it in Java, Python etc... Or Use Rust/C/C++ and a cross platform toolkit.
- dragonwriter 6y ago> Wait, of course they write slow programs on purpose, because "premature optimization is the root of all evil," right? No, the first is not the meaning of the second.
- adrusi 6y agoWarnings against premature optimization suggest a two-pass strategy, where in the first pass you avoid trading increased performance for increased labor, and then in the second pass you do whatever is needed to make the performance good enough. The faster the underlying platform, the less work is required to get to "good enough" performance, so this strategy absolutely leads to software not getting faster as hardware gets faster, and the only way for an end-user to get their software to run fast is to have faster hardware than is typical for the target market for that software. I don't think it's much of a stretch to call a development paradigm that causes software to never get faster even as hardware improves "writing slow programs on purpose."
- erik_seaberg 6y agoPart of the reason for writing the slow version is that you need to profile it to find out where the problems actually are, because intuition is not a very good guide. Some of the worst bottlenecks seem tiny but happen so frequently they add up, while a lot of things that sounded slow don’t actually matter.
- carlmr 6y agoThat's also the thing with premature. I would agree with you that premature is before you know what's slow. But if you have a CI Profiling run showing a few hotspots it's not premature anymore. Still people quote this adage. Further there are things you should know are usually performance issues, that I would expect you to avoid entirely, except with good reason. Using O(N²) or worse algorithms on big collections when there are much faster alternatives in the standard library of your language for example. I don't think these good habits are premature optimization.
- 6y ago
- doggosphere 6y ago> Wait, of course they write slow programs on purpose, because "premature optimization is the root of all evil," right? A developer might use Electron because it's "fast enough" and halves your development time, and "fast enough" is always a perceptual metric, and not a technical one. That's not writing a slow program on purpose; that's accepting a tradeoff of speed for deliverability. Writing a slow program on purpose means intentionally adding code to make it slower with no other consequence. "Fast enough" can be measured in ms latency for UX purposes. Ex: Websites test and benchmark themselves on load time because they know sales/pageviews decrease after too long.
- zamfi 6y ago> accepting a tradeoff of speed for deliverability So...making a purposeful decision that results in your program being slower...is not “writing slow programs on purpose”? They’re definitely not slow by accident. No one but artists (this is not a dig at artists, in fact I love them and teach them to program at an art school) would take “writing slow programs on purpose” to mean “adding useless code to slow things down”. It’s all about making decisions that prioritize the perceived latency at the expense of anything else.
- cwyers 6y agoThere is a difference between deciding "we don't need to be fast" and deciding "we need to be slow."
- Turing_Machine 6y agoCode that makes your software able to run on a completely different platform with minimal further development cost isn't "useless". Quite the contrary. And you're not adding it "to slow things down". You're adding it to make it possible to run at all on the other platform.
- zamfi 6y agoI guess I wasn’t clear — this is my point! You’re adding it because it has huge benefits, and one cost is it slows things down. You are still making an explicitly decision to use something that makes your app slower, no?
- jimnotgym 6y agoWe are looking at Electron as a potential way to write once for all platforms, not least to be able to run on Mojave, Catalina and Big Sur without a breaking change every 12 months. The software is in the 'run once every few months' category, so for me the optimisation required is not anything to do with speed or memory usage, and more about not getting nailed by Apple's latest change of direction.
- matthewmacleod 6y agoThat’s nonsense though. Native Mac apps built years ago continue to work completely fine on the latest OS releases.
- baumandm 6y agoThere's a significant difference in meaning between "write slow programs on purpose" and "write programs that are fast enough but not faster."
- groby_b 6y agoGiven that people whine if an app costs 99 cents, and that a lot of people proudly copy commercial software without paying... Maybe it's not just developers at fault here. There are plenty of devs who'd be happy to ship extremely high quality, small & fast code. It's just that very few people want to pay for it.
- zeroc8 6y agoOne of the problems is, that Microsoft failed to provide a decent native framework for their platform. WinRT/C++ now kind of fits the bill, but MS still doesn't seem to push it in any way. I've recently switched to the Mac and I'm learning Swift/SwiftUI/Metal right now. Apple has its act together, writing native platforms using those technologies is a dream come true.