having so much fun with this vibe coding what used to take me two or three hours can now be done in a single day
-
@AbramKedge @hiway @futurebird
A lot of VB code was like that. I did encounter one bit of in-house VB6 that was beautifully structured, had clean abstractions, and spoke to a SQL Server back end, so I at least have an existence proof that good, clear, maintainable code was possible in VB. I never managed to write any though. Somewhere I have some floppy disks full of truly terrible VB2 to VB4 that I wrote as a child.
-
The vibe coding thing does highlight how much code is pointless. A load of the things that I’ve seen people be impressed with are things that should be a couple of hundred lines of code but somehow modern frameworks have focused on making things require more code to accomplish the same thing. Systems like HyperCard or even Flash let people produce rich GUIs with almost no code. The kinds of things that could be built in a visual editor with a small amount of code 15-25 years ago are now being generated as tens of thousands of lines of unmaintainable and buggy LLM code.
@david_chisnall @futurebird I talked to a friend who made a lot of money taking a company public (and who is a huge booster of llm-assisted coding) about this exact issue.
his response was kind of horrifying, but at least now I understand how these people think. He said "I don't care. companies don't fail because their code is unsustainable, they fail because they don't have a product. by the time the tech debt comes due, you should have already sold the company."
-
I think there are probably some interesting incentives for people to study here. It’s struck me a lot that the popular GUI frameworks today take far more code to achieve good results than good ones from the ‘90s (though less than the worst of the ‘90s). I suspect that it’s a combination of three things:
- Good API design is simply not taught anywhere.
- Poor API design is an externality. Consumers of your library / framework pay the cost, not you.
- Frameworks that require more code make it easier for their users to justify their salaries. If someone writes a 300 line app, it seems like a toy to their management. If they write a 10,000-line app that does the same thing, it’s much easier to explain why it cost money to build.
None of this is really to do with the cost of RAM or compute. Smalltalk-80 was a full GUI on a machine with 1 MiB of RAM and a CPU slower than the slowest Cortex-A0 and it ran interpreted bytecode.
@david_chisnall @futurebird yeah, I can certainly agree that the incentives for writing small, clear, maintainable programs are... hidden, at best. That's part of what angers me.
And the management incentives - LOC, releases regardless of what's in them, integration of AI into things even if it will break everything, are powerful.
I would like to go live on the moon, please.
-
@david_chisnall @futurebird yeah, I can certainly agree that the incentives for writing small, clear, maintainable programs are... hidden, at best. That's part of what angers me.
And the management incentives - LOC, releases regardless of what's in them, integration of AI into things even if it will break everything, are powerful.
I would like to go live on the moon, please.
@david_chisnall @futurebird Oh, and there's the fact that writing clean code requires time and thought. Given the number of teams I've been on which required several people to do the project, but only one gets employed - with the exact same deadlines as a full team - I've no doubt that contributes to code being produced that looks like a shitty first draft every time. Because it has to be.
-
@david_chisnall @futurebird I talked to a friend who made a lot of money taking a company public (and who is a huge booster of llm-assisted coding) about this exact issue.
his response was kind of horrifying, but at least now I understand how these people think. He said "I don't care. companies don't fail because their code is unsustainable, they fail because they don't have a product. by the time the tech debt comes due, you should have already sold the company."
@Amoshias @david_chisnall @futurebird
If the purpose of a company is to be sold before the technical debt comes due, then that does explain why every web hosting service seems to come with "AI will help you build your website" but I still can't buy an actual, usable, practical in-home assistance robot that has minimal technical debt and actually works. -
@Amoshias @david_chisnall @futurebird
If the purpose of a company is to be sold before the technical debt comes due, then that does explain why every web hosting service seems to come with "AI will help you build your website" but I still can't buy an actual, usable, practical in-home assistance robot that has minimal technical debt and actually works.@robotistry @david_chisnall @futurebird while I agree with the thought of what you're posting...
What?!? Dude. that's "if we can put a man on the moon, why can't we put a man on Mars?"
-
having so much fun with this vibe coding what used to take me two or three hours can now be done in a single day
@futurebird
One cool but sunny spring morning in the early 1980s I bumped into a student from Africa with whom I exchanged words with on occasion.We fell into conversation, starting with the weather and how the winter had been and colds that the winter brought. As folk used to do in the days before Covid.
They observed the following:
"You know, without medicine a cold lasts for seven days. But with medicine it only lasts a week."
Vibe coding seems to be worse than merely ineffective.
-
I think there are probably some interesting incentives for people to study here. It’s struck me a lot that the popular GUI frameworks today take far more code to achieve good results than good ones from the ‘90s (though less than the worst of the ‘90s). I suspect that it’s a combination of three things:
- Good API design is simply not taught anywhere.
- Poor API design is an externality. Consumers of your library / framework pay the cost, not you.
- Frameworks that require more code make it easier for their users to justify their salaries. If someone writes a 300 line app, it seems like a toy to their management. If they write a 10,000-line app that does the same thing, it’s much easier to explain why it cost money to build.
None of this is really to do with the cost of RAM or compute. Smalltalk-80 was a full GUI on a machine with 1 MiB of RAM and a CPU slower than the slowest Cortex-A0 and it ran interpreted bytecode.
@david_chisnall @grrrr_shark @futurebird
Back in the 1980s, we build a perfectly usable full X.500 email client that ran on BBC micros (that’s 32kB of RAM, or 48kB with sideways RAM mod). Bloat has exploded since then. -
@david_chisnall @grrrr_shark @futurebird
Back in the 1980s, we build a perfectly usable full X.500 email client that ran on BBC micros (that’s 32kB of RAM, or 48kB with sideways RAM mod). Bloat has exploded since then.@KimSJ @david_chisnall @futurebird Right? The concern I was expressing was this - useful things don't NEED to be huge. But so many people don't even have the skills to make them clean and small now.
Even when I write with bloated languages/frameworks/tools now, I still think about what the code I'm writing is going to do and try to be parsimonious. But it IS a skill and if folks don't learn it, of course they won't do it.
-
@KimSJ @david_chisnall @futurebird Right? The concern I was expressing was this - useful things don't NEED to be huge. But so many people don't even have the skills to make them clean and small now.
Even when I write with bloated languages/frameworks/tools now, I still think about what the code I'm writing is going to do and try to be parsimonious. But it IS a skill and if folks don't learn it, of course they won't do it.
@grrrr_shark @KimSJ @futurebird
This is partly why I enjoy working on CHERIoT so much: I can understand the entire hardware-software stack.
-
In the ‘90s there was a huge push in software engineering to component models. COM and CORBA both came out of this. The idea was to build libraries as reusable blocks. Brad Cox wrote a lot about this and created Objective-C as a way of packaging C libraries with late-bound interfaces that could be exposed to higher-level languages easily.
This combined with the push towards visual programming, where you’d be able to drag these libraries into your GUI and then wire things up to their interfaces with drag-and-drop UIs. The ‘Visual’ in Visual Studio is a hangover from this push.
Advocates imagined stores of reusable components and people being able to build apps for precisely their use case by just taking these blocks and assembling them.
It failed because the incentives were exactly wrong for proprietary COTS apps. Companies made money by locking people into app ecosystems. If it’s easy for someone to buy a (small, cheap) new component to Word 95 that adds the new feature that they need, how do you convince them to buy Word 97?
The incentives for F/OSS are the exact opposite. If another project can add a feature that some users want (but you don’t) without forcing you to maintain that code, everyone wins. But we now have an entire generation that has grown up with big monolithic apps who copy them in F/OSS ecosystems because it’s all they’ve ever known.
@david_chisnall
There are more problems with components than just monetization.Plug-in style extensions add extra layers of complexity for both developers and users. End users have to source and manage thier plug-ins. Developers often build their plug-in for only one operating system or one version of the application then abandon it.
There are good technical and social reasons for projects (such as the Linux kernel) to use a monolithic model.
-
Dude it's not going to die, it's not bitcoin
-
Dude it's not going to die, it's not bitcoin
"bitcoin's not going to die, it's not like the dotcom bubble. The blockchain is a real new technology with endless applications, this is nothing like the hype over having webpages ..."
-
N Marianne shared this topic
