Programming in the large does not necessarily involve uncertainty. A CPU microarchitecture or an OS are large, complex systems, but we expect them to perform reliably. Well-understood modularity boundaries are of course quite important for this. It's only when we expect systems to do things that they weren't designed for at the outset (such as keeping private data from being accessed via side-channels, if you're designing a modern CPU) that real problems exist.
>microarchitecture or an OS are large, complex systems, but we expect them to perform reliably. Well-understood modularity boundaries are of course quite important for this
We expect them to mostly approximate correct operation but know that there are bugs at pretty much every level. See Spectre, rowhammer, dirty pipe, etc.
> Programming in the large does not necessarily involve uncertainty.
Can you provide some reasoning to support this, or elaborate? This seems obviously false to me, maybe I don't understand what you're trying to say here.
When we have goals like wanting to keep private data from being accessed via side-channels, there are some major problems preventing you from being certain about it. You are probably not going to be certain that you know which data is private and which data is not private. You are probably not going to be able to enumerate all possible side-channels--new ones keep getting discovered. Then, suppose you've found a way to mathematically express what data is private and what side channels are and what it means to leak data, do you expect to somehow apply formal methods to the entire damn system?
Maybe someday. Not today.
Today, you apply defense-in-depth strategies. Mitigations upon mitigations upon mitigations. You try to keep any one bug from bringing down the whole system. You do analyses of different types of bugs and see how they affected the system, and figure out ways to make the system more resilient.
There is a radical idea discovered in the 70s, that you can just buy computers and run your own code on your own machines. Rumour has it that some still practice this ancient art.
If you're happy with the experience of using computers in the 1970s and 1980s, you are of course free to continue using computers that way. Meanwhile, all the people who want to build a "quick web app" are building on top of an enormous tech stack which they don't understand. Your application will be affected by everything from the way that your TCP packets get routed around the world, to the arcane rules which your browser uses to decide when to repaint the page, to the byzantine rules for text segmentation and script-specific shaping engines used to let end-users interact with "plain text" content.
The question is whether this is necessary. I agree with you that people are doing all of those things. It's not, strictly speaking, necessary, it's just a popular choice.
A CPU does error check and handle cases where it ends in a state that was not intended. OS do that in spades, and we wouldn’t accept an OS that didn’t embrace it has bugs and stuff go wrong.
At that scale, the question isn’t wether there’s behavior we didn’t understand, it’s how to try to make the best deal with them.
