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 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.
-
…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?)
@inthehands " 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"
UI programming was hard before we got mobile devices. This is not why UI programming is hard (though agreed, it makes it harder if desktop+mobile is in your design remit).
-
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.
Still, per the OP’s point, we should learn from what it is about vibe coding that really appeals to people.
The OP makes the case that we should find better abstractions and better idioms to fight boilerplate. Yes. And that we should look to things like Hypercard that reward inexperienced experimentation and exploration. Very very yes.
The latter part of my thread argues that we should •also• search for better solutions to the “Don’t make me decide! Just do something typical!” problem. I don’t know what that looks like, but we should take that problem more seriously.
-
@inthehands " 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"
UI programming was hard before we got mobile devices. This is not why UI programming is hard (though agreed, it makes it harder if desktop+mobile is in your design remit).
@PaulDavisTheFirst
You’ve trimming “a lot of” from my sentence, a phrase which was doing a lot of work.(I personally had been doing UI programming for 20-some years before my first experience with mobile device in J2ME, so I do hear you)
-
@miss_rodent @inthehands To bastardize an alleged Dijkstra quote: "Computer programming is as much about typing as classical music is about piano keys."
@theorangetheme @inthehands Hm, not sure what that quote is from? Wouldn't be surprised if it's Dijkstra, he wrote -a lot-, and had a bunch of interviews, speeches and presentations, etc., I've read... quite a lot of it, but, not all of it, and definitely don't remember everything from it, lol.
( https://www.cs.utexas.edu/~EWD/welcome.html has an archive )
-
Still, per the OP’s point, we should learn from what it is about vibe coding that really appeals to people.
The OP makes the case that we should find better abstractions and better idioms to fight boilerplate. Yes. And that we should look to things like Hypercard that reward inexperienced experimentation and exploration. Very very yes.
The latter part of my thread argues that we should •also• search for better solutions to the “Don’t make me decide! Just do something typical!” problem. I don’t know what that looks like, but we should take that problem more seriously.
@inthehands I don't know that there can be a solution to that problem, that doesn't introduce new problems.
If you're writing code - the decisions you make about what to use and how *is* the task. Not the typing-it-out part.
In the same way that a writer's job is not to type/write, but to make decisions about what to write, and how to write it, etc.
The typing it out part is just getting the decision you should already have made out of your head and into the world.
