The best way I can explain it is that it's the same feeling when I upgraded from 56k dialup to cable broadband.

I don't see why it should be all that difficult. All you have to do is first find a library that implements a decent solution to the halting problem and you're off to the races.

Its funny because you can write a halting problem oracle by calling out to an LLM and have it return yes / no / not sure and get it to work reliably for almost all real code, like that is an entirely practical thing to do in 2026.

All we need now is some sort of program to evaluate halting problem oracles...

Wasn't the original proof something like "a program that loops indefinitely when the oracle says it will halt, and stops immediately if an oracle says it will not stop"? The whole point was the you can construct a contradictory program that cannot be decided by any oracle by its very nature.

```python

source_code = open(__file__, 'rt').read()

response = ask_llm("will this program halt, only answer 'yes' or 'no'?\n" + source_code)

will_halt = response == 'yes'

while will_halt:

   continue

```

You're right of course, LLMs provide a partial, unsound oracle.

The "halting problem is unsolvable" argument relies on the oracle not being able to output "not sure". But adding that option admits trivial oracles, like ones which output "not sure" for everything, so some are better than others.

The "real world" use most people have for halting oracles is as part of software safety, where if the checker outputs "not sure" you modify the software until the checker can decide if it halts.

Even if we had an answer to the halting problem, from a practical point of view, it's solving the wrong problem anyway. There's no point in distinguishing a function that would run forever from one that would exit after a century. They are both too slow.

Knowing that functions terminate is important for proof languages like Lean, where you often want to prove things without running the code at all. You're proving that one could, theoretically, calculate an answer, without actually calculating it.

It's an engineering vs science question, and we've solved the practical but not the theoretical. LLMs being non-deterministic is another one of those things.

You can use my script p-noteq-np.sh too if that helps.

I checked out your script but it looks like it's just a wrapper for ! ( p-eq-np.sh )

ya im partial to oracle.ts xD

Baking weights in makes a lot of sense for inference speed and power efficiency and has the added benefit of putting many end-users on the hardware refresh treadmill.

Yes, but how much would be a static Sonnet 3.5 be worth today? Its just about 2 years old. I'm not even going to ask about 3yo models like GPT4.

Okay, but the models today will be useful for a lot longer than sonnet 3.5. They're already more than capable to do nearly anything you throw at them given enough time and human assistance. The next step up is faster, cheaper and better user experience. I have only had two instances where I needed to reach for 5.6 sol and that only totalled around $2.7 in api costs.

I would imagine it would look something like this:

Ground breaking/novel research -> SWE -> day to day assistant conversations -> chat support bot...

The first one might not make sense but it gets them the pipeline for when it does make sense in the future. Plus for a lot of things using LLMs they'd be fine with older tech, especially if running it was even faster and cheaper.