3 ms·

> People 'engineering' the system don't actually understand how it works. The problem is that the complexity of systems is growing beyond the capacity for peop

> People 'engineering' the system don't actually understand how it works. The problem is that the complexity of systems is growing beyond the capacity for people to understand in the first place, and the solution is to make it possible to do meaningful work in systems where people only understand a part of it at a time. In a way, software engineering is catching up with the rest of the world, which already operates that way. When you build a skyscraper or a bridge, maybe you have a structural engineer who understands how concrete and steel work, and you have a geotechnical engineer who understands how soil and sand work. My personal observation is that programming has long attracted people who like the kind of absolute certainty that you can have in smaller programs, where the behavior of programs is known to a mathematical certainty. If you're careful, you can build larger and larger programs this way... but at some point, the program or system is too large, and you are forced to think about things in statistical terms. You have to accept that your program has bugs in it. Some people who are otherwise brilliant programmers are simply too uncomfortable with the jump from the certainty you have in small programs to the known uncertainty you have in large programs & systems. It used to be you could make a decent living working within the certainty of small programs, but nowadays you are going to have to plug things together.

zozbot234 4y ago
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.
- klodolph 4y ago
  > 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.
  - inimino 4y ago
    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.
    - klodolph 4y ago
      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.
      - inimino 4y ago
        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.
- makeitdouble 4y ago
  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.
- thfuran 4y ago
  >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.
deleted 4y ago
[deleted]
inimino 4y ago
> The problem is that the complexity of systems is growing beyond the capacity for people to understand in the first place This is the argument, but it's a question whether this is a choice that we are making as a society and an industry, to not understand, and to choose technologies that abrogate the possibility of understanding, or to choose understanding, and focus all our efforts on enhancing the ability of understanding. To build bicycles for the mind, or bricks for software engineers to stack. It's a keen observation about the people who like certainty, but as systems get bigger these people can also often reason mathematically even about the uncertain cases, the statistical terms as you put it. There are even more people who would rather navigate politics than mathematics. Internal politics becomes more important in relative terms if everybody can agree that understanding the fundamentals is a waste of time.

zozbot234 4y ago

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.

klodolph 4y ago
> 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.
- inimino 4y ago
  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.
  - klodolph 4y ago
    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.
    - inimino 4y ago
      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.
makeitdouble 4y ago
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.
thfuran 4y ago
>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.

deleted 4y ago

[deleted]

inimino 4y ago

> The problem is that the complexity of systems is growing beyond the capacity for people to understand in the first place This is the argument, but it's a question whether this is a choice that we are making as a society and an industry, to not understand, and to choose technologies that abrogate the possibility of understanding, or to choose understanding, and focus all our efforts on enhancing the ability of understanding. To build bicycles for the mind, or bricks for software engineers to stack. It's a keen observation about the people who like certainty, but as systems get bigger these people can also often reason mathematically even about the uncertain cases, the statistical terms as you put it. There are even more people who would rather navigate politics than mathematics. Internal politics becomes more important in relative terms if everybody can agree that understanding the fundamentals is a waste of time.