Comment by dsr_
18 days ago
It's not a programming language if you can't read someone else's code, figure out what it does, figure out what they meant, and debug the difference between those things.
"I prompted it like this"
"I gave it the same prompt, and it came out different"
It's not programming. It might be having a pseudo-conversation with a complex system, but it's not programming.
> It's not a programming language if you can't read someone else's code, figure out what it does, figure out what they meant, and debug the difference between those things.
Well I think the article would say that you can diff the documentation, and it's the documentation that is feeding the AI in this new paradigm (which isn't direct prompting).
If the definition of programming is "a process to create sets of instructions that tell a computer how to perform specific tasks" there is nothing in there that requires it to be deterministic at the definition level.
> If the definition of programming is "a process to create sets of instructions that tell a computer how to perform specific tasks" there is nothing in there that requires it to be deterministic at the definition level.
The whole goal of getting a computer to do a task is that it’s capable to do it many times and reliably. Especially in business, infrastructure, and manufacturing,…
Once you turn specifications and requirements in code, it’s formalized and the behavior is fixed. That’s only when it’s possible to evaluate it. Not with the specifications, but with another set of code that is known to be good (or easier to verify)
The specification is just a description of an idea. It is a map. But the code is the territory. And I’ve never seen anyone farm or mine from a map.
I think I 100% agree with you, and yet the other day I found myself telling someone "Did you know OpenClaw was written Codex and not Claude Code?", and I really think I meant it in the same sense I'd mean a programming language or framework, and I only noticed what I'd said a few minutes later.
> "I gave it the same prompt, and it came out different"
I wrote a program in C and and gave it to gcc. Then I gave the same program to clang and I got a different result.
I guess C code isn't programming.
Note that the prompt wasn't fed to another LLM, but to the same one. "I wrote a program in C and gave it to GCC. Then I gave the same program to GCC again and I got a different result" would be more like it.
> Then I gave the same program to GCC again and I got a different result" would be more like it.
This is a completely realistic scenario, given variance between compiler output based on optimization level, target architecture, and version.
Sure, LLMs are non-deterministic, but that doesn't matter if you never look at the code.
5 replies →
If there is no error on the compiler implementation and no undefined behavior the resulting program is equivalent and the few differences are mostly just implementation defined stuff which are left to the compiler to decide (but often gcc and clang do the same). The performance might differ also. It’s clearly not comparable to the many differences you can get from LLM’s output.
It just depends what level of abstraction you're willing to pretend doesn't matter.
gcc and clang produce different assembly code, but it "does the same thing," for certain definitions of "same" and "thing."
Claude and Gemini produce different Rust code, but it "does the same thing," for certain definitions of "same" and "thing."
The issue is that the ultimate beneficiary of AI is the business owner. He's not a programmer, and he has a much looser definition of "same."
5 replies →
The output will conform to the standard & it will be semantically equivalent. You're making several category errors w/ your comparison.
> You're making several category errors w/ your comparison.
I don't think I am. If you ask an LLM for a burger web site, you will get a burger web site. That's the only category that matters.
22 replies →
Prompting isn't programming. Prompting is managing.
Is it?
If I know the system I'm designing and I'm steering, isn't it the same?
We're not punching cards anymore, yet we're still telling the machines what to do.
Regardless, the only thing that matters is to create value.
Interesting how the definition “real programming” keeps changing. I’m pretty sure when the assembler first came, bare metal machine code programmers said “this isn’t programming”. And I can imagine their horror when the compiler came along.
I think about those conversations a lot. I’m in the high power rocketry hobby and wrote my own flight controller using micropython and parts from Adafruit. Worked just fine and did everything I wanted it to do yet the others in the hobby just couldn’t stand that it wasn’t in C. They were genuinely impressed then I said micropython and all of a sudden it was trash. People just have these weird obsessions that blind them to anything different.
How did you come up with this definition?
All programming achieves the same outcome; requests the OS/machine set aside some memory to hold salient values and mutate those values in-line with mathematical recipe.
Functions like:
updatesUsername(string) returns result
...can be turned into generic functional euphemism
takeStringRtnBool(string) returns bool
...same thing. context can be established by the data passed in, external system interactions (updates user values, inventory of widgets)
as workers SWEs are just obfuscating how repetitive their effort is to people who don't know better
the era of pure data driven systems is arrived. in-line with the push to dump OOP we're dumping irrelevant context in the code altogether: https://en.wikipedia.org/wiki/Data-driven_programming
[flagged]
I'm not sure I will ever understand the presentation of "inevitable === un-criticizable" as some kind of patent truth. It's so obviously fallacious that I'm not sure what could even drive a human to write it, and yet there it is, over and over and over.
Lots of horrifying things are inevitable because they represent "progress" (where "progress" means "good for the market", even if it's bad for the idea of civilization), and we, as a society, come to adapt to them, not because they are good, but because they are.
>"I prompted it like this"
>"I gave it the same prompt, and it came out different"
1:1 reproducibility is much easier in LLMs than in software building pipelines. It's just not guaranteed by major providers because it makes batching less efficient.
> 1:1 reproducibility is much easier in LLMs than in software building pipelines
What’s a ‘software building pipeline’ in your view here? I can’t think of parts of the usual SDLC that are less reproducible than LLMs, could you elaborate?
Reproducibility across all existing build systems took a decade of work involving everything from compilers to sandboxing, and a hard reproducibility guarantee in completely arbitrary cases is either impossible or needs deterministic emulators which are terribly slow. (e.g. builds that depend on hardware probing or a simulation result)
Input-to-output reproducibility in LLMs (assuming the same model snapshot) is a matter of optimizing the inference for it and fixing the seed, which is vastly simpler. Google for example serves their models in an "almost" reproducible way, with the difference between runs most likely attributed to batching.
8 replies →