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

@grrrr_shark @futurebird

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 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.

#Robot: https://labradorsystems.com

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

@grrrr_shark @futurebird

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.

@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.

@futurebird

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.

@pikesley @wakame @futurebird

Dude it's not going to die, it's not bitcoin