Live data from Hacker News

Towards a Theory of Bugs: The Ruliology of the Unexpected

writings.stephenwolfram.com

11–20 of 51 posts

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#11

'Ruliology' is an ignorant neologism, and whoever thought it up should be dropped down a well. Canonology is linguistically consistent without being obscure.

It's Wolfram-speak, so you'd want to drop Stephen if you're committed.

It's part of his GUT. You will likely become committed to the well when you encounter ruliad: https://writings.stephenwolfram.com/2021/11/the-concept-of-t...

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#12
post #3

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)

Kurt Godel says that you are correct.

Eh? I don’t see how Gödel’s results imply that.

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#13
post #3

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)

Shhhhh!

It may be the only way to keep us all employed.

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#14

'Ruliology' is an ignorant neologism, and whoever thought it up should be dropped down a well. Canonology is linguistically consistent without being obscure.

It's Wolfram-speak, so you'd want to drop Stephen if you're committed. It's part of his GUT. You will likely become committed to the well when you encounter ruliad : https://writings.stephenwolfram.com/2021/11/the-concept-of-t...

I went through a process of “what the fuck is this bullshit” to “ok, yes, that makes sense and can suffice for my multiverse worldview until someone writes a better one” when I read all his foundational essays on the topic.

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#15
At the risk of straying into forbidden metacommentary: look, I understand (and also feel) the temptation to have a go at Stephen Wolfram every time he posts something wacky, but… he’s just a guy with a fun hobby, isn’t he? Sure it’s all a bit eccentric and self-indulgent, but so are most hobbies, and in contrast to basically every other rich tech man he isn’t actually hurting anyone. Live and let live I reckon.

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#16

One of the frustrating things with the way Stephen Wolfram works is because he never actually defines anything it’s very hard to pin down what is actually interesting empirical science and what is data visualisation buggering around. Here, before he starts, how do we know that the bugs in the Turing machine implementation of f(n)=n+1 are in any way representative of bugs in a normal computation? He seems to be genera…

I see it as related to the Church-Turing thesis which is also a bit fuzzy but I think comes down to the conjecture that there is no physical computer which exceeds the Turing machine in capabilities. (Quantum computers, as we know them, don't count because they can be simulated by classical computers with sufficient space and time) One thing I find tragic about Wolfram is that he found his holy grail, Rule 30, at the…

The Church-Turing hypothesis I agree could be crisper (ie the definition of effectively computable is a bit complicated/weasely), but it actually says something quite concrete that I can understand and potentially falsify ie that a universal turing machine, the lambda calculus and general recursion can all "effectively compute" the same things. That seems reasonable, and I can check that something I can write in lambda calculus I can compute on a Turing Machine (simulated at least).

Whereas in stating the Principle of Computational Equivalence Wolfram says things like "... the evolution of weather systems can, in principle, compute the same things as a computer."[1]

Well, ... wtf? What does it mean to say the evolution of a weather system can compute something? Where do we even start on understanding this? I pick up a calculator and compute the volume of a cone. It's a sunny day outside. How do I "in principle" use that to check my calculation? It literally makes no sense whatsoever on its face as a claim but it is so slippery because of that "in principle" that it doesn't give me anything to hold onto that I could even test.

And that's before I even get started on the "underpants gnome" logical justification behind the claim, which seems to be:

1. Computers are complex

2. Weather is complex

3. Therefore they are "in some sense" equivalent

4.

5. Thus weather can "in principle" compute the same things as a computer.

I'm really not trying to misrepresent him, I'm just baffled.

[1] https://mathworld.wolfram.com/PrincipleofComputationalEquiva...

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#17
post #3

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)

It's my view of the Halting Problem that we've known for a surprisingly long time that eliminating all software bugs is mathematically impossible and should stop letting perfect get in the way of the good.

Especially with the more recent relative of the Halting Problem combined with the Church-Turing Theorem that found mathematical proof of a "0-day" sandbox escape in the Universal Turing Machine itself.

We have always lived in a house of glass. LLM agents automating trebuchets for rock throwing certainly seems like a bad idea to me and "let's simply eliminate all software vulnerabilities" an interesting bit of ostrich work (stick your head in the sand and hope it all gets better).

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#18
post #3

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)

It's my view of the Halting Problem that we've known for a surprisingly long time that eliminating all software bugs is mathematically impossible and should stop letting perfect get in the way of the good. Especially with the more recent relative of the Halting Problem combined with the Church-Turing Theorem that found mathematical proof of a "0-day" sandbox escape in the Universal Turing Machine itself. We have alwa…

This has little to do with the halting problem, because we can choose to not deploy programs (or subroutines) that we want to be terminating but can’t prove that they are terminating. And that goes for any undecidable problem. There is no application where we want the program to have a certain property where we would be forced to deploy a program where we can’t prove the property due to computational theory reasons.

No, the real issue is that for the most we don’t want to put the necessary effort into proving the relevant properties, because it’s costly and time-consuming, and we think we can live with the risk. The issue is not some theoretical inability to do so.

Re: Towards a Theory of Bugs: The Ruliology of the Unexpected

#20
post #18

Earlier quoted context omitted.

It's my view of the Halting Problem that we've known for a surprisingly long time that eliminating all software bugs is mathematically impossible and should stop letting perfect get in the way of the good. Especially with the more recent relative of the Halting Problem combined with the Church-Turing Theorem that found mathematical proof of a "0-day" sandbox escape in the Universal Turing Machine itself. We have alwa…

This has little to do with the halting problem, because we can choose to not deploy programs (or subroutines) that we want to be terminating but can’t prove that they are terminating. And that goes for any undecidable problem. There is no application where we want the program to have a certain property where we would be forced to deploy a program where we can’t prove the property due to computational theory reasons.…

We absolutely have pragmatic compromises and shortcuts for dealing with termination problems, but that doesn't mean we've solved the Halting Problem, it means we've adapted to coexistence with it. (And maybe we've coexisted with the Problem for long enough it feels like most of those adaptations are sufficient day to day, which makes it all the harder to appreciate the bugs that are always there we just mitigate enough to worry about them less.)

Potentially Infinite Loops are a great power. We've learned in most programming languages the "Uncle Ben lesson" that with such great power, comes great responsibility. In most programming languages we don't want to remove the ability to infinitely loop, because we might need that power, we work on ways to limit that responsibility (loop guards and timeouts and cancellations and teardowns). But it will likely always be possible to see some code spin in a loop we can't tell is accidentally infinite or just a loop with a lot more work than we expected. The infinite spin wait will always be a risk in our code.

I think it has a lot to do with the Halting Problem.

Post reply on HN