I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.
-
There’s a long history of people thinking that they’ve made programming easier by changing the syntax, or by making it not look like programming. That history is mostly a parade of embarrassments (COBOL! 4GLs!). One big subset of the current AI hype is just that mistake again — “vibe coding is programming in English!” — but now compounded by the nondeterminism of the tool.
Hogg’s thread correctly navigates around that mistake, focusing on •abstractions• instead of •syntax• as the problem.
@inthehands I just watched a video today of a presentation about LLM model collapse, and toward the end, the presenter talked about the distinction between semantics (abstraction) and syntax, and how LLMs fundamentally have to operate on syntax. But humans can handle semantics; semantics are the interesting bits.
Link for those interested: https://youtu.be/ShusuVq32hc
-
There’s a long history of people thinking that they’ve made programming easier by changing the syntax, or by making it not look like programming. That history is mostly a parade of embarrassments (COBOL! 4GLs!). One big subset of the current AI hype is just that mistake again — “vibe coding is programming in English!” — but now compounded by the nondeterminism of the tool.
Hogg’s thread correctly navigates around that mistake, focusing on •abstractions• instead of •syntax• as the problem.
@inthehands hypercard was such a great way to learn how control works as a child. it is a shame for sure.
for sure qbasic is good enough for user friendly... that was comprehensible to me when I was eight. I imagine most adults can handle it if they are actually curious.
LabView is a whole mess, they had a good idea but made it expensive and complicated in spite of itself.
You know, the most accessible programming language might be Max/MSP or PureData. Weird.
-
There’s a long history of people thinking that they’ve made programming easier by changing the syntax, or by making it not look like programming. That history is mostly a parade of embarrassments (COBOL! 4GLs!). One big subset of the current AI hype is just that mistake again — “vibe coding is programming in English!” — but now compounded by the nondeterminism of the tool.
Hogg’s thread correctly navigates around that mistake, focusing on •abstractions• instead of •syntax• as the problem.
On that topic, see my text in the “Software in Context” section at the bottom of this reading assignment from one of the courses I teach:
“Generating code is the easiest part of software development.”
-
There’s a long history of people thinking that they’ve made programming easier by changing the syntax, or by making it not look like programming. That history is mostly a parade of embarrassments (COBOL! 4GLs!). One big subset of the current AI hype is just that mistake again — “vibe coding is programming in English!” — but now compounded by the nondeterminism of the tool.
Hogg’s thread correctly navigates around that mistake, focusing on •abstractions• instead of •syntax• as the problem.
@inthehands Thank you! The real difficulty in programming was never the coding. It was in sufficiently and correctly understanding the problems you're trying to solve. If you understand what you want to achieve well-enough to write an English language description of everything, the coding pretty much follows.
There's a lot to be said for the dismal state of modern software dev practices these days. The "left-pad" debacle is an exemplar. As a security guy, don't let me get started on that!
-
On that topic, see my text in the “Software in Context” section at the bottom of this reading assignment from one of the courses I teach:
“Generating code is the easiest part of software development.”
There’s a second wrinkle to the OP’s critique beyond “abstractions should be better.”
The fundamental thing that makes programming hard is bridging the gap between ambiguous natural language and an unambiguous programming language. That’s hard.
That’s hard partly because the things that make a language unambiguous make such a language deeply unintuitive to humans, no matter how much it resembles English. BUT…
…the other reason it’s hard is that it forces you to decide •exactly• what you want.
-
There’s a long history of people thinking that they’ve made programming easier by changing the syntax, or by making it not look like programming. That history is mostly a parade of embarrassments (COBOL! 4GLs!). One big subset of the current AI hype is just that mistake again — “vibe coding is programming in English!” — but now compounded by the nondeterminism of the tool.
Hogg’s thread correctly navigates around that mistake, focusing on •abstractions• instead of •syntax• as the problem.
@inthehands speaking as someone who has spent his career in this particular cul-de-sac, the problem with english-like syntax is not that you can't write a good program in it; the problem is the very premise that you don't have to be a programmer to write a program.
i've had a long and moderately profitable career undoing the problems caused by such people.
i'm not sure this entirely puts LLMs in the same category. in some ways yes; in some ways no.
some of the folks vibe coding are programmers.
-
There’s a long history of people thinking that they’ve made programming easier by changing the syntax, or by making it not look like programming. That history is mostly a parade of embarrassments (COBOL! 4GLs!). One big subset of the current AI hype is just that mistake again — “vibe coding is programming in English!” — but now compounded by the nondeterminism of the tool.
Hogg’s thread correctly navigates around that mistake, focusing on •abstractions• instead of •syntax• as the problem.
@inthehands in Klein's interview with Jack Clark (Anthropic) at 06::00 he describes how you need to talk to Claude to get good results he is more or less describing the exact processes of most software engineering. I don't think this is a coincidence
There is software that is easy to develop, because the goal is completely understood; there is software that is much harder to develop because the goal is an evolving dialectic betwene user & developer. You can't make the 2nd one that much easier
-
@inthehands A lot of the vibecoding push also seems to miss that... being able to write more lines of code in less time has literally never been the actual bottleneck to productivity writing code.
The hard part - the part that requires thinking, planning, designing, figuring out obscure errors and navigating weird edgecases, etc. - all happens when you're not just typing out the solution you've come up with anyway.@inthehands Like - sure, the LLM can vomit out lines of code faster than a human, but it's code of lower quality (see: https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report ), that is generally harder to maintain, more error prone, increases technical debt, is less secure, and is generally less efficient than what a competent human could produce;
and it's already been established that number of errors even with human written code scales to lines of code pretty reliably, so, more lines is generally a bad idea either way. -
@inthehands A lot of the vibecoding push also seems to miss that... being able to write more lines of code in less time has literally never been the actual bottleneck to productivity writing code.
The hard part - the part that requires thinking, planning, designing, figuring out obscure errors and navigating weird edgecases, etc. - all happens when you're not just typing out the solution you've come up with anyway.@miss_rodent
Totally, see my subsequent post which I was gathering as you typed yours! -
@inthehands A lot of the vibecoding push also seems to miss that... being able to write more lines of code in less time has literally never been the actual bottleneck to productivity writing code.
The hard part - the part that requires thinking, planning, designing, figuring out obscure errors and navigating weird edgecases, etc. - all happens when you're not just typing out the solution you've come up with anyway.@miss_rodent @inthehands To bastardize an alleged Dijkstra quote: "Computer programming is as much about typing as classical music is about piano keys."
-
@miss_rodent
Totally, see my subsequent post which I was gathering as you typed yours!@inthehands Ah, fair, missed it because I was typing this (and re-finding the link).
-
There’s a second wrinkle to the OP’s critique beyond “abstractions should be better.”
The fundamental thing that makes programming hard is bridging the gap between ambiguous natural language and an unambiguous programming language. That’s hard.
That’s hard partly because the things that make a language unambiguous make such a language deeply unintuitive to humans, no matter how much it resembles English. BUT…
…the other reason it’s hard is that it forces you to decide •exactly• what you want.
@inthehands "The fundamental thing that makes programming hard is bridging the gap between ambiguous natural language and an unambiguous programming language." ... no, what makes it hard is the actual specifications are not really known no matter what language you use to describe them.
this is the entire motivation for the "agile" development pattern of the last 20-30 years.
without the cycle of specify-develop-use-respecify, you cannot approach the "true specification", and that's hard.
-
@inthehands Ah, fair, missed it because I was typing this (and re-finding the link).
@miss_rodent Oh, clear race condition — and I think you won the race! Just great minds etc.
-
There’s a second wrinkle to the OP’s critique beyond “abstractions should be better.”
The fundamental thing that makes programming hard is bridging the gap between ambiguous natural language and an unambiguous programming language. That’s hard.
That’s hard partly because the things that make a language unambiguous make such a language deeply unintuitive to humans, no matter how much it resembles English. BUT…
…the other reason it’s hard is that it forces you to decide •exactly• what you want.
To some extent, that’s the job of abstractions:
Maybe I don’t want to have to decide exactly what a button should look like, so I use the OS’s provided Button widget.
Maybe I don’t want to have to decide exactly how integer addition should work, so I use the language’s integer type.
In both cases, part of what the abstraction provides is “just do this thing the standard way.” But…
-
@inthehands speaking as someone who has spent his career in this particular cul-de-sac, the problem with english-like syntax is not that you can't write a good program in it; the problem is the very premise that you don't have to be a programmer to write a program.
i've had a long and moderately profitable career undoing the problems caused by such people.
i'm not sure this entirely puts LLMs in the same category. in some ways yes; in some ways no.
some of the folks vibe coding are programmers.
@fishidwardrobe @inthehands "the problem is the very premise that you don't have to be a programmer to write a program." -- well put. i have been known to rant about the concept of "tools for non-programmers" (to do the kinds of things done with programming), as in, what is a non-programmer? and don't they cease to be one once they successfully use such a tool, by definition?
-
There’s a second wrinkle to the OP’s critique beyond “abstractions should be better.”
The fundamental thing that makes programming hard is bridging the gap between ambiguous natural language and an unambiguous programming language. That’s hard.
That’s hard partly because the things that make a language unambiguous make such a language deeply unintuitive to humans, no matter how much it resembles English. BUT…
…the other reason it’s hard is that it forces you to decide •exactly• what you want.
@inthehands I’m saving this thread to explain why legalese is different from ambiguous language. And the same people who keep insisting that AI can do legal work unassisted are missing this very same point.
-
To some extent, that’s the job of abstractions:
Maybe I don’t want to have to decide exactly what a button should look like, so I use the OS’s provided Button widget.
Maybe I don’t want to have to decide exactly how integer addition should work, so I use the language’s integer type.
In both cases, part of what the abstraction provides is “just do this thing the standard way.” But…
…sometimes there’s •not• a clear standard way. Sometimes you need flexibility. For example, a lot of what makes UI programming hard is layout: you have to make your own very specific application look good on a variety of devices and screens, which means coming up with an •algorithm• for adjusting your design for all those different contexts.
That’s an intrinsically hard problem that requires design chops and nuance and contextual knowledge. Attempts to abstract the decisions out of that problem have been stubbornly unsuccessful. (How many layout engines are out there now?)
-
There’s a second wrinkle to the OP’s critique beyond “abstractions should be better.”
The fundamental thing that makes programming hard is bridging the gap between ambiguous natural language and an unambiguous programming language. That’s hard.
That’s hard partly because the things that make a language unambiguous make such a language deeply unintuitive to humans, no matter how much it resembles English. BUT…
…the other reason it’s hard is that it forces you to decide •exactly• what you want.
@inthehands personally I’m baffled by the idea that we haven’t made programming easier because we haven’t tried hard enough.
There are SO many people out there trying to make stuff simpler. Like… all of them. It’s one of the most universal motivations I can come up with among software developers. It’s just fucking hard!
-
…sometimes there’s •not• a clear standard way. Sometimes you need flexibility. For example, a lot of what makes UI programming hard is layout: you have to make your own very specific application look good on a variety of devices and screens, which means coming up with an •algorithm• for adjusting your design for all those different contexts.
That’s an intrinsically hard problem that requires design chops and nuance and contextual knowledge. Attempts to abstract the decisions out of that problem have been stubbornly unsuccessful. (How many layout engines are out there now?)
Vibe coding provides a tantalizing answer in that situation: maybe it’s too varied to •abstract•, but not too varied to •plagiarize• and call it good.
This is something subtly different from abstraction. It’s not “do this in the standard way.” Instead, it’s “just rip off whatever other people are doing right now.”
A lot of people really want that — and tbh, a lot of them are not wrong to want it. I personally love the craft of programming, but let’s face it, a lot of software out there just needs to look like everything else and be done with it.
-
Vibe coding provides a tantalizing answer in that situation: maybe it’s too varied to •abstract•, but not too varied to •plagiarize• and call it good.
This is something subtly different from abstraction. It’s not “do this in the standard way.” Instead, it’s “just rip off whatever other people are doing right now.”
A lot of people really want that — and tbh, a lot of them are not wrong to want it. I personally love the craft of programming, but let’s face it, a lot of software out there just needs to look like everything else and be done with it.
There have also been many past attempts to solve this class of “Don’t make me make choices” problem where there’s too many customization points to provide a tidy abstraction, but people just want something standard.
Some attempts look like snippet libraries, code generators. Other attempts look like Dreamweaver.
They’ve all suffered from problems that vibe coding recapitulates: speedy initial prototyping gives way to maintenance nightmares.
