Giving a precise description of what the computer is supposed to do is exactly what programming is.
The more specific your requirements the closer you get to natural language not being useful anymore.
The more specific your requirements the closer you get to natural language not being useful anymore.
Any semi-competent AI Agent can do that with a plan you've written in 5 minutes.
I may be wrong, but it seems when people are talking about easy glue code, they’re talking about web services API, not OS API, not graphics or sound API, not file formats libraries,…
I know it's a piece of shit API done in the worst possible way on purpose (they don't want openness, but had to fulfill a law that mandates "openness") because I had previously tried to do it manually - twice. I ran out of whisky before I got anything done.
Sonnet _3.5_ almost one-shotted it with just the API "documentation" they had and access to Python and curl.
People have also hooked stuff into proprietary APIs on "smart" devices with zero documentation, just by having an Agent tirelessly run through thousands of permutations to figure it out.
Your suggestion that because languages have specified undefined behaviour, they are somehow not precise, makes little sense.
Otherwise, we're just saying that the precise parts of the language are precise, which isn't much of a differentiator since it's similarly true for all languages.
Grandparent said:
> The single best feature of any programming language is that it is precise.
C overtook a more precise language family because it has features other than precision that people cared about. Perhaps a better tradeoff of expressiveness and readability with precision.
Grandparent could be correct, and precision is the best feature of C, despite being less precise than ASM. And its better expressiveness nets out to a better overall programmer experience. I just wanted to point out that precision is something we do trade away for other things we want.
That's also where engineers come into play. They (and often only they) can judge how much precision is needed depending on the part of the system they are working on.
To me, the notion of precision isn't in any way related to whether any given statement is sound. It's about the behavior of the language for sound programs.
One could take the position that specifying precisely 'do whatever, I dunno' counts as perfectly precise. But then a language that was entirely UB would count as precise, which would be an odd position to hold, since you can't specify any behavior at all with it.
Now consider sound, in-spec C. Versus natural language.
Consider the subset of natural language that has strictly defined semantics. This would include, for example, talking in about the arithmetic of real numbers. The rest is not relevant to evaluating the precision of natural language.
Does that exclusion feel different in the natural language case? Why?
Perhaps it’s a matter of degree, not a categorical difference.
Not really, no. I just think we have better ways of expressing well-defined mathematical concepts like that than natural language when the recipient is a machine.
What do you use them for? For most AI users it's usually CRUD and I've never seen a web server or frontend in APL like languages.
The reason why programming is hard is because most languages force you to use a hammer when you need a screw driver. LLMs are very good at misusing hammers and most people find them useful for that reason.
If you use a sane dsl instead the natural language description of a problem is always more complex and much longer than the equivalent description in a dsl. It's also usually wrong to boot.
This is what algebra used to look like before variables: https://en.wikipedia.org/wiki/Archimedes%27s_cattle_problem#...
I don't think you will find anyone who can do better than an LLM at one shotting the prose version of the problem. Both will of course be wrong.
But I also don't think you will find an LLM that can solve the problem faster than a human with Prolog when you have to use the prose description of the problem.