Hacker News new | past | comments | ask | show | jobs | submit
kikdij | on: The foolishness of "natural language programming" (1978)
I don't think reproducibility is relevant, here. Otherwise, even your compiler example doesn't stand. No, machine code is not always the same after compiling high-level language. First, it depends on compiler. Clang and GCC won't produce the same output. Then it depends on the version of your compiler. GCC-9 and GCC-11 won't produce the same output. It obviously depends on the architecture too (arm vs x86), but even then, it depends on details about current configuration of the system you're building it on (CPU flags, hardening, etc). And then of course, there may be things randomized on purpose at each build, like randomized memory addresses to make the binary less exploitable.
ifdefdebug | parent
Yeah I should have been more precise. What I was suggesting is that the behavior of the machine code will be always the same after compiling (assuming no compiler bugs).

Anyway, my work process is as follows: I have the agent write the code, and describe it's purpose etc. via comments so another session can later pick it up easily without me having to explain everything again. That's what I commit. Sometimes I even look at the code :)

What else could I commit? At the current state of the art, I could commit the whole natural language session that lead to the code, instead of the code. When I later check this out in a fresh environment (without the artifacts the LLM putted out), I'd just load the most recent version of the conversation as an initial prompt. Or I could want to check out the conversation at a point two months ago and rebuild the program from there.

Would that produce a program with exactly the same behavior? I don't know. But if it doesn't, the essay's argument is not moot. Not yet ...

kikdij | root | parent
Interestingly, it _is_ possible to get the exact same output from the exact same input with LLMs. For example, with llama.cpp/llama-server, you can set the temperature to 0, define a seed for the randomizer, turn off caching so it doesn't mess with the inference, and you would get the exact same result every time. But it's largely an academic distinction, because 1/ change a letter in your prompt, and it's over… and you're certainly going to want to change your prompt at some point, and 2/ model publishers have recommendation about the temperature setting, usually between 0.7 and 1, so your reproducible results… might be terrible at solving actual problems.

That being say, I really like the idea of committing our prompts. I can see a possible future in which that would be our work: write precise specs so that you can generate the program again with an other model, in an other programming language, and get the same behavior. Which sounds a hell lot like… a RFC. :)

We may be the culprit here, by the way. Maybe the only thing missing is us taking "prompt engineering" more seriously. It would be specification writing, really, or protocol design. I think it might already be possible, from an experience I had. I made Codex write a POSIX vi implementation from POSIX ex/vi specs. It took it a week-end, but I now have a POSIX vi, with only added on top multilevel undo/redo and syntax coloration, and without the baggage and instability of nvi2, I'm an happy man. I've been using it for more than a month and still have to find a fault to its POSIX implementation (and there are _a lot_ of details in POSIX vi specs). I think models are already there, when it comes to implemented behavior predictability, it's just us who are not precise enough in our specifications.