Most of Wolfram's discussion of "bugs" is not about the following situation:
You want a program that does X. So you think about what a program that does X should look like, and write a program that does what you think should produce result X, but maybe you made some mistakes.
but about the following, to my mind completely different, situation:
You want a program that does X. So you write a bunch of random short programs and after a while you find one that looks on small examples as if it's doing X. You use that one, but maybe actually it doesn't always work.
The key difference here is that in the first case you try to make there not be bugs by understanding what the program is doing and in the second you try to make there not be bugs by looking at the program's output.
(Perhaps some super-extreme practitioners of test-driven development might argue for something like the latter. Perhaps some AI-driven programming is uncomfortably close to it. But it's not, generally, how people have produced and debugged software.)
Wolfram kinda tries to justify this perspective by saying:
"Fundamentally the only way to make sure a program will always do what you want is to understand everything it can do. But there’s a kind of paradox implicit in that: if you can really understand everything your program can do that basically means the program is doing something computationally reducible, and you probably in the end didn’t actually need to run the program with all its steps to get the result you wanted."
but I think this is silly (and suspect it's the result of Wolfram trying to shoehorn his pet notion of "computational (ir)reducibility" into places where it brings no actual insight). It happens all the time that you write a program that (at least in principle) you understand completely, but that you don't know a much cheaper way to do it.
In this framing, clean coding abstractions gain a purpose beyond helping humans understand the code and actually help enforce that the end result is reasonably bug free. Building code out of understandable pieces can ensure that the whole thing is reasonably understandable.
While the article is focused on “low level” bugs, the key insight is that human understanding has limits, and bugs show up when the human is overconfident in their understanding, and unwilling to verify the code by running it on a sample of test cases. This does seem to help explain why “high level” bugs occur, where the reality somehow doesn’t match the assumption. Maybe a dependency is on the wrong version, a global variable isn’t initialized in certain cases, etc.
In a world of LLMs producing code that isn’t always understandable to humans, it does raise the question of how to enforce that AI code is bug free, and maybe forcing coding agents to stick to human abstractions is the missing piece.
Am I wrong to conclude that the statement by Google's VP of Security Engineering that "we simply must eliminate every software vulnerability on Earth" (before AI Agents find them) is not only stunningly ambitious, but doomed from the start?
Most of Wolfram's discussion of "bugs" is not about the following situation:
You want a program that does X. So you think about what a program that does X should look like, and write a program that does what you think should produce result X, but maybe you made some mistakes.
but about the following, to my mind completely different, situation:
You want a program that does X. So you write a bunch of random short programs and after a while you find one that looks on small examples as if it's doing X. You use that one, but maybe actually it doesn't always work.
The key difference here is that in the first case you try to make there not be bugs by understanding what the program is doing and in the second you try to make there not be bugs by looking at the program's output.
(Perhaps some super-extreme practitioners of test-driven development might argue for something like the latter. Perhaps some AI-driven programming is uncomfortably close to it. But it's not, generally, how people have produced and debugged software.)
Wolfram kinda tries to justify this perspective by saying:
"Fundamentally the only way to make sure a program will always do what you want is to understand everything it can do. But there’s a kind of paradox implicit in that: if you can really understand everything your program can do that basically means the program is doing something computationally reducible, and you probably in the end didn’t actually need to run the program with all its steps to get the result you wanted."
but I think this is silly (and suspect it's the result of Wolfram trying to shoehorn his pet notion of "computational (ir)reducibility" into places where it brings no actual insight). It happens all the time that you write a program that (at least in principle) you understand completely, but that you don't know a much cheaper way to do it.
In this framing, clean coding abstractions gain a purpose beyond helping humans understand the code and actually help enforce that the end result is reasonably bug free. Building code out of understandable pieces can ensure that the whole thing is reasonably understandable.
While the article is focused on “low level” bugs, the key insight is that human understanding has limits, and bugs show up when the human is overconfident in their understanding, and unwilling to verify the code by running it on a sample of test cases. This does seem to help explain why “high level” bugs occur, where the reality somehow doesn’t match the assumption. Maybe a dependency is on the wrong version, a global variable isn’t initialized in certain cases, etc.
In a world of LLMs producing code that isn’t always understandable to humans, it does raise the question of how to enforce that AI code is bug free, and maybe forcing coding agents to stick to human abstractions is the missing piece.
Am I wrong to conclude that the statement by Google's VP of Security Engineering that "we simply must eliminate every software vulnerability on Earth" (before AI Agents find them) is not only stunningly ambitious, but doomed from the start?
https://youtu.be/B_7RpP90rUk (at 3:00)