I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.
-
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 This is similar to a discussion I had recently. Not only are LLMs showing that we gatekept programming (no, it's not democratizing tools, it's just showing how bad our current ones are!) but also some programmers who are able to write that code turn to LLMs for boilerplate. This, LLMs "solve" as well.
But common is that, in order to develop an app or anything, you need to know basically a lot of "useless" knowledge. Things that actually are not relevant to the program domain but just... cruft. Boilerplate are the "magic numbers" of software development. You just need to know (or be willing to type it).
And yes, we suck at building proper abstractions. In algebra, when we abstract from simple operations to groups and rings we look for patterns in behavior, for categories, for similarities in operations such that we can group them together. Then, we can discuss derived properties of the system, independent of the specifics of the underlying operation.
A proper abstraction would you to build a UI w/o caring about the intrinsics because you only specify what is relevant to your level of abstraction.
1/x
-
@inthehands This is similar to a discussion I had recently. Not only are LLMs showing that we gatekept programming (no, it's not democratizing tools, it's just showing how bad our current ones are!) but also some programmers who are able to write that code turn to LLMs for boilerplate. This, LLMs "solve" as well.
But common is that, in order to develop an app or anything, you need to know basically a lot of "useless" knowledge. Things that actually are not relevant to the program domain but just... cruft. Boilerplate are the "magic numbers" of software development. You just need to know (or be willing to type it).
And yes, we suck at building proper abstractions. In algebra, when we abstract from simple operations to groups and rings we look for patterns in behavior, for categories, for similarities in operations such that we can group them together. Then, we can discuss derived properties of the system, independent of the specifics of the underlying operation.
A proper abstraction would you to build a UI w/o caring about the intrinsics because you only specify what is relevant to your level of abstraction.
1/x
@inthehands Now, we build lots of leaky abstractions (i.e., we suddenly /do/ need to know magic stuff) and to combat this, we build code generators (even before LLMs!). But code generators are brittle and leaky abstractions age badly. Further, both often tend to "hide" the wrong information or, if i want to override a specific thing, make it hard to tear down a level of abstraction, selectively.
But I also want to give credit where credit is due. Building abstractions of comprehensively-defined ideas of mind is much easier than what we try to do in software engineering. How do "abstract" different screen sizes, formats, cut-outs, color systems, refresh systems (e-ink), etc. in a way where the user "doesn't need to know"? To a big degree this is futile. We will.keep "reinvesting" the wheel because we are thrown into a world that evolves. It's similar to how evolution scientists try (and fail) to categorize (and thus: abstract) the "trees" of our evolution... but evolution happening in real-time. Building an app may still be less complicated than building a car, but the details of the how have changed within a month more than within years for cars. We're literally sprinting and trying to keep up with abstractions.
2/x
-
@inthehands Now, we build lots of leaky abstractions (i.e., we suddenly /do/ need to know magic stuff) and to combat this, we build code generators (even before LLMs!). But code generators are brittle and leaky abstractions age badly. Further, both often tend to "hide" the wrong information or, if i want to override a specific thing, make it hard to tear down a level of abstraction, selectively.
But I also want to give credit where credit is due. Building abstractions of comprehensively-defined ideas of mind is much easier than what we try to do in software engineering. How do "abstract" different screen sizes, formats, cut-outs, color systems, refresh systems (e-ink), etc. in a way where the user "doesn't need to know"? To a big degree this is futile. We will.keep "reinvesting" the wheel because we are thrown into a world that evolves. It's similar to how evolution scientists try (and fail) to categorize (and thus: abstract) the "trees" of our evolution... but evolution happening in real-time. Building an app may still be less complicated than building a car, but the details of the how have changed within a month more than within years for cars. We're literally sprinting and trying to keep up with abstractions.
2/x
The "soft" nature of software is our curse. Because we can change everything on a whim, capitalism demands us to. Change, evolve, revolutionize – and tear down the careful abstractions we just built because they've become legacy, they don't fit the new world. Unfortunately, LLMs will only speed up this process.
Maybe it's time to think hard about what we can actually abstract... and what we need to solve differently. And where the only thing we're left with is changing the system.
Final thought though: While we can see all the above as a problem and LLMs do address it (I don't want to say "solve"), is it so? I think almost everyone who actually wants to /build/ an app is able to. But most do not want to build, they want to /have/ an app. So we're less gatekeeping the building knowledge but mostly the creation of new "stuff". And maybe... that's not actually as bad? We've seen the waste lands of plastics and new apps are the same, but for software. Do we need another app that does the same, slightly differently?
3/x
-
The "soft" nature of software is our curse. Because we can change everything on a whim, capitalism demands us to. Change, evolve, revolutionize – and tear down the careful abstractions we just built because they've become legacy, they don't fit the new world. Unfortunately, LLMs will only speed up this process.
Maybe it's time to think hard about what we can actually abstract... and what we need to solve differently. And where the only thing we're left with is changing the system.
Final thought though: While we can see all the above as a problem and LLMs do address it (I don't want to say "solve"), is it so? I think almost everyone who actually wants to /build/ an app is able to. But most do not want to build, they want to /have/ an app. So we're less gatekeeping the building knowledge but mostly the creation of new "stuff". And maybe... that's not actually as bad? We've seen the waste lands of plastics and new apps are the same, but for software. Do we need another app that does the same, slightly differently?
3/x
Don't get me wrong, I think everyone should go out there and build things. But I'm talking about individuals. Not big corporations who create new apps as if they're free to print and discard. This is fast fashion, but for software. Single-use plastics. Now we've given them a tool to do this faster. They don't care about the quality, how soon it'll fall apart. LLMs fit there perfectly.
The counter idea would be to for us to come together and not only build slowly. But to own the platforms (and thus the speed of the software evolution, we don't need to jump on every redesign bandwagon), and to collaborate: Because when capitalism's answer to "this product is good, I want to make it better" is "let's build it ourselves, but add the feature, our answer must be to converge and get together.
4/x
-
Don't get me wrong, I think everyone should go out there and build things. But I'm talking about individuals. Not big corporations who create new apps as if they're free to print and discard. This is fast fashion, but for software. Single-use plastics. Now we've given them a tool to do this faster. They don't care about the quality, how soon it'll fall apart. LLMs fit there perfectly.
The counter idea would be to for us to come together and not only build slowly. But to own the platforms (and thus the speed of the software evolution, we don't need to jump on every redesign bandwagon), and to collaborate: Because when capitalism's answer to "this product is good, I want to make it better" is "let's build it ourselves, but add the feature, our answer must be to converge and get together.
4/x
@inthehands
Unfortunately, this is hard. Especially since, for some time, the big corpo world will be more shiny than what we build. They got more resources. It'll be hard to give up my high-end laptop that's very tied into a foreignly controlled platform for something that may be mine... but slow or even less secure. Or the free cloud CI. Many things broke the soviet union (rightfully so, it was just as authoritarian than the next state), but a big part was the comparison with the shiny west. Even if it's shiny on the surface mostly, and the bloq products may be more durable and repairable because they evolve slower.One big aspect that may motivate us, however, to not betray the cause, to keep building slow, is not solely the ownership of the product we built. But that what we build is a by-product of what we learn.
5/x
-
@inthehands
Unfortunately, this is hard. Especially since, for some time, the big corpo world will be more shiny than what we build. They got more resources. It'll be hard to give up my high-end laptop that's very tied into a foreignly controlled platform for something that may be mine... but slow or even less secure. Or the free cloud CI. Many things broke the soviet union (rightfully so, it was just as authoritarian than the next state), but a big part was the comparison with the shiny west. Even if it's shiny on the surface mostly, and the bloq products may be more durable and repairable because they evolve slower.One big aspect that may motivate us, however, to not betray the cause, to keep building slow, is not solely the ownership of the product we built. But that what we build is a by-product of what we learn.
5/x
@inthehands Yes, the abstractions may be leaky... but when I read a Wikipedia article about something specific, I often don't get "the" answer straight away either, even if it's "there". Because it's impossible to build such an abstraction that every possible question can be answered by a surgical cut of the view of Wikipedia containing precisely the fitting answer. Instead I go down the rabbit hole, clicking on links, and gathering knowledge even of things I didn't intend to learn. And I think that's beautiful.
And yes, I may not want to know the OS intrinsics when I just want a button. But do I actually... not /want to know/? Or do I just /don't have the time to learn/ because there's the dayjob, the laundry to do, I need to cook and do tax returns. Because I bet, most people want to know, want to learn. They're just too exhausted.
The abstractions aren't the issue. Neither the boilerplate. They're learning opportunities. But we've come to shun them and see them as a bad thing. Because learning is what I do for myself, to increase *my* value. Not the value of the company, not the value of the deliverable.
6/6
-
@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?
@chrisamaphone @inthehands well, by one definition technically yes, but IMO a programmer *thinks like a programmer*, and i've met folks who were paid to program in a 4gl, had written tens of thousands of lines of code, *and never did that*.
things i find myself saying out loud at work:
- if it works 80% of the time, it doesn't work
- if you have to change the program every week to make it work, then…
- if it doesn't work when two people run it at the same time, then…
- if no-one but you can make sense of the code, then…
- if even you can't remember why that bit does that, then…
- if it's got the same bit of code copied and pasted three times in a row in it, then…
- if your variables are all "a1,a2,a3" and especially if you get to "a65", then… -
@chrisamaphone @inthehands well, by one definition technically yes, but IMO a programmer *thinks like a programmer*, and i've met folks who were paid to program in a 4gl, had written tens of thousands of lines of code, *and never did that*.
things i find myself saying out loud at work:
- if it works 80% of the time, it doesn't work
- if you have to change the program every week to make it work, then…
- if it doesn't work when two people run it at the same time, then…
- if no-one but you can make sense of the code, then…
- if even you can't remember why that bit does that, then…
- if it's got the same bit of code copied and pasted three times in a row in it, then…
- if your variables are all "a1,a2,a3" and especially if you get to "a65", then…@chrisamaphone @inthehands oh! this particular 4gl has an OOP variant, because it's still stumbling on like a zombie. it's quite good.
i've never used it commercially, because, getting these people to understand OOP concepts? LOL no ROTFL
-
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 mean, it's bad enough that many programming languages are not themselves unambiguous. *stares grumpily at C* -
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 Dijkstra's criticism of natural language programming continues relevant. But I think the problem is exactly what we're seeing with chatGPT; people just want to minimize intellectual labor, just tell the electronic servant what to do and have it done. And maybe sometimes that's okay but it's a little like asking a genie to grant your wish—you may not get what you think you want.
-
@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.
@mirth @inthehands Hypercard and VB were empowering (loved them both!), but they also were a thing in a much simpler world of either pre-popularized internet, or at least one where your whole financial life wasn't available in a few clicks.
These tools CAN do useful things, but I think it would be nuts for a newbie to programming to something like throw a Django app on the web. They're not in a place to diagnose even the most basic of security issues.
-
@mirth @inthehands Hypercard and VB were empowering (loved them both!), but they also were a thing in a much simpler world of either pre-popularized internet, or at least one where your whole financial life wasn't available in a few clicks.
These tools CAN do useful things, but I think it would be nuts for a newbie to programming to something like throw a Django app on the web. They're not in a place to diagnose even the most basic of security issues.
@lerxst @inthehands Oh I largely agree. I think this is a failure of system design, there is no reason why the functional equivalent shouldn't be doable today. The success of companies like Zapier and SmartSheet hints at one version. Browsers and the early Apple + Google phone OS sandboxing models have some thinking about security model. It must be possible to provide something tolerably easy with few footguns and no subscription attached.
-
R relay@relay.infosec.exchange shared this topic
-
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.
Because some of the replies, while good, have wandered a bit off the rails, please consider:
1. “We should study and learn from how Hypercard lowered the barrier to entry to programming.”
2. “Hypercard or something like it would be unsuitable for many / most modern applications.”
Please note that both these things can be true (and both are in my view). Upthread I’m pushing for (1). And…
-
Because some of the replies, while good, have wandered a bit off the rails, please consider:
1. “We should study and learn from how Hypercard lowered the barrier to entry to programming.”
2. “Hypercard or something like it would be unsuitable for many / most modern applications.”
Please note that both these things can be true (and both are in my view). Upthread I’m pushing for (1). And…
…crucially, I’d argue that (2) is •not• the only cause of (1): narrowing the problem space was not the only thing Hypercard did that lowered the barrier to entry. There have been other tools that also aggressively narrowed the problem space yet did not catch on the way Hypercard did.
Narrowing the class of problems is •part• of Hypercard’s barrier-removing success, to be sure! For example, I mentioned UI layout upthread. Hypercard stacks aren’t resizable. Layout involved absolute positioning, end of story (mostly).
-
…crucially, I’d argue that (2) is •not• the only cause of (1): narrowing the problem space was not the only thing Hypercard did that lowered the barrier to entry. There have been other tools that also aggressively narrowed the problem space yet did not catch on the way Hypercard did.
Narrowing the class of problems is •part• of Hypercard’s barrier-removing success, to be sure! For example, I mentioned UI layout upthread. Hypercard stacks aren’t resizable. Layout involved absolute positioning, end of story (mostly).
Still, there are some other things Hypercard did we’d do well to study, even with full-scale tools. Off the top of my head:
- It richly rewarded unguided exploration. Unsuccessful experimentation had a way of leading to paths forward, not just dead ends.
- Much of it worked by direct manipulation: if you want the thing there, you put the thing there. (Unity and Godot both sort of kind of do some descendant of this, but not with the same discoverability and transparency.)
- There was a rich library of good starting points, modifiable examples.
- An empty but functioning new project had essentially zero boilerplate. You didn’t have to have 15 files and hundreds of lines of code to get a blank page.
- Its UI made it easy-ish for newcomers to ask “What can I do with this thing here?” Modern autocomplete and inline docs kind of sort of approximate this, but in practice only for people who already have tool expertise.
- HyperTalk (the programming language) is tricky to write (it’s a p-lang), but it’s remarkably easy to read. You can peer at it with very limited knowledge and make educated guesses about its semantics, and those guesses will be mostly correct. (HyperTalk syntax tends to get the most attention when people talk about this, I think at the expense of the other things above.)
