Paul Cantrell
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.
Hrefna (DHC)
@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."
Paul Cantrell
@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 (DHC)
@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.
Paul Cantrell
@hrefna
Yeah, I don’t read the original thread that way.
I’m just hearing “modern tools could sure use a round of streamlining” and also “we should learn from Hypercard to make tools that are more accessible to newcomers.” Which are two different thoughts, and both modest and defensible claims.
And speaking, for example, as somebody who just used Docker in heat for the first time — yeah, there’s a clear example of something where a total revamp of the config format without fundamentally changing the core tool would have saved me some painful hours.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.