This is just going to encourage bloat and inefficiency, isn't it? Note: this has nothing to do with specifically Apple Silicon but just any computing improvements in general.
Kind of a cynical take... but is he wrong?
Still, I feel there's a lot of software I use that is hard to optimize or no longer developed, and I'm certainly happy to have it run faster given new hardware. As a programmer I also like being able to be lazier and still have usable software. Higher level languages, GC, less thinking about access patterns and debugging prefetch problems, etc.
More seriously, while program overheads have undoubtedly gotten higher, that's always been in exchange for something else, even if non-technical, like a better developer experience and platform support. 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. Low level programmers love to smugly pretend that those tradeoffs do not exist but they do.
No, but we are in a place where most development projects are really "stitching" dependencies together, and those dependencies can get heavy.
On the other hand, this may help apps written in things like Ionic to speed up like crazy, because WebKit is now insanely fast.
Is there anything wrong with that, though? If there's any common thread in the history of computing, it's that progress happens when things become abstracted enough to allow for another layer of building blocks. That's not to say that those layers don't have a cost, or we don't need to learn how to do them well, but gluing together components is really all software development has ever been.
It's hard to use a lot of dependencies, regardless of their quality, without introducing bloat. Lots of redundancies.
For example, each dependency may have its own messaging or thread management system, or its own memory management system.
Or it may include other dependencies that have their own "special sauce."
For myself, I use lots of little packages; mostly written by Yours Troolie, and only occasionally use third-party dependencies.
Each of my packages is usually crafted towards a certain discrete function, and has its own project lifecycle. I think that's a good thing about using dependencies. I believe that modules with encapsulated lifecycles are a good way to ensure quality (or not, if I "choose poorly," as the Knight Templar said in the Indiana Jones movie).
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.
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.
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.
Real software that does a job you need it to do is much better than hypothetical software that will do the same job faster.
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.
No, the first is not the meaning of the second.
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."
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.
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.
If true, I envy your ability to produce correct, maintainable code without labor!
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.
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.
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.
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.
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.
More seriously, while program overheads have undoubtedly gotten higher, that's always been in exchange for something else, even if non-technical, like a better developer experience and platform support.
- Many devs aren't familiar with the real breadth of possibilities and discount some approaches without understanding them (using "developer experience", "platform support", and "too low level" as excuses), thereby skewing towards familiarity and preference. As most devs are familiar with web tech, this tends to win out. Other legitimate issues might not be even be understood (HCI, attack surface, accessibility, etc.)
- The performance hit might not be significant enough to notice on a dev-grade machine (e.g. M1-processor, 32GB of RAM, etc.) and/or in isolation, but will become noticable when regular users run several apps built using the same heavy stack.
The latter is particularly apparent if you try to run multiple Electron-apps simultaneously on a low-to-medium specced laptop – which I find pretty egregious as a user, as multitasking computer systems has been a thing for a while now.
My interpretation is that many people (or companies) will usually write software that's no more performant than what they can get away with – which can be summed up, if cynically, as "users won't see any major performance gain or increase in capability in their day-to-day usage because of shitty software."
This is also how I felt watching the video, but on the other hand I have a really hard time finding serious faults with his point.
HN keeps things light. My personal website is super light. But the product I work on? What's a few MB gzipped down to less than a MB? 100ms? 300ms? Who can tell the difference[0].
[0]: I can, but certainly not the people who the feature matters to much of the time.
Yeah most things are frivolous... you can survive without a better camera in your phone for another year. But that ham-fisted implicit cultural aspect is what also brings people medical devices 5-10 years sooner than it could have. We all know these gains compound over time. So maybe it's ok if our programs are a little slow. We buy the truly mission critical technology faster with that frivolity.
But I'll also say, I still get mad at my phone and throw it pretty often. Just the way it is.
Well problem is developers are not writing fast programs on purpose. That they did not write slow on purpose but it nevertheless turned out to be slow is real problem to me as a user.
True, but nobody writes fast programs on purpose either, only "fast enough" programs. The optimization work stops as soon as it "feels" fast enough and, this "feels fast enough" has been the same over the last few decades no matter how fast the underlying hardware is. Any advance in hardware will ineviatably be eaten by software within a year or two. That's why running old software on new hardware feels so increadibly fast.
I also disgree that we got better developer- or user-experience out of the "deal". Most commercially developed applications have a "peak version", but still continue to be stuffed with new features that nobody asked for. E.g. name one feature that was added to Microsoft Word, Outlook or Excel in the last two versions which really added to the "user experience".
However, when it comes some software areas prone to capture, there's not only no choice, but rather a multitude of incompatible-by-design options. Due to WFH, I need to have four different bloated chat/videoconference software on all the time which all offers the same features to me. When I want to watch a live stream, I need to open YouTube or Twitch or Facebook Live which all offer the same basic functionality but no one is interested in standardizing their interface so I can just point my familiar video player to it (at least without it breaking all the time due to cat-and-mouse fights between the platform and open source developers).
I'm not generally in favour of regulation, but mandating some basic degree of interoperability so platform and software can compete separately seems like the only option.
That said, there's something of a problem with that though, because by making 1) more and more prevalent, it makes 2) more expensive due to fewer people choosing to work in that manner. Similar to how consumer technology goods get much less expensive, but have many more defects and issues. That "race to the bottom" makes cheap things cheaper, but makes more expensive things more difficult to make. I don't know what that phenomenon is called specifically, but it's definitely something I've been frustrated by in nearly every industry and product category.
It's not that people or organizations were necessarily more considerate or contemplative in the past, it's just that the processes or technological improvements (e.g. better hardware) weren't there to allow those races to the bottom. And maybe the systems we were living under didn't reward that behavior as much.
This software culture is visible on Linux than macOS, but it's alive and thriving.
Further, as someone who deals with HPC at $WORK, our (medical) researchers always want faster.
Also every laptop I've had prior, would get pretty hot or the fan would get quite loud when connected to an external display. This M1 is completely silent when doing that AND it doesn't throttle.
But I see two reasons why the M1 is a big deal, even given the bloat tax.
One is simple power efficiency. These chips run cool and fast, and Intel laptop chips don't. No amount of hyperefficient code is going to get you a real 18 hours of battery life on last year's MacBook Air.
The other one is Apple's proven track record of integrating custom hardware and software, into something which is greater than the sum of its parts. Ever since I got an iPad Pro, I've been quietly frustrated with the user interface of MacBooks. It's just not physics-smooth, and the iPad just is.
I just got one of the 16" MacBook Pros for work, and it's pretty loaded, and it's a good computer— by the standards previous to the M1. Battery life could be better; overheats sometimes with serious fan noise, for no good reason, although each update to Catalina appears to substantially reduce this.
I figured I could get five years on this rig. No way. I might make it to 2022, but I know terminal gearlust when I see it. Whatever Apple sticks in the next release of the 16", I'm craving it already.
Latency from the user perspective is a bit harder, although I guess for a webpage you could run it headless into a video recording then time how long to go from a blank screen to showing information?
If facebook doesn't have the money for the engineering effort to build a native messenger app, I don't know who does
Same as it ever was:
> Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster.
> The adage is named after Niklaus Wirth, who discussed it in his 1995 article "A Plea for Lean Software".[1][2]
[…]
> Other common forms use the names of the leading hardware and software companies of the 1990s, Intel and Microsoft, or their CEOs, Andy Grove and Bill Gates, for example "What Intel giveth, Microsoft taketh away"[7] and Andy and Bill's law: "What Andy giveth, Bill taketh away".[8]
I was thinking the same thing as I read this bit. I’m still on an Intel Mac and recently switched from VSC to Panic’s Nova editor, highly polished and 100% native.
If bloated code runs fast on an M1, imagine how native code performs? I’m trying very hard to excise as much Electron garbage from my life as possible.
As an example, Minecraft on the 16GB M1 Pro running under Rosetta 2 runs much better (near-constant 60fps with everything on default, no fans, imperceptible heat) than on the 32GB i9 Pro (peaks about 40fps with everything turned down, full fans, will burn you unless you disable Turbo Boost).
I'm looking forward to a native JVM and seeing if it gets even better.
(I assume you can sub in your own JDK with Minecraft? Never used it)
The bar of quality are quite low for lot of people.
We simply wouldn't have the services we have today at their low price if our hardware didn't offer them more breathing room.
As inefficiency tips more towards degradation in machines, more emphasis will be given to efficiency.
While you can profile performance in any web inspector, I think a good product team should keep a base-spec Windows laptop on hand to see how it all comes together for users who may not have the kind of hardware they design and develop on.
Roughly 1/100000 of what's on a low end computer today. On a CPU that ran at 1MHz and took many clock cycles per instruction.
In other words, yes but that's nothing new.
There's a heck of a lot of pointless bloat. But at least some of the extra power has gone to useful features!
Today feels different. If Slack really have any significant features that couldn't be done on computers 15 years ago?
Processing the touches into events should take 1 C64 of power or less.
Scrolling shouldn't significantly more difficult. 1 C64 for this.
The screen is much higher resolution, so we need the power to render that, but that's offloaded to the GPU and the GPU doesn't even need to leave idle frequencies.
60fps, well what was the C64? Whatever, multiply the resources by 10.
We've now accounted for... 20 C64s of power.
It's a little odd to exclude the supercomputer your computer comes with to help with scrolling.
And, I mean, the C64 offloaded rasterization to a different chip too.
Don't even get me started on drawing more than 8 sprites!
(Ex C64 games programmer here)
The C64 had a resolution of 320x200 pixels with 16 colors. That would cover about 1,5 square inches on a modern phone (modulo the colors, another factor of 6 to 10). You could not dream of re-rendering the whole screen with any FPS number. Games had to resort to all kind of tricks to create a smooth experience, and whatever was put on screen was pre-rendered content combined in clever ways. Calculations involving floating point like a mandelbrot set in said resolution took hours to days per _frame_.
And the C64 does re-render every frame, because there's not enough memory for a frame buffer!
I'm not worried about games here, and word processors don't need fractals.
Apparently this and other things did not go over well with developers (apparently the apps needed to be done at least partly in assembly too). Wikipedia:
GeoWorks attempted to get third-party developers but was unable to get much support due to expense of the developer kit — which ran $1,000 just for the manuals — and the difficult programming environment, which required a second PC networked via serial port in order to run the debugger.
Even though PC/GEOS is referred to as an "operating system", it still requires DOS in order to load. GEOS and its applications were written in a mix of 8086 assembly (Espire) and C (GOC), both with non-standard language extensions to support the object-oriented design.[5][9]
In the past, I developed on old hardware (or at least tested on old hardware). If the software was performant on my old machine, it was bound to be fine for most others.
There is no virtual machine, and nothing is happening other than your code and the libraries you use.
It’s only high level from the point of view of the type system.
Eh? Apple's fairly clear about what Swift is doing in the background (which isn't much, really; boring ol' reference counting).
This might apply more to Java, mind you. There are no secrets, but most people probably aren't going to investigate exactly what the JIT or GC are doing.
Are there any specific instances you’re thinking of here? Java, Go, and even Swift all are open source.
I don’t really understand your complaint here. The Swift runtime library is pretty limited - basically just allocation and reflection. The compiler spits out machine code that you can look at. Where is the “background” you are thinking of?
I remember being shocked when I first read a game requiring 16MB of RAM (yes, 16MB, get off my lawn).
If I ever meet the king of software I could ask him to make faster software, but I haven't found him in the phonebook yet.
They are cross-platform apps which still need to run well on the 95% of other computers which don't have the M1 chip.
This isn't like with web browsers where it impacted everyone.
If it does, Wintels are not going to be pleasant environments for users. Wintel laptops would need to up to 32gb/64gb RAM