Computer scientists generally struggle with intensional contexts, ie., the sense in which sqrt(4) isnt (1 + 1); or the sense in which I believe(that sqrt(1101) ~10) but I dont believe(that 10^2 ~1101)

So they replace everything with extensional contexts, ie., in/out sets -- where things are replaceable by their values. And then use the machinery of very simple mathematics to analyse the situation.

In ML, consider comparing two classifiers extensionally, so that two classifiers "are the same" if they partition some input data exactly the same vs., declaring them different if they do so by means of some differing internal representation.

Since intensional contexts are the archetypal feature of mental representations, they're rarely analysed well by computer scientists.

I think its easy for us to think we can understand what a program is going to do when we're dealing with high level abstractions. I think if we really came to grips with everything the program is doing all the way down to the hardware level, we might have less confidence that we can predict what its going to do with 100% accuracy every time, even in the case of supposedly simple programs.

It's because he's an intellectual con artist.

At least he isn’t abusing some existing term.

That's not the point of the essay. The point he's trying to make here is the same one underlying every Stephen Wolfram essay, which is "I am very smart".

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 very beginning of his project and ever since he's found that every family of rules that he's look at that is sufficiently powerful has something like Rule 30 -- but always a bit more complex, complicated and not quite so beautiful, in fact often outright ugly...

... so he jumps into this sort of thing and samples of some of a ruliad, finds the usual things he finds in every ruliad, gets excited about it and thinks he has a "theory" and then moves on to something else and most of us are scratching our heads.

Kurt Godel says that you are correct.

Isn't that also the point of your comment only much lazier?

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. <don't worry about step 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...

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.

Shhhhh!

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

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).

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

I'm sure there are unwarranted attacks on Stephen Wolfram out there in the public discourse, but what I see is people criticizing his ideas, which is always fair game.

I actually think criticism is especially important in the case of high-profile public figures like Wolfram. Far more people in the general public know about him and his highly speculative and unproven theories, while at the same time thousands of serious scientists publishing important and influential work go relatively unrecognized.

I appreciate this opinion, it's very generous

At least not automatically. From an algorithmic standpoint it seems likely to be undecidable. But let us not look too closely at what was really a throwaway remark.

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.

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.

An infinite loop doesn’t mean that you can’t prove whatever property you want to prove about your program, if you’ve designed it for that. The limitations coming from undecidability don’t really affect our everyday applications. Unless your application is exactly to determine whether another arbitrary program will halt, that is. But that’s not what the vast majority of software whose bugs we might be concerned about is about.

“We can’t write bug-free software due to the halting problem anyway” is an incorrect argument.

You can't prove a program completed successfully if you can't prove a program even completes at all.

I don't know what properties you think people are trying to pragmatically prove about arbitrary programs but "did the program complete successfully" will always be an important, pragmatic property in software development. Especially in the pragmatic world where so much of our software is chaining smaller programs together to solve a task.

I'm saying we can't write perfectly bug-free software because of the Halting Problem and the inability to prove any given loop will not be infinite until running that loop. Perfect remains the enemy of the good and we certainly write a lot of "bug-free-enough" software without worrying about the Halting Problem day-to-day. But if you are saying the world needs to write perfectly bug free code starting tomorrow because LLMs will find all the vulnerabilities and sandbox escapes the Halting Problem is absolutely one of the reasons we can't ever provably hit that "perfect" target. We still need to find "good enough" or we give up on software development altogether and that's not what I'm advocating. Perfect is the enemy of the good. Mathematically perfect provably does not exist. Software will always have bugs, especially in the world with a threat model of active brute force machines.

SolutionNotFound is a perfectly valid return case for my Algo. I start two threads, one searches for a solution, second one terminates the first after one second, if it is still running.

How in the world does the halting problem enters into the picture if my program is bug free or not?

I think you have slightly misunderstood the halting problem. There is no computer program H that, for every program P, determines whether P halts. This does not imply that for some particular program Q there is no proof that it halts. In fact in the setting where programs do not take input there is always such a proof (just a trace of the program running to completion). And there are many valid proofs of theorems like "For all x, Q(x) halts" for particular Q. Consider, for example, the case where Q has no control flow at all!

You have a serious misunderstanding of the consequences of the undecidability of the Halting Problem. The Halting Problem says you can not prove the precise halting behavior in every problem. Precise and every are very important qualifiers.

If you sacrifice precise and widen it to: "Halt" and "Maybe run forever, but might just take longer than the age of the universe and is thus irrelevant for actual programs we might choose to run" then it is decidable for every problem.

Every means that there exist programs, in the infinity of all programs, that can not be proven. It does not mean that no program can be proven. Programs that are 10^8000000 instructions long that are intentionally obfuscated count in every. Human-designed programs that humans want to be correct and are reasonably sure are correct are extremely well-behaved in comparison and their provable termination can almost always be reasoned about.

Generally speaking, human-designed programs are almost always implicitly being constructed in the space of programs that will terminate (possibly relative to a event loop). At every step of the process you only extend using provably terminating constructions. Few humans will have a loop condition like: "Terminates if the Goldbach Conjecture is true" which is one of those sorts of things that makes it hard to prove termination. Just stay away from unproven conjectures in your loop conditions and you will probably be fine.

I think it's more that I lean into some of the corollaries that directly factor computation time into account. There is no computer program H that for every program P determines whether P halts faster than running P.

You cannot find/prevent every case of an infinite loop at design time/compile time if the only way to determine a complex enough control flow converges towards halting is to run the full program in a live environment.

But again, the context is not about humans trying very hard to stick to problems in "terminating space" when writing software, but about LLMs with no such compunctions/boundaries finding inputs that break "terminating space assumptions". (Whether or not you also believe that LLMs are capable of staying within the lines of "terminating space" when generating code.)

Generally speaking, yes, humans want to design programs as best they can in the world of safely terminating applications. Humans aren't perfect at it today, given practical real world data such as CVE databases. Trying to hope humans become perfect to safeguard the world against LLMs like the Googler quote way above is the thing I find futile. Humans aren't going to magically get perfect. We need good enough solutions more than we need perfect solutions. The fear is that LLMs can greatly outpace humans in breaking "good enough" than humans can keep up in building "good enough".

You can prove a program is correct and terminates for all inputs and, absent a hardware or other assumption vulnerability that breaks the abstract machine assumptions, there would be no inputs that "break" anything. In fact, almost any human-designed program that is correct and terminates would not just be provable, but "easy" to prove algorithmically (in the theoretical sense, in a practical sense existing techniques are insufficient to prove complex programs).

Even ignoring isolation guarantees that could generically prevent unbounded escalation for arbitrary programs, you can just reject anything that is not "easy" to prove. Humans are really dumb, so anything that is not directly proven or easy to prove automatically is almost certainly not correct, so you can just err on the safe side and just reject them if you care about global correctness.