I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.
-
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 In my career I went from tools/toolkits with slow release cycles and good documentation to continuous release cycles with little to no documentation. Towards the end of that progression, stackoverflow became an essential resource for cut-and-paste solutions to common problems. 1/2
-
…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 you’re articulating this in a very clear way. Over the past thirty years, I’ve coded projects in everything from Ada, Java, OCaml, Perl, PHP to Ruby, including using frameworks or libraries or scaffold-generators. I discover over and over again that the next language or framework is *great* for making it easy to solve problems until you get outside of its focus. Then suddenly, all that elegance or hidden complexity becomes handcuffs.
-
@inthehands In my career I went from tools/toolkits with slow release cycles and good documentation to continuous release cycles with little to no documentation. Towards the end of that progression, stackoverflow became an essential resource for cut-and-paste solutions to common problems. 1/2
@inthehands I'm out of the game now, thankfully, but I see LLM tools being used by non-vibe coders in that same way, except that it's a firehose of code that's harder to vet. I see the so-called vibe coders differently, operating beyond the limit of what they can really understand and just hoping it works out. 2/2
-
@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 )
@miss_rodent @inthehands Oh sorry, I bastardized it quite a bit heh. The original one attributed to him is something like "Computer science is as much about computers as astronomy is about telescopes".
-
@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.@inthehands reducing boilerplate makes sense - and things like better libraries, better abstractions, better systems to reuse code other people already wrote so you don't have to reinvent 30 wheels every time you start a new project, etc. can help reduce that.
But - if you're programming, your decisions are the main thing that actually adds value to what you're making, from the larger scale of what language, libraries, etc. to use, down to what decisions you make in implementation details -
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'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.
-
@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.
@inthehands Vibe coding is appealing like pulling the lever on a slot machine is appealing. Everybody wants a magic button that does what they mean. Unfortunately, that doesn't exist, and probably never will. I think there are much greater and more mundane forces at play here.
-
@inthehands reducing boilerplate makes sense - and things like better libraries, better abstractions, better systems to reuse code other people already wrote so you don't have to reinvent 30 wheels every time you start a new project, etc. can help reduce that.
But - if you're programming, your decisions are the main thing that actually adds value to what you're making, from the larger scale of what language, libraries, etc. to use, down to what decisions you make in implementation details@inthehands This is kinda just how 'knowledge work' works, generally?
Making (informed) decisions is, largely, what the job is.
Which is exhausting, and difficult, and easy to burn out on, and there is always a temptation to try to cut corners, especially if you're overworked and underpaid or feel alienated from your work - look at the general state of academia, for example - but to 'solve' the problem of needing to make decisions, is really to remove the part of it that actually matter -
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 have enjoyed this thread so much... thank you.
I'm less convinced that there's a clear separation between thinking and typing. The history of programming language design is all about that: how do you create an expressive medium for people to *think with* in a particular domain. It's not just making it more like English. People who have the right language in their hands can do really amazing things.
To stay with the example, HyperTalk was really good because it was *so* fit-to-purpose. It didn't do anything but manipulate this tiny object model. Alan Kay bitched about it: that the smallness of the object model itself was the problem... but you and I and everyone who loved HyperCard felt differently.
-
@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)
@inthehands i wasn't disputing that "a lot of [what makes UI programming hard is layout]". Layout is hard.
Just that the dfficulty really doesn't have much to do with the (relatively new) desire to make layouts work on mobile-sized devices as well as 72" HiDPI displays, though that likely adds to the problems.
-
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 " better solutions to the “Don’t make me decide! Just do something typical!” problem." ... the answer in the Hypercard case was "this is how Hypercard does it". That was pretty awesome for new programmers. But if I had tried to write Ardour with Hypercard's limitations on UI, I'd have gone crazy. So this is a bit nuanced. "Something typical" nearly always comes with a "in this context" clause, and that can make for wildly different solutions/outcomes.
-
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
When we do make it easier, we stop calling it "programming". Spreadsheets come to mind. -
@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 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. -
I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.
Jonathan Hogg (@jonathanhogg@mastodon.social)
I will say one thing for generative AI: since these tools function by remixing/translating existing information, that vibe programming is so popular demonstrates a colossal failure on the part of our industry in not making this stuff easier. If a giant ball of statistics can mostly knock up a working app in minutes, this shows not that gen-AI is insanely clever, but that most of the work in making an app has always been stupid. We have gatekeeped programming behind vast walls of nonsense.
Mastodon (mastodon.social)
Gotta say I'm glad things on the street have calmed enough that you can post computer science stuff again.
-
@miss_rodent @inthehands Oh sorry, I bastardized it quite a bit heh. The original one attributed to him is something like "Computer science is as much about computers as astronomy is about telescopes".
@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) -
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 "Don't make me decide" is often synonymous with "I've a messy problem and I just want to make it disappear with some of that IT fairy dust".
Standard solutions can often make problems very visible, and that's orthogonal to the sentiment above. For the people wanting their problems to disappear, a LLM coding assistant probably looks like a large pool of magic you can drown your problems in. That can be very attractive, I think.
-
@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.
