“Clean” code, horrible performance

I think the post invites a question to all the HN responders: What would it take for the computer [software] you are using to run at its full blazing potential?

The answer is - if every single piece of software was written while already knowing the true requirements, the scope of its use and re-use, and knowing the future bugs and security flaws that would appear, then it could be written one time and be BLAZING FAST.

Many parts would still be written in a 'Clean code' style for the necessary extensibility and testability, etc. But many others would be small and near optimal.

THEN on top of that, if the author or an equivalent talent came along and rewrote or supervised the optimization of the regular software, similar to how the article does, your system would be HYPER INSANE BLAZING FAST.

If we are proponents of OOP or Clean code, we need to acknowledge that fact. (i.e. My code may not be important but it all contributes to slowing down the computing world). And if we think the Author is preaching gospel here, you should also acknowledge that because the future is so often unknown when we write code we often have no choice but to fill it with Clean code that can be easily changed later, and sometimes even 'Shit code' that we thought would never be used by anyone.

>You keep saying, CPU cycles are cheaper than developer hours, but this is nonsensical without quantities attached to each. How many CPU cycles, on what kind of machines? How many cycles do those machines have to spare? What's the performance per watt? How many developer hours at what kind of salary? There's way too much missing info to be making such a statement.

Yeah that is fair. There is a lot of missing information. I'm only trying to across that now days developer time is often expensive and hardware is often cheap and powerful.

I don't like the idea that our goal is always to make the most efficient code possible. It's not, it's to deliver business solution as efficiently as we can with the resources available. Just like you wouldn't want to pay for a mechanic to spend a week making your car more fuel efficient if you took it in to get new engine mounts. His job is not to make your car work for you, not work the best it possibly could.

That said most of the time you do want to be writing efficient code.

I kind of want to amend that! I discovered today that maybe there is hope with granular update libraries such as Jotai, @preact/signals-react and recoiljs.

> I don't like the idea that our goal is always to make the most efficient code possible. It's not, it's to deliver business solution as efficiently as we can with the resources available. Just like you wouldn't want to pay for a mechanic to spend a week making your car more fuel efficient if you took it in to get new engine mounts. His job is not to make your car work for you, not work the best it possibly could.

If he could get me a 1000x gain in fuel efficiency, like you often see when software when performance overhauls are done, I would sure as hell give him his week. But this is less about maintenance and more about how the car/software is built the first time around.

In that vein, I do expect that if gasoline prices drop to $0.20c/gallon in a decade (hah), that fuel economy on new cars does not drop to 3mpg to match. That's essentially what seems to have happened in software --- the hardware got really fast, so software got really slow.

> It's not, it's to deliver business solution as efficiently as we can with the resources available.

This is true; I guess what I take issue with is externalizing hidden costs to the customer. We keep paying for faster and faster hardware, and have to because that old hardware which is still working perfectly fine can't run the new software, which is much slower. And often, even on new hardware, the software is just this side of "tolerable". If you're writing your own in-house tool and nobody cares, do whatever suits.

> That said most of the time you do want to be writing efficient code.

Yes. That's all I want. Reasonably efficient. Not balls-to-the-wall speed demon witchery like we saw back in the demoscene heyday, just not to be sliding backwards all the time to erase all the gains our hardware got us.

---

EDIT: I get where you're coming from with the business incentives, I really do. But I'm saying I have a lot of issues with the end result --- as is often the case, maximal profit for the business is wreaking havoc elsewhere, in a sort of tragedy of the commons effect. And there are no realistic ways for me as a consumer to alter business incentives. A lot of software, especially the type that people get paid to write is closed source and closed protocol.

An excellent example is Discord --- it works well enough, when it works, but it's kind of a big heavy behemoth. It doesn't run well on older computers (I frequently see it burning a whole core just sitting in a voice channel). Right now, it's using nearly 1GB(!) of RAM, and frequently climbs to 2 or more if I leave it run long enough. This is a program whose core functionality was essentially available to me in 1999, and it struggles if I try to run it on a 4GHz machine from 2012. The search function sucks imo, and various other complaints. Screensharing with audio is broken (because electron), and probably always will be.

And I can't do a damn thing about it. I can't use a different platform, because the platform I use is determined by the people I want to talk to that are already using it. I can't improve or fork the program, because it's closed source. I can't (realistically) use a different client, or even write my own, because it's a closed protocol. So I'm just stuck with this pig of a program, and no amount of rage or frustration that I feel will alter the company's business incentives.

But it's just one program, right? Okay, I've got the cycles to spare, and the RAM, well, I overprovisioned this machine, so (in the case of this one, relatively modern machine), it's not the end of the world... right?

Now add Spotify. It's the same damn problem, so now the problem is 2x. Add a web browser (I mean, one who's job is actually to browse the web). I manage to draw the line there, mostly, but a lot of people are stuck with a lot more (VS Code, etc). It all adds up to a nightmare. And yet, all the time, I hear how "performance doesn't matter" (not exactly your words, but a prevalent developer sentiment).

I dislike government intervention, and so disavow my following statement. In the course of fining hidden externalized costs like those of dumping chemical waste into rivers, governments might fine software developers when they dump informational waste on to customers' machines. In this hypothetical, they deserve it. Anyone who ships an electron app goes to the gulag.