People often talk about how fast old software is, but one of the things that stands out about GeoWorks for me is how small it was while doing a lot.

Of course, lots of things that make modern software bigger are things we very much don't want to do without--full Unicode support, accessibility, clever rendering, improvements to quality of life. But our 'foundations' are also built higher; the Web platform and a bunch of native toolkits provide a lot out of the box. (The platform doesn't include all the widgets that are now quasi-standard, of course, so we build a lot on top anyway.)

There are also a ton of useful third-party libraries you can call on without getting too bloated, and there's a lot that would have been bloated then but not now: in the 90s you probably wouldn't embed an SQL DB you didn't really need, but SQLite is a pretty safe dependency now.

Nothing in particular I'm really driving towards here but I think "how do I keep the code to functionality ratio good" can still be an interesting angle from which to look at high-level design decisions even as a lot of the circumstances and numbers have changed over decades.

Classic response to that:

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

These days it's have LLMs rewrite it in rust. </s>

Software these days compared to back then is bloated. There were memory constraints and processor constraints. If RamAltman had his way, we would likely return to needing to do that.