I commented elsewhere, but that doesn't mean it's not deterministic. Deterministic means given the same input it gives the same output. Compilers can still have bugs and generate the wrong code. But so long as given the same input it generates the same wrong output, it is still deterministic.
Compilers can generate wrong output in many different ways. And they're all analogous to the same ways that a sophisticated LLM can generate wrong outputs.
The compiler relies on:
* Careful use of the ENV vars and CLI options
* The host system, or the compilation of the target executable (for cross-compiling)
* It relies on the source code specifically
How is this really different from careful prompt engineering, and an extensive proposal/review/refine process?
They are both narrowing the scopes and establishing the guardrails for what the solution and final artifact will be.
> proposal/review/refine process
This is essentially what a sophisticated compiler, or query optimizer (Postgres) does anyway. We're just doing it manually via prompts.
And none of that means it isn't non-deterministic. Compilers still satisfy the, given the exact same environment and input, you get the same output. It doesn't matter the number of inputs. So long as f(3, 2) always gives 5, it's deterministic. Doesn't matter what f(x,y) does so long as it always gives the same output per input. LLM generation does not do this. If given f(3,2), sometimes it says 5, sometimes 6, sometimes 1001, sometimes 2.
And we are talking compilers, not query optimizers, so I don't really care what they do.
> How is this really different from careful prompt engineering, and an extensive proposal/review/refine process?
So different that those concepts don't even exist.
I don't have to carefully prompt my compiler in case it might misinterpret what I'm saying. My compiler comes with a precisely specified language.
I never, ever, review the output of my compiler.