Performance Matters (2019)

I'm old enough to remember Win32 programming in C/C++ because it was the only thing that worked. There was a problem though. Memory management, shitty standard library, and a non-existent packaging system. Java came around and gave you something that worked. Memory management? The runtime does it. Want to do X? Here is a library for X. These combined with academia moving over to Java killed new C++ development hard. It seemed good at the time. Java sucked but Widgets and MFC sucked harder. Qt wasn't that popular yet.

There was only one problem with Java. Even on new machines, you would get noticeable random pauses doing simple things. This never happened in C++ apps even with full MFC bloat. The GC just wasn't that good yet. Programmers would also include FAR more code and libraries because it sped development up. Even today, C++ applications only include libraries if they absolutely have to because of how painful it is.

All of C++'s disadvantages become advantages when you look at them from the lens of performance. Manual memory management means that even if you are slow, you are consistently slow. You don't get the peaks and valleys that really irritate humans who are incredibly sensitive to rhythm. Memory leaks are honestly not even a problem unless you have long running servers. Even then, you could honestly just restart. The near-complete lack of standard libraries and complete lack of a package system highly reduced the amount of fluff you had. If you wanted it in your software, you had to do it yourself. This led to very simple, non-pretty, static interface that just tried to look like Word without the Toolbar of Death. The best optimization has always been to Do Less Stuff.

It's only going to get worse too. The same companies who think C++ is too complex for their programmers are going to laugh at Rust. People in Java or .NET shops aren't going to move over. "Native" is increasingly becoming a JavaScript space which has all the terrible performance of JavaScript usually combined with the slowness of internet connections. For good and ill, package management is now standard.

Microsoft Office used to run fast on a 486 with megabytes of ram. Think about that. Are you a more complex or intensive program than Word? I bet that ePCR has far higher specs. The program running on it isn't inherently more complex. It's literally a form filler, but it isn't used because of how ridiculously bloated even the most basic software has become. In the 90's, you could have made that machine by installing Windows on a machine and programming a VB program in a few weeks that hooked up to a printer. It would have been more responsive than a state-of-the-art ePCR that sits unused today.

It isn’t as simple as that but I still want to recognize and applaud this response. You’re right, performance isn’t the fundamental issue, distance from user need and user pain is. Unfortunately even where that distance is short, mitigation can be hard to achieve. Understaffed and underfunded orgs can be wildly aware and even obsessed with shortcomings in their offerings and still fail to deliver improvements. I’ve worked in such orgs, I’ve seen overworked, deeply caring and empathetic and dedicated engineers trying to move mountains to fix (and have habitually been one myself).

More to the point: unfortunately the software needs in the world, and the ways the world are underserved by software, are competing for resources and organizing talent with organizations that fundamentally don’t serve those needs. And both categories are competing in a limited pool, because software’s capabilities have outpaced the available talent to take advantage of those capabilities.

Good for my bank account, I guess. But bad for people and the world we (I) inhabit. And bad for me too, probably even more than I know.

Anyway this is far afield of parent comment’s point, but I felt it was a good place to add a little depth as an engineer who gives a damn but rarely sees the opportunity to apply damns.

This is great for two reasons (and probably more):

1. It highlights that user impact determines success more than resource metrics.

2. It shows that assumptions infect even when you think you’ve accounted for assumptions.

Honorable mention: don’t just prove the abstraction and call it done. It’s got to prove itself in real world scenarios before you can trust its claims!

I'm not sure this is a useful summary of the problem. I've seen an awful lot of code written in C and C++ that pisses away any and all advantage of using either. In general, I think software devs (and the software market) tend to value convenience over performance until it's too late, but the reasons why are so complicated and different per sector they'd make for a full PhD thesis and then some.

One thing I don’t see mentioned here (haven’t looked at the past comments link but it’s worth surfacing here) is that requirements for many public RFPs, health care being right up there, is that since most people driving the process aren’t intimately familiar with software success and failure cases tend to refer to the intersection of tech and regulation. They don’t necessarily think about usability except in terms of a11y. Uptime, yes. Human experience interacting with it? Likely only if it resembles workflows that are similar and painful for them. This isn’t faulting these people defining these requirements! It’s a call to all the types of HN readership to put yourself more in the position to bring the knowledge that informs your contribution into the requirements process. You might never know that the success of the project you work on depends on your knowledge of color accuracy or time zones or particular patterns of abuse... until you get yourself a seat at the “first things first” table.