I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.
-
@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.) -
@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 @fishidwardrobe
People keep accidentally creating programming languages in disguise, and it never ceases to be a source of amusement and disaster. -
@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.
@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.
-
@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.
@inthehands @hrefna
The thing is, there are reasons we don't build apps in hypercard today. or even websites. It's tailored pretty specifically at small, personal, experimental usage. Which is great, we need that kind of thing.But we also need languages and frameworks and etc that are tailored toward big, enduring, public usage. Because we have lots of big, enduring, public services.
One can't be the other. This is, as usual, a social problem masquerading as a tech problem. We don't need more perfect frameworks. We need to socially validate that those small, personal, temporary things are good and valuable as they are. That there are thing which are made worse by trying to make them universal. And that those small, personal, temporary things should be built with the appropriate tools for that goal.
-
@inthehands @hrefna
The thing is, there are reasons we don't build apps in hypercard today. or even websites. It's tailored pretty specifically at small, personal, experimental usage. Which is great, we need that kind of thing.But we also need languages and frameworks and etc that are tailored toward big, enduring, public usage. Because we have lots of big, enduring, public services.
One can't be the other. This is, as usual, a social problem masquerading as a tech problem. We don't need more perfect frameworks. We need to socially validate that those small, personal, temporary things are good and valuable as they are. That there are thing which are made worse by trying to make them universal. And that those small, personal, temporary things should be built with the appropriate tools for that goal.
@jenniferplusplus @hrefna
People •did• build big, enduring, publicly used production apps out of Hypercard. Myst was a Hypercard stack in its original form!Your point is a good one that a low barrier to entry is inherently in tension with flexibility, generality, and robustness. I still think we’ve failed to learn what Hypercard could teach us.
-
@inthehands @hrefna
The thing is, there are reasons we don't build apps in hypercard today. or even websites. It's tailored pretty specifically at small, personal, experimental usage. Which is great, we need that kind of thing.But we also need languages and frameworks and etc that are tailored toward big, enduring, public usage. Because we have lots of big, enduring, public services.
One can't be the other. This is, as usual, a social problem masquerading as a tech problem. We don't need more perfect frameworks. We need to socially validate that those small, personal, temporary things are good and valuable as they are. That there are thing which are made worse by trying to make them universal. And that those small, personal, temporary things should be built with the appropriate tools for that goal.
@inthehands @hrefna To the extent that there is a technology component to this social problem, it's that it's so hard to take that small scale personal thing and make it span across a few locations and devices. People should be able to make their little recipe books or w/e, and then open it on their phone and also their computer, at work and at home.
But it turns out the simplest way to do that is to host a big thing on the public internet, with a database. And that's where things start to go off the rails
-
@inthehands @hrefna To the extent that there is a technology component to this social problem, it's that it's so hard to take that small scale personal thing and make it span across a few locations and devices. People should be able to make their little recipe books or w/e, and then open it on their phone and also their computer, at work and at home.
But it turns out the simplest way to do that is to host a big thing on the public internet, with a database. And that's where things start to go off the rails
This was one of the core messages at a distributed systems conference I was at now… too long ago.
"If your problem can be solved on a single computer, it is probably trivial."
This isn't to knock single user apps (AutoCAD is somewhere between a divine relic and an eldritch evil the first time you use it), but rather to point out that the moment you open up a socket and connect it to the outside world, life gets more complex.
Even more so if you deal with what I was talking about earlier, which is that a lot of this doesn't _scale_ cost effectively unless you have a big database sitting on the public internet somewhere.
Even if all you want to do is make a distributed little recipe book.
-
@jenniferplusplus @hrefna
People •did• build big, enduring, publicly used production apps out of Hypercard. Myst was a Hypercard stack in its original form!Your point is a good one that a low barrier to entry is inherently in tension with flexibility, generality, and robustness. I still think we’ve failed to learn what Hypercard could teach us.
@inthehands @hrefna I'm sure we could learn a lot more from hypercard. We should start with the recognition that we did actually learn a great deal from hypercard. It was an educational toy, it let people experiment with hypertext and simple logic at a time when hardly anyone knew what those things were.
It's not so different than Legos.
-
@inthehands @hrefna I'm sure we could learn a lot more from hypercard. We should start with the recognition that we did actually learn a great deal from hypercard. It was an educational toy, it let people experiment with hypertext and simple logic at a time when hardly anyone knew what those things were.
It's not so different than Legos.
tbh I credit HyperCard with a lot of my development as an engineer, I even wrote some basic LAN applications in it back in high school. it was great for that experimentation and learning.
But for as much nostalgia as I hold for it and as much as I wish it had a modern descendent to play with some days, I wouldn't write modern applications with it (maybe something like OpenDoc) and I wouldn't build a modern distributed system with it.
-
tbh I credit HyperCard with a lot of my development as an engineer, I even wrote some basic LAN applications in it back in high school. it was great for that experimentation and learning.
But for as much nostalgia as I hold for it and as much as I wish it had a modern descendent to play with some days, I wouldn't write modern applications with it (maybe something like OpenDoc) and I wouldn't build a modern distributed system with it.
@hrefna The modern descendant is LiveCode. Working on it was my job 2014–2017.
LiveCode Create - Build Software You'll Never Outgrow
One platform. Endless power. Build scalable apps with visual development, custom logic, and built-in AI assistance. From idea to launch, your perfect app awaits.
(livecode.com)
Alas, now fully “AI enabled.”
-
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
