[farmdawgnation]

I think you could also make the case that the existing abstractions aren't actually fully deterministic themselves. The compiler or interpreter may not behave as it should. Therefore, for any correct C code, there's probability that the GCC compiler will turn it into correctly formed machine code. But it may not!

Is the probability much higher with GCC? Sure. But it's still a probability.

[anon-3988]

I am sorry but this is an insane take. The probability of GCC going haywire with your special snowflake correct C code? Please. Have this EVER happen to you? I am not talking about the performance of the generated assembly because that IS flaky, but functionality wise I do not think so.

If people are so confident about the determinism of LLMs, or at least consider it on par with compilers, please ask it to compile your source code instead. Better yet, replace all your GNU utils with LLM instead. Replace your `ls` with `codex "prompt"`.

[elwebmaster]

I have done this, alias codex --yolo -p . It's very helpful not having to remember every odd command and its parameters. It's a bit more typing but I type faster than invoke and scan through man pages.

[hirako2000]

They are deterministic. Including in the way they fail.

[yuye]

People forget what determinism is.

Non-deterministic systems produce different output states given identical input states.

Even if a compiler's memory gets a one-in-a-million bitflip that produces a different output, it doesn't mean it's non-deterministic. It just means that the output state is different due to an external force changing the internal state.

An infinite loop will halt when the processor is powered off.

[farmdawgnation]

One of these days I'm going to learn the lesson that my tongue in cheek doesn't always come across on HN.

[vrighter]

if a compiler bug is found, it can be fixed. You can't fix an llm.