Comment by snickerer | Hacker News Reader

Comment by snickerer | Hacker News Reader

I agree with this article a lot.

The layers over layers of software bloat increased with the hardware speed. The general trade-off is: We make the software as slow as possible to have the shortest development time with the least educated programmers. "Hey web dev intern, click me a new UI in the next two hours! Hurry!"

This intern-clicks-a-new-UI works because we have a dozen layers of incomprehension-supporting-technologies. You don't need to know how most parts of the machine are working, Several libraries, VMs, and frameworks will make you a bed of roses.

My point is that we a overdoing it with the convenience for the developers. Today there is way too much complexity and bloat in our systems. And there are not enough programmers trained to handle memory management and similar low-level tasks. Or their bosses wouldn't allow it because the deadline, you know.

I think the general trend is bad because there is no free lunch. No silver bullet. Everything is a trade-off. For example C is still important because C's trade-off between programming convenience and runtime efficiency is very good. You pay a lot and you get a lot.

This is also true for parallel programming. To write highly efficient parallel code you need skill and education. No silver bullet tooling will make this less "hard".

And here I see the irony. Faster CPUs were used to have lower educated devs delivering quicker. More parallel CPUs need higher skilled devs working slower to utilize the chip's full potential.

The point about skill is absolutely key.

Two types of engineer now exist: Those that are largely "code monkeys" implementing features using high level tooling and guard rails and those that are responsible for building that tooling and low level components. FWIW I've met plenty of engineers even from FAANG companies with fairly limited exposure to writing performant software.

Over time, the former bucket has grown significantly as barriers to entry have dropped but this has led to extremely bloated and inefficient codebases. Deployment patterns like micro services running on container orchestration platforms mean that it's easier to scale bad code horizontally pretty easily and these "high level frameworks" are generally "good enough" in terms of latency per-request. So the only time efficiency ever becomes a concern for most companies are when cost becomes an issue.

It'll be interesting to see how this all unfolds. I wouldn't be surprised if the huge incoming supply of unskilled engineers doesn't cause compensation to drop significantly in general.

To save money on infrastructure you need to pay your engineers more. Companies are choosing to hire cheaper engineers as they are the ones that are harder to replace.

The whole software vs hardware and developer vs runtime efficiency discussion is way more nuanced. No, the layers as they are currently are at least partially hindering productivity, because they all have bugs, rather painful limitations and are constantly changing under your feet. There is so much complexity, you don't have a chance to understand it (and the implications of it) completely from the click in a client's web browser all the way to the instructions executed on the server. This is not convenient and nobody (not even Google, Facebook and others) can handle the complexity, which manifests itself in bugs, weird behaviour, surprising security holes, other rare defects and more every day.

You don't want to manage memory manually unless you absolutely have to. Almost certainly, it is going to be way more demanding, you will make mistakes and the performance will not really be much better if you do whole system benchmarks for like 95% of applications. It is like using mining equipment and explosives to hang a picture on your concrete wall, it is just totally over the top. I am also not denying, there are use cases for something, where most of the responsibility is on you e.g. embedded or infrastructure software. Most people just aren't aware that they need the skill and understanding to reliably and most importantly responsibly wield it. In both cases, there is considerable room for better, more robust tools, and better methods/ practices and a great reduction in developer hubris.

Some have used better hardware for saving on development effort to some degree. There are applications that really need the extra performance to help users do their work in a more convenient way - not just developers. Some of the performance is lost due to systemic inefficiencies such as the web browser and most related technologies. E.g SVG rendering in web browsers is a mine field of bugs and bad performance, so you do the rendering yourself using canvas and JavaScript, which visually is the same thing but there is a lot more work for the developer and e.g. printing/ export into PDF (where you cannot just recalculate) is where you still kind of want the vector graphics capability in some form. Virtualization has enabled slicing of the cores to serve more customers with low cost and readily available compute. We also have way more users and different security expectations now than we used to in the past, so a single machine has to handle and check more stuff or we can use a single machine for stuff that would need a data centre or wouldn't be possible/ feasible before.

> More parallel CPUs need higher skilled devs working slower to utilize the chip's full potential.

Parallelism isn't so bad, you can use a functional style a lot of the time! E.g. Futhark, the accelerate framework, APLs....

Based on what I can tell... the programmers who made huge contributions to parallel compute are those programmers who grossly understood the hardware.

It didn't matter if they were Java programmers (Azul), Lisp Programmers (1980s CM2: Steel / Hille), GPU programmers, or C programmers. If you understood the machine, you figured out a fast and concurrent solution.

Reply on news.ycombinator.com