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