The problem is more acute than ever. Sure, there are applications today that couldn’t exist 10 or 20 years ago; and yes, interfaces have improved.
Yet common tasks (messaging, web browsing, document authoring, software development) are not all that different but require much larger amounts of resources.
@civodul I feel this is a sociological issue. Humans, it seems, will prefer to expand to consume all resources until there is some forcing factor to prevent us from doing so. Wirth's law is the expression of this in our industry.
Something to reflect on which I find helpful: why do we use and love Guile and not write everything in machine code?
A domain I am interested in is software that allows humans to operate at high levels without sacrificing efficiency. Lisp macros are an example of this
I sympathize to some extent with the critique of “our recent penchant for friendly user interaction”, insisting that “ease should be based on an underlying concept that makes the use almost intuitive”.
I have a feeling though that Wirth puts too much blame on GUIs. They sure were a significant part of “bloat”, especially back in 1995. But is it still true for the 1995–2024 time frame?
Also, some of the incentives for “bloat” and disincentives for “lean software design” Wirth describes hold for proprietary software, but not so much for free software.
Yet, free software does suffer from the same problem.
20 years ago I’d run GNU/Linux, X11, Firefox, Emacs, Guile, etc. on my Sun UltraSparc4 (64-bit SPARC!). Would I be able to run modern versions of these things on that machine? I doubt it.
Why is that?
(Linux and Debian dropped SPARC64 years ago anyway.)
We need a principled way to measure (and define!) “bloat” and we need to study the phenomenon in more detail; it’s not just the fault of icons and overlapping windows and customer demand.
I don’t know how to do that (I’m not even able to fully understand what’s happening with the software I develop!) but I think it’s a crucial challenge for the future. The computing we’ll keep will have to make do with less resources.
@civodul I don't know how to define bloat either, but I think things like fonts, icons, emojis, encryption algorithms, and programming language runtime environments can be excluded from the definition.
But there are many things I do not like. I do not like every application downloading its own copy of slightly different versions of the same library, and/or the same programming language runtime environment. I do not like containers, or things like AppImage or Flatpak trying to facilitate this practice by hiding away the details of library dependencies.
Of course I am sure we both agree that Guix (and Nix) both go a long way to solving the technical details of this problem, but I think there are political issues that remain unresolved, like can we get everyone to agree to release their software at roughly the same time, in a sort of point-release fashion? (Like what Ubuntu does, every 6 months.) I think this solution is analogous to democratic elections in a parliamentary government. "Elections" are held every 6 months, where all laws that have been drafted in the past 6 months go into effect just before the election. So the "laws" are like the software, the "election" is the process of cutting a release of that software and submitting it to the network that delivers it to end users.
But some people will insist on rolling releases. Some people will insist on installing packages using tar archives, some people will insist that flatpaks, appimages, and docker images are all good, practical ways of delivering software. This disagreement is why I call it a "political issue."
@ramin_hal9001 Software bundling (“vendoring”) is certainly part of the problem, and so are application bundles like Docker/Flatpak images. They clearly contribute to increased disk and memory usage, and yes, Guix, Debian, and Nix (but to a less extent AIUI) contribute to addressing that.
That’s just part of the story though, “system-level bloat”.
Individual software packages have their own problems.
@civodul making software lean requires extra efforts (planning ahead, trying out several implementations, and cleaning up afterwards), but everybody¹ prefer more features instead of that — proprietary or not, the tradeoff is always the same
¹ who has the power over the course of development, in the end it's essentially hardware vendors — software is only good for selling more hardware
@civodul I don't think GUIs are a problem by itself, it's rather that GUIs are hardly ever created with user freedom (and user empowerment) in mind.
A user interface that isn't programmable is disposable-ware, and hopefully this is only a temporary problem (in the first couple of decades of the 21st, it was popular for programmers to treat their users as morons).
@janneke Ah yes, I agree regarding the negative impact of GUIs on user empowerment.
For many tasks, I don’t think a textual interface is inherently harder to learn and use, as long as it’s based on a “concept that makes the use almost intuitive”, as Wirth writes.
When it comes to resource usage though, that of non-GUI software seems to increase as well.
> "it's rather that GUIs are hardly ever created with user freedom (and user empowerment) in mind."
@civodul@janneke this is very true, and even more true for smartphone operating systems.
I can think of a few GUI applications that do empower users: Emacs, Blender, GIMP, Krita, there are probably a few more that don't occur to me right at this moment.
@civodul
I've seen myriad fingers pointed at many technical reasons, but I've found counter-examples for basically all of them. We do demand more from our software now, but that's not the whole story.
@civodul
Most users have no clue. Software adoption follows trends, influenced by marketing. Changing software is a bigger headache than buying a new device. They don't care about how the sausage is made.
Devs need to make a living, so they mostly learn what's desired by the job market.
The zeitgeist in the corposphere is that dev time is more expensive than hardware, so just grab a library to ship the feature. No, not that niche one. We need you to be replacable to keep salaries down. 3/4
@civodul
Free software isn't immune to entire generations of coders coming up in this environment.
So, what then? There will always be those of us who make more efficient software for love of the craft or because we're not privileged enough to do otherwise, but we must face facts.
We are tailors bemoaning the poor quality of off-the-rack. We are woodworkers shaking our fist at IKEA. This is the commodification of tech.
Add comment