This is actually my biggest gripe with vibecoding. The single best feature of any programming language is that it is precise. And that is what we throw out?! I favor of natural language, of all things?! We're insane!
It turns out an awful lot of precision (plenty for many things) lives in library and web APIs, documentation, header files and dependency manifests. Language can literally just point at it without repeating it all. Avoidance of mistake through elimination of manual copying in things like actuarial and ballistics tables was what the original computers were built for.
API Glue is the easy and boring part in programming. Nobody really enjoys wiring API A to API B, combining the results and using API C to push it forwards.
Any semi-competent AI Agent can do that with a plan you've written in 5 minutes.
I would love to see an AI try to make sense of GTK API.
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 used Sonnet 3.5 over a year ago to decrypt a notoriously shitty local government API to get data out of meetings, votes and discussions.
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.
Historically we almost entirely moved from ASM to C, a language with lots of undefined behavior, because precision is not the most valued feature of languages.
It's the existence of UB that is the reduction in precision. A language without UB is more precise, in my view, than one that has UB. I don't know if this a conventional view. But being able to write parsable, compiler-receivable code that does 'uh, whatever', feels like a reduction in precision to me compared to a language that does not have that property.
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.
UB is about edge cases that a compiler should not be enforced to check against and an occurrence is always a bug. You don't necessarily need a precise description of the actual faulty behavior.
Right. The language has well-formed expressions with no defined meaning in terms of machine instructions. My claim is that this is a reduction in precision compared to assembly language.
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.
I don't completely follow the analogy, but I do follow the argument. High precision regarding the requirements often is not needed and that's exactly where LLMs shine.
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.
Could you please explain why you feel that having UB makes C less precise than asm?
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.
There are syntactically well-formed C programs that are not sound programs because their behavior is undefined. Or, rephrasing: a subset of all parseable C programs contain 'do whatever, I dunno'. I interpret this as a lack of precision.
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.
The exceptions that prove the rule. When your programming language is built up of singular Unicode characters with specific meanings, of course that's faster than typing out in English what you want.
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.
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.
Using esoteric programming languages doesn’t suddenly make it true for the majority of development, which is web apps, CRUD stuff, some data science, etc.
Who is using APL and J these days? I guarantee 90+% of Claude users are developing CRUD web apps, or something similar. Your point about algebra is a non sequitur to what people are actually developing for these days.