Hacker News Reader

> 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.

> 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.

There is a difference between deciding "we don't need to be fast" and deciding "we need to be slow."

Code 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.

I 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?

There's a significant difference in meaning between "write slow programs on purpose" and "write programs that are fast enough but not faster."

> 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.

Warnings 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."

> Warnings 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.

No. The argument against premature optimization is not about labor vs. performance tradeoffs (but about correctness and maintainability vs. performance tradeoffs), nor is it about the entire code base, but about non-critical elements.

Quoth Knuth: “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

Thinking about and designing for broad performance concerns even though it adds to initial implementation time is not against the adage; it’s when you are compromising clarity and ability to reason about the code to shave off microseconds on a path without a clear reason to believe that its going to be hit often enough that those microseconds matter in the big picture that you are engaging in premature optimization of the type targeted by the expression.

EDIT:

> 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.”

If that is its explicit intent, sure; if it is a side effect, no. In any case, blaming such a paradigm on the adage against premature optimization is misplaced.

You're right, I guess it's the cargo cult interpretation of "premature optimization is the root of all evil" that's the issue.

That the adage was intended to address a narrower case does not invalidate your argument, friend!

People should, and do, make tradeoffs for maintainability over speed — and this is still choosing to make your app slow — whether Knuth meant it or not.

> No. The argument against premature optimization is not about labor vs. performance tradeoffs (but about correctness and maintainability vs. performance tradeoffs), nor is it about the entire code base, but about non-critical elements.

If true, I envy your ability to produce correct, maintainable code without labor!

Part 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.

That'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.

We 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.

That’s nonsense though. Native Mac apps built years ago continue to work completely fine on the latest OS releases.

One 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.

People used to talk about Java in the same way people talk about electron now so I feel like that's a definite no.

Programs 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.

The 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.

Java'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.

One wonders how fast Electron will be in 25 years, if it lasts that long.

The relative penalty for using Java over C is so much smaller than Electron over Java or Electron over C

For 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.

That'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.

Given 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.

One 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.