This is dumb and "obvious" but the advantage of the layers of abstraction is that a lot of people share layers of abstraction. So the issues need to only be found once, so to speak

Of course you lose specialization and you end in "the image decoder supports some weird format which allows RPC " territory but most software can barely handle the high level bugs.

It's pretty crazy how something like Django exists, powers thousands and thousands of websites, but has perhaps less than a thousand contributors overall? Less than one person per project. Now that's an amazing payoff!

> how on Earth our technology is working as well it does, considering there are layers upon layers of abstractions which could have a lot of issues which are either worked around or just not hit in particular application.

Our technology works as well as it does because of these layers upon layers of abstraction. That's the only way you are going to be able to construct something with a few billion components and a fighting chance at avoiding unwanted interference between parts. The amazing thing is how often we get it just right, not that there are super rare edge cases that were not taken into account during the abstraction process that lead to bugs.

Every leaky abstraction is a bug in the waiting, all it takes is for someone to focus on the discrepancy with enough time, effort and resources thrown at it it might lead to a crash or an exploit.

Also note that it is not as if we don't know that caching is a hard problem to get right, it is one of the three explicitly mentioned in the 'there are two things hard about computing' joke.

I feel like the more I learn, the more convinced I become that computing is because we build stupidly impenetrable abstractions that keep us from shooting our feet. Yet I can't shake the feeling that we are leaving so much room for optimization on the table.

That's true, but optimization is always an exercise in economy. If the money is there someone will do the optimization, for instance, in the Bitcoin mining arms race you could see the writing on the wall for CPUs long before the jump to GPU's, FPGA's and eventually ASIC's.

In mobile phones I always expected battery life to cause a resurgence of things like assembly programming but it never happened, people are happy to recharge their phones. I wonder what would happen if someone introduced a smartphone OS based on old school principles jacking up the battery life to 5 days or so.

It could still happen. Mobile phones have been riding the CPU speed improvement gravy train for a decade or so, but there are signs that this is coming to an end like it did for desktop CPUs.

There will be increased demand for faster software when the hardware stops getting faster.

Optimization is vertical integration. Guess which mobile phone manufacturer is best placed to pull that off!

I have exactly same experience.

And it is somewhat reinforced by the kind of "software problems" that only manifests themselves on new hardware revision or even production batch. And the causes range from wrong chip assembled in production (sot23-6, same package marking, but dual jfet really does not work as replacement for LDO), through various signal integrity issues ("how did you determine, that this makes 100R mictrostrip?" "It looked right and makes the board look right", somehow the "right-looking" diffpair on 6+ layer board does not work on 2 layer backplane) to real sillicon errata that either can (MSP430G-series USCI interrupt handling, you will not even trigger that when using TI provided sample code) or can not (Microchip's various pin routing issues, some Intel Atom erratas and such) be sanely worked around in software.