5 ms·

I don't believe people like the author of the OP are just over-generalizing for clicks. Based on the other responses on this thread, they're expressing somethin

I don't believe people like the author of the OP are just over-generalizing for clicks. Based on the other responses on this thread, they're expressing something that many of us feel, and that they presumably feel themselves. I'm not sure what to do about that feeling, though. The tools coming out of the Handmade network, at least the ones I've seen, tend to go too far, throwing out necessary things like accessibility. Some of the complexity of modern software is truly necessary. It's easy for those of us who have used computers for a while, or have read some computer history, to look back at earlier feats of software compactness and efficiency, such as an IDE starting and running fast on a processor with a tiny fraction of the power of current CPUs (90s Delphi as raised by a sibling comment), a MIDI sequencer with karaoke-style lyrics display in less than 48 KB of machine code (Diversi-Tune on the Apple IIGS in 1988), or a BASIC interpreter in less than 4 KB (the original Altair BASIC from Microsoft). It's easy to look at these things, compare them to the size of a hello-world program produced by a modern toolchain, and conclude that modern software is indeed terrible. But of course, we look back on those past artifacts with rose-colored glasses. I don't doubt that, for some subset of modern software, bloat is indeed out of control. I'm not sure what to do about it though, or if we can ever get back to those feats of efficiency that tend to impress us in retrospect.

mike_hearn 2y ago
Right. But I think it's easy to misremember the past. Delphi 5 might start quickly if you run it on today's hardware, but back then it took a good 10-15 seconds to start. I remember staring at those splash screens and listening to the endless frustrating clicking of the HDD head far too well. I think a good reality check is to try and bring splash screens to mind. How many splash screens can you think of for modern apps? I can only think of Slack. Back in the Delphi era every app had a splash screen. Office apps, IDEs, html editors, even web browsers! One reason IE4 won over Netscape 4 is the latter showed you a big splash of a lighthouse where the former didn't need one. SSDs are truly miraculous devices but also software engineering just got better. Like, modern client devs know to keep slow operations off the GUI thread whereas back then very few apps were threaded so hung windows that wouldn't repaint were standard. Software is definitely bigger now, but that's mostly because hardware is vastly bigger so nobody cares. Like, on an average Swiss internet connection the bottleneck for installing an app is now the decompression and GateKeeper hashing/anti-malware checks, not the download itself! Why optimize for size when users don't complain about it?
- mwcampbell 2y ago
  > Why optimize for size when users don't complain about it? Pride in one's work? Especially when comparing it to the "good old days". Maybe we'd have better morale if we were allowed (or allowed ourselves, for those of us running our own companies) to indulge in such "useless" optimizations. But no, the pressure is on to keep cranking out more, more, more, with no time for quality that we can be proud of. Edit to add: You're right though that splash screens are less common now.
  - mike_hearn 2y ago
    Well, let's think about the sources of bloat. I'd argue that the primary source of bloat in software today is when there's a mismatch between what developers need and what the underlying platform provides. The most extreme case of this can be found in desktop operating systems where relatively few apps now use the underlying platform at all, largely because nobody wants to write GUI code multiple times. What developers want and what the underlying operating systems provide are almost entirely different so everyone ships a giant runtime to replace what's the OS comes with. Modern mobile platforms have a similar problem, where things like Swift UI or jetpack tend to be bundled with the app or at least were historically up until recently, and that yields bloated packages too. In contrast people get the vapors if a web app is more than 5 MB of download and this happens because the web platform is significantly more responsive to what developers really want even though it has poor technical foundations. Where bloat does occur in web apps, it's because the browser makers have not responded quickly enough or at all to growing mismatches, for example the vdom diffing algorithm react uses could be implemented in the browser itself, but isn't, so lots of apps ship it bundled. Apps for Windows 95 didn't seem bloated, but that's because they relied so heavily on what already came with the computer when you bought it. People just had a suck up the fact that the underlying API was pretty bad, because they couldn't afford to ship anything better and till the CD era came along and then you did start to see apps leave behind the underlying platform and get more bloated. A truly next-gen operating system would make it very difficult to talk precisely about bloat, I think, because if you really went beyond the Unix or NT designs your operating system would download and manage code modules automatically, a little bit like browsers did before the introduction of cache partitioning. How bloated an app appears to be then would depend entirely on what you had previously used and downloaded, and thus to some extent would be in the eye of the beholder. After all, if you measured all of the code paged in by running a native Mac app, or even something like delphi, versus the amount of code paged in by an electron app, it probably wouldn't be that different. It's just that the Mac app is accessing code that is shared with other operating system utilities.
Bluestein 2y ago
> Based on the other responses on this thread, they're expressing something that many of us feel, and that they presumably feel themselves IMHO, agree. It is a thing. Also IMHO one of the first steps is acknowledgement and stakeholder discourse. We can figure this out.-

mike_hearn 2y ago

Right. But I think it's easy to misremember the past. Delphi 5 might start quickly if you run it on today's hardware, but back then it took a good 10-15 seconds to start. I remember staring at those splash screens and listening to the endless frustrating clicking of the HDD head far too well. I think a good reality check is to try and bring splash screens to mind. How many splash screens can you think of for modern apps? I can only think of Slack. Back in the Delphi era every app had a splash screen. Office apps, IDEs, html editors, even web browsers! One reason IE4 won over Netscape 4 is the latter showed you a big splash of a lighthouse where the former didn't need one. SSDs are truly miraculous devices but also software engineering just got better. Like, modern client devs know to keep slow operations off the GUI thread whereas back then very few apps were threaded so hung windows that wouldn't repaint were standard. Software is definitely bigger now, but that's mostly because hardware is vastly bigger so nobody cares. Like, on an average Swiss internet connection the bottleneck for installing an app is now the decompression and GateKeeper hashing/anti-malware checks, not the download itself! Why optimize for size when users don't complain about it?

mwcampbell 2y ago
> Why optimize for size when users don't complain about it? Pride in one's work? Especially when comparing it to the "good old days". Maybe we'd have better morale if we were allowed (or allowed ourselves, for those of us running our own companies) to indulge in such "useless" optimizations. But no, the pressure is on to keep cranking out more, more, more, with no time for quality that we can be proud of. Edit to add: You're right though that splash screens are less common now.
- mike_hearn 2y ago
  Well, let's think about the sources of bloat. I'd argue that the primary source of bloat in software today is when there's a mismatch between what developers need and what the underlying platform provides. The most extreme case of this can be found in desktop operating systems where relatively few apps now use the underlying platform at all, largely because nobody wants to write GUI code multiple times. What developers want and what the underlying operating systems provide are almost entirely different so everyone ships a giant runtime to replace what's the OS comes with. Modern mobile platforms have a similar problem, where things like Swift UI or jetpack tend to be bundled with the app or at least were historically up until recently, and that yields bloated packages too. In contrast people get the vapors if a web app is more than 5 MB of download and this happens because the web platform is significantly more responsive to what developers really want even though it has poor technical foundations. Where bloat does occur in web apps, it's because the browser makers have not responded quickly enough or at all to growing mismatches, for example the vdom diffing algorithm react uses could be implemented in the browser itself, but isn't, so lots of apps ship it bundled. Apps for Windows 95 didn't seem bloated, but that's because they relied so heavily on what already came with the computer when you bought it. People just had a suck up the fact that the underlying API was pretty bad, because they couldn't afford to ship anything better and till the CD era came along and then you did start to see apps leave behind the underlying platform and get more bloated. A truly next-gen operating system would make it very difficult to talk precisely about bloat, I think, because if you really went beyond the Unix or NT designs your operating system would download and manage code modules automatically, a little bit like browsers did before the introduction of cache partitioning. How bloated an app appears to be then would depend entirely on what you had previously used and downloaded, and thus to some extent would be in the eye of the beholder. After all, if you measured all of the code paged in by running a native Mac app, or even something like delphi, versus the amount of code paged in by an electron app, it probably wouldn't be that different. It's just that the Mac app is accessing code that is shared with other operating system utilities.

Bluestein 2y ago

> Based on the other responses on this thread, they're expressing something that many of us feel, and that they presumably feel themselves IMHO, agree. It is a thing. Also IMHO one of the first steps is acknowledgement and stakeholder discourse. We can figure this out.-