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