I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.
-
@ianbicking @inthehands Usually when we try making programming easier, we make some other part of it harder. Like, we went all-in on scripting languages, but it turns out strict type checking is really useful in maintenance. Same problem with vibe coding; it's easier to create, but now that you need to fix bugs and ensure it's secure and update new APIs..
Garbage collection is great, until your program gets large enough that you actually need to care about memory because you're using so much.@ianbicking @inthehands Programming computers is difficult and messy because *we're* difficult and messy. Humans. We change our needs and we require programs to adapt to changing usage and we poke and prod at the program in ways that was never intended and we want programs to match our cultural desires and then suddenly we want the opposite of our cultural desires (because schismogenesis) and now we need to enshittify it because capitalism and now there's a license change so we need to..
-
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
When I read or hear people talking about LLM coding, I see people who don't want the "programming" part of development at all. They want to decide *what* to make, not the details around *how*.And indeed, they treat the models as workers, with themselves as the manager or product owner. They don't want to deal with the code any more than an architect wants to deal with rebar and PVC pipes.
-
@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!
@lerxst @inthehands I don't think this is fully true. A user can get something usable from "Write a Django app to track maintenance records for my cars. Target latest Python and deploy to Heroku. Ask questions until you have enough information to implement, then proceed unattended until all tests pass."
Completing this requires some idea of what's going on but not nearly the time or experience necessary to do it all by hand. I use software every day worse than what that would generate.
-
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.
the other reason it’s hard is that it forces you to decide •exactly• what you want.
Yes.
So, I came to cs from philosophy and I want to say something that a lot of programmers have dismissed as silly:
Programming isn’t hard because of the syntax. It’s hard because you have to be precise or pay the price.
In philosophy, especially analytic philosophy, the price is exacted by anal retentive logicians who smell invalidity and pounce - fallible, wet-ware compilers. And when you’ve survived their hazing programming languages are a comforting, warm embrace.
BTW, the hardest hard thing for me has always been hooking up all the systems: os, libraries, apis, services, keys, etc. these aren’t programming but the prerequisitees.
-
@lerxst @inthehands I don't think this is fully true. A user can get something usable from "Write a Django app to track maintenance records for my cars. Target latest Python and deploy to Heroku. Ask questions until you have enough information to implement, then proceed unattended until all tests pass."
Completing this requires some idea of what's going on but not nearly the time or experience necessary to do it all by hand. I use software every day worse than what that would generate.
@lerxst @inthehands While I don't think this mitigates or really relates in any way to the ethics and labor power issues, I do think the use of these tools is a bit more than smoke and mirrors. The way we build software has a lot of unnecessary complexity that has no real value to anyone, yet persists because we haven't figured out a better way. Tools that allow a sketch-level instantiation of an idea are understandably popular.
-
@theorangetheme @inthehands Ah okay, I think that might be a misattribution? I can find a lot of claims *that* he said it, but, have yet to see any for *where* he said it?
(It fits his vibe, though)@miss_rodent @inthehands Wouldn't surprise me heh. This is definitely the intersection of lore and apocrypha, as Einstein famously said.
-
@inthehands
When I read or hear people talking about LLM coding, I see people who don't want the "programming" part of development at all. They want to decide *what* to make, not the details around *how*.And indeed, they treat the models as workers, with themselves as the manager or product owner. They don't want to deal with the code any more than an architect wants to deal with rebar and PVC pipes.
Frank Lloyd Wright said the architects greatest tool was the hammer. He used to go on-site and destroy whatever the builders did "wrong" when building his designs.
(His innovations weren't familiar to the builders.)
-
@lerxst @inthehands While I don't think this mitigates or really relates in any way to the ethics and labor power issues, I do think the use of these tools is a bit more than smoke and mirrors. The way we build software has a lot of unnecessary complexity that has no real value to anyone, yet persists because we haven't figured out a better way. Tools that allow a sketch-level instantiation of an idea are understandably popular.
@lerxst @inthehands I've studied cases like HyperCard, Excel, Visual Basic, etc... I don't know what the path will be but I do think eventually we'll have something better than the current state of things. A world where ordinary non-programmers can build a rough cut of a tool with an audience of one, at low cost, and move on with their lives. Kind of the empowering spirit of the old micros and BASIC.
-
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.
@inthehands also worth noting is the incentive structures in place in many companies. If an engineer can produce something that enables the PM to say “we got X project complete on time and under budget”, and the manager to say “look how productive my team is”, and the sales people to say “this looks great in a demo, I can sell this”, and the CFO to say “our revenue numbers look good this quarter” — then it’s a job well done. Things like correctness and tech debt have never been valued lower, and the corporate cycles have never been so compressed.
LLMs are very well-suited to that job.
-
Frank Lloyd Wright said the architects greatest tool was the hammer. He used to go on-site and destroy whatever the builders did "wrong" when building his designs.
(His innovations weren't familiar to the builders.)
@rayckeith @inthehands
Though I guess he was reacting to design aspects such as a roofline angle or railing height; not whether the sink drain connectors were up to code. -
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.
“Don’t make me decide! Just do something typical!”
The hard part there is, as you pointed out with ui programming, the world is messy and filled with varying degrees of mutually incompatible plumbing.
I guess what I’m asking is, is there a better wrt to this objective?
Edit: turns out loads of people had already expressed this basic idea but with much more clarity, nuance, and context. This is a great place to hang out. Thanks for your threads.
-
@inthehands I'm just not ready to believe that the AI hype is so big because programming is too hard. I think we definitely do need easier and more creative interfaces to machines, but I don't see the regular people who would be helped by them flocking to AI. If anything, the people most excited seem to be the people who ostensibly already know how to program, or the very online techbros on websites like HN.
@theorangetheme @inthehands I think “ostensibly” is the key word there. People who know programming is possible, but haven’t been able to advance their own skills to the level they’d like. (Probably more due to their situation than any inability.)
-
@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.This is a really good description of the problem. Engineering is a much higher order practice than what vibe coding does.
-
@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!
@ianbicking @inthehands I don’t think that’s the idea being expressed here, but also, that’s not what the money goes to; programmers have tried plenty, but people who hire programmers don’t care. There are zillions of half-finished not-quite-usable prototypes of good ideas that never get fully developed
-
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.
@inthehands I think the focus on abstractions in the original is missing the mark and giving the AI more credit than it deserves.
As you say: what makes programming hard was never the syntax, and IMO it was also _never the boilerplate_. Boilerplate might make it obtuse, but it doesn't make it hard. Because as you say: there are a lot of things that solve "boilerplate" at different levels.
We've seen eighty million tools on solving this for you. Some of them even work. They all have tradeoffs.
Tools like HyperCard were just amazing though. Encouraging exploration, easy entry. I wish tools like OpenDoc had caught on more as well.
I fully agree we need to learn from vibe coding what people find appealing about it. I just draw the line at a different point than "the abstraction layer programming works on is too difficult."
-
@inthehands I think the focus on abstractions in the original is missing the mark and giving the AI more credit than it deserves.
As you say: what makes programming hard was never the syntax, and IMO it was also _never the boilerplate_. Boilerplate might make it obtuse, but it doesn't make it hard. Because as you say: there are a lot of things that solve "boilerplate" at different levels.
We've seen eighty million tools on solving this for you. Some of them even work. They all have tradeoffs.
Tools like HyperCard were just amazing though. Encouraging exploration, easy entry. I wish tools like OpenDoc had caught on more as well.
I fully agree we need to learn from vibe coding what people find appealing about it. I just draw the line at a different point than "the abstraction layer programming works on is too difficult."
@hrefna I think "the abstraction layer programming works on is too difficult" perhaps makes a bit of a strawman of the thread I quoted. It’s more like “better abstractions would lower the barrier to entry and increase the portion of work that is useful work.”
-
@hrefna I think "the abstraction layer programming works on is too difficult" perhaps makes a bit of a strawman of the thread I quoted. It’s more like “better abstractions would lower the barrier to entry and increase the portion of work that is useful work.”
@inthehands I don't disagree that I was being somewhat uncharitable/facetious, but I also don't agree with the core of the thesis. Or rather, I don't agree that the impact is so high that it requires a paradigm shift in thinking.
It's kind of like my old thing on tools:
1. Someone looks at the state of the world and goes "this is all too complex! We need to solve this complexity somehow!"
2. They invent a tool. It's fast! It's amazing! Development is now so easy!
3. Everyone starts using it. It's the future. We talk about it in conferences.
4. People realize it needs to work for more than 4 people at a time, that it needs to be secure, that it is still sitting on top of a database that needs structure, it has extensions for different use cases, it needs to be upgraded, etc.
5. It gets to be a nightmare to work with unless you've got a lot of experience or have been doing it for a while.
6. GOTO 1.This is where tools like BPEL, rules engines, WSDLs, and certain DSLs live. All of which can have their place, even, and be very useful (as I've said before: get a rules engine off the shelf or reinvent one, those tend to be your two options).
But they also didn't end up lowering the barrier to entry overall because of the other problems on the stage: maintainability over time, security, performance, the cost of adding features, etc all sneak up on you.
-
@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!
@ianbicking “We haven’t made programming easier because we haven’t tried hard enough”
…is superficially similar to but not at all the same thought as…
“We’ve allowed barriers to entry to build up because we haven’t prioritized removing them, or even understanding them”
“We’ve failed to learn from successful past attempts to remove those barriers”
“We’ve allowed our routine development practices to fill with ‘walls of nonsense’ that could be abstracted away”
-
@inthehands
When we do make it easier, we stop calling it "programming". Spreadsheets come to mind.@jannem
Agreed, and I’d love to see more people trying to learn from what works about Excel + Hypercard that they function(ed) so well as entry points to programming -
@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.
@eniatitova
There’s another thread to be written on how legalese is in fact not at all like code, despite both of them being formed under pressure to avoid ambiguity. (Programmers frequently thing legal language is like code, or fails because it is not, and do a big faceplant in short order.)
