3 ms·

You have completely ignored the most important parts of that graph, which are the inputs and outputs at its boundaries. Recall that the halting problem, Gödelia

You have completely ignored the most important parts of that graph, which are the inputs and outputs at its boundaries. Recall that the halting problem, Gödelian undecidability and the Church-Turing correspondence place very hard limits on the ability of axiomatic systems to define the truth, even in an abstract sense. But we see this all the time in computer science and programming. Something which takes so long to compute that you can't distinguish between whether it's accomplishing useful work for a given input case or not has a completely different kind of conceptual characteristic than "discrete maths, graphs, boolean algebra, group theory..." There's less universality. More details. More arbitrary, capricious conditions that you nevertheless have to not just work around, but determine how to build resilient systems in spite of. It is almost cruel to taunt practitioners working around the hard, messy, ugly constraints of reality with the beautiful, elegant, and noble idea of not just conceptual mathematics, but the ability to immanentize it. But, this does little to solve the inherent messiness of the world that the software interacts with, and the messy things that people do which affect what it needs to do.

loup-vaillant 7y ago
Most of the mess we have in programs is of our own making. Our inability to properly address changing (not complex) requirements. And sure, the world is messy. But some things aren't worth automating. I've seen a talk about how the guy was writing a program to generate invoices. Turns out invoices are incredibly messy. The previous system was an overly complex brittle pile of code, that didn't quite work. His approach? Solve the common case first, and let human handle the messy bits. He started by something very simple, that could handle 60% of the invoices. Then 90%. Then 95%. Then 99%. The he stopped. With 99% of the invoices handled, he had a simple, solid system. The messy part was handled by humans, and they had the time to do so because 99% of the grunt work was taken away from them. Plus, they could trust it works because since those invoices were relatively simple, they could be automated reliably. I believe that approach can be generalised. As Mike Acton said: "solve the common case first". That I believe would work to "solve the inherent messiness of the world". Automate what you can, let humans deal with the rest. Or don't automate at all, just give tools & tricks so humans can work faster. Alternatively, we could adapt around computers. Before electricity, factories used to have a giant engine that powered everything through mechanical transmission. Wen electricity first came along, we did the same thing. But it turns out electricity is much easier to distribute at a small scale. So factories adapted, and instead of having a big engine at the centre, they started to have lots of small engines everywhere, close to where they were needed. I believe computers are similar: we started using them as glorified paper, but as we understand what they can do, we employ them in more efficient ways. But the interface of a computer (it can do anything!) is much more complex than that of an engine (it can rotate!). I believe we haven't found how to best make use of them just yet.
- yowlingcat 7y ago
  I really like your point about solving the common cases, but what you're getting at there is exactly what is the challenging part, not the mathematical part of it. How do you figure out what is the most important 60%, then 90%, then 95%, then 99%? How do you develop the judgment to know when 99% is good enough, or 95%, or 90%, or 60%? How does mathematics help you out with that? My point is that this judgment is the messy and valuable part. And to your point around the end, that you believe we haven't found how to best make use of them just yet -- I agree with that too, and that's why I think the work of writing software, or best practices, or sound theory is not fully established. To build good product does fundamentally require a pioneer spirit that can make compromises and negotiations and arrive at that sweet spot that's not quite 100% but high enough to be "good enough".

loup-vaillant 7y ago

Most of the mess we have in programs is of our own making. Our inability to properly address changing (not complex) requirements. And sure, the world is messy. But some things aren't worth automating. I've seen a talk about how the guy was writing a program to generate invoices. Turns out invoices are incredibly messy. The previous system was an overly complex brittle pile of code, that didn't quite work. His approach? Solve the common case first, and let human handle the messy bits. He started by something very simple, that could handle 60% of the invoices. Then 90%. Then 95%. Then 99%. The he stopped. With 99% of the invoices handled, he had a simple, solid system. The messy part was handled by humans, and they had the time to do so because 99% of the grunt work was taken away from them. Plus, they could trust it works because since those invoices were relatively simple, they could be automated reliably. I believe that approach can be generalised. As Mike Acton said: "solve the common case first". That I believe would work to "solve the inherent messiness of the world". Automate what you can, let humans deal with the rest. Or don't automate at all, just give tools & tricks so humans can work faster. Alternatively, we could adapt around computers. Before electricity, factories used to have a giant engine that powered everything through mechanical transmission. Wen electricity first came along, we did the same thing. But it turns out electricity is much easier to distribute at a small scale. So factories adapted, and instead of having a big engine at the centre, they started to have lots of small engines everywhere, close to where they were needed. I believe computers are similar: we started using them as glorified paper, but as we understand what they can do, we employ them in more efficient ways. But the interface of a computer (it can do anything!) is much more complex than that of an engine (it can rotate!). I believe we haven't found how to best make use of them just yet.

yowlingcat 7y ago
I really like your point about solving the common cases, but what you're getting at there is exactly what is the challenging part, not the mathematical part of it. How do you figure out what is the most important 60%, then 90%, then 95%, then 99%? How do you develop the judgment to know when 99% is good enough, or 95%, or 90%, or 60%? How does mathematics help you out with that? My point is that this judgment is the messy and valuable part. And to your point around the end, that you believe we haven't found how to best make use of them just yet -- I agree with that too, and that's why I think the work of writing software, or best practices, or sound theory is not fully established. To build good product does fundamentally require a pioneer spirit that can make compromises and negotiations and arrive at that sweet spot that's not quite 100% but high enough to be "good enough".