I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.
-
…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. -
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)
