Live data from Hacker News

Software bloat makes me sad

remarkablyrestrained.com

141–150 of 165 posts

Re: Software bloat makes me sad

#141
post #93

Earlier quoted context omitted.

People who complain about bloat are usually complaining about features they don't use. Of course watch what happens when people start doing metrics and optimizing their UI for "common uses" - turns out you're optimizing for non-existent users (see: the Ribbon).

The ribbon gets knocked a lot; but the median word processor user has zero experience. The ribbon gives them a fighting chance to find what they need. At the expense of 'expert users' with their idiomatic expectations.

Which is a problem because tools should be just that - tools. You don't make welders or soldering irons easy for people with zero experience. You make them effective and efficient tools, and then train people to use them. Heck, show me a single musical instrument giving zero-experienced users "a fighting chance to find what they need".

It's weird how new trends in UX design try to make a first-time user become a genius immediately after double-clicking on the program icon. The only way you can do that is by dumbing down the software to the point it can actually be comprehended this way - which makes it much less usable and effective as a tool.

Re: Software bloat makes me sad

#142

One thing that strikes me is the explosion in dependencies in most software. I'm guilty of this, too. I've seen plenty of examples where an entire library or framework is added to a project just for a couple of features. Add a few libraries like that and suddenly you have a few megabytes of additional libraries, where maybe 90% or 95% of the features will never be used. A good article a while back looked at common un…

Dart makes a decent argument for a smarter compiler. They've implemented "Tree Shaking" in their compiler: essentially cross-library dead code elimination. This would probably be quite tricky in Java land where reflection does add new entry points, but it could be used to solve the problem of "I only need this one function from this library, don't compile in anything else". I was personally quite surprised when I por…

> I ported from code from Node to Java/Groovy

How much of that was Java's fault and how much Groovy's, I wonder?

Re: Software bloat makes me sad

#143

I've previously decried bloat too, but I find that my rants against software bloat are based on emotion, not reason. So, looking at this rationally, consider your favorite lightweight window manager or desktop environment for Linux. Is it fully internationalized, including support for CJK input methods? Is it fully accessible to users with disabilities, e.g. blind people and people with mobility impairments? Does it…

> AFAIK, the only Linux desktop environments that come close are GNOME and Unity. I'm the project lead of LXQt. All those things you listed can be supported without introducing much bloat at all. In DEs, most bloat comes from pure technical debt. Unnecessary libraries, duplicated code/libs, etc. Feature bloat is another matter and is more subjective. A lot of it is down to UX. Fun fact: KDE 4.x depends on ruby in mos…

don't forget about backwards compatibility.

Re: Software bloat makes me sad

#144

Earlier quoted context omitted.

I think you misunderstand. The parent was asking for examples of bloated code. I was providing examples. I actually /do/ use other browsers like Midori, w3m, and surf. The problem doesn't disappear, though, because it's up to all of us writing code to be better at it.

Not all code bases need to be minimal to be valid. Some people like having the features you class as superfluous. So long as you have the option to choose software that suits your taste there's not really much of a problem. I, for one, am glad that the web continues to evolve beyond its original design, clearly that's not something you're as interested in, both viewpoints are valid.

So my point here isn't that I feel those features are superfluous, but that that including them wholesale into the web browsing application directly is bloat -- it would be better served to produce separate applications specialized for those features.

Bookmarks, for instance, can be handled in a much cleaner and portable way than isolating them to the specific browser implementation. The same can be said for history, authentication, and so on.

Also, to be fair, I wasn't arguing for minimal codebases -- that was your point. I was providing examples for the GP.

Re: Software bloat makes me sad

#146

Earlier quoted context omitted.

The ribbon gets knocked a lot; but the median word processor user has zero experience. The ribbon gives them a fighting chance to find what they need. At the expense of 'expert users' with their idiomatic expectations.

Which is a problem because tools should be just that - tools. You don't make welders or soldering irons easy for people with zero experience. You make them effective and efficient tools, and then train people to use them. Heck, show me a single musical instrument giving zero-experienced users "a fighting chance to find what they need". It's weird how new trends in UX design try to make a first-time user become a geni…

That's the expert talking. The tool is made for the most common case - a new hire meeting it for the first time. They're not gonna do a good job; but anything that can improve their performance, pays. Follow the money.

Re: Software bloat makes me sad

#147
post #8

Earlier quoted context omitted.

So maybe my comment stems from ignorance. Are you saying that two Golang projects sharing the same (large, for the sake of the argument) dependency would not take (size of the dependency * 2) on i.e. the Ubuntu live CD (as was the example in the fine article)?

Correct. I would not be surprised if those two Golang projects take less than the size of the dependency. 2x is a degenerate worst-case. With static linking, you only need to pull in things you actually need (and you can optimize from there!), whereas with dynamic linking you need to pull in the entire dependency regardless. (You only need to pull in one copy regardless of how many things are using the library, true.…

That makes a lot of sense.

Thanks for the insight, I now understand why my comment was misguided.

Re: Software bloat makes me sad

#148

Earlier quoted context omitted.

Civilian comment: the Gnome/dbus/logind/systemd situation seems to have arrived as a result of a number of independent projects each on their own random walk but responsing to the earlier states of other projects that each depends on. So it may be overall integration issues (Linux based systems have always seemed to me as a user to be like bags of lego) rather than efficiency of any particular aspect of one project.

While I agree they're all attacking the same problems, ultimately they all have exactly the same problem when it comes to code: no designs, no docs, and no tooling. The point you make about Linux systems being bags of Lego is interesting. That's exactly how it is supposed to be. Unfortunately, the projects we're talking about don't compose well -- they're more like Duplo than Lego because often times they subsume who…

Not sure why you are being down-voted for expressing an opinion about program design. Would downvoters care to explain?

Re: Software bloat makes me sad

#149

One thing that strikes me is the explosion in dependencies in most software. I'm guilty of this, too. I've seen plenty of examples where an entire library or framework is added to a project just for a couple of features. Add a few libraries like that and suddenly you have a few megabytes of additional libraries, where maybe 90% or 95% of the features will never be used. A good article a while back looked at common un…

Dart makes a decent argument for a smarter compiler. They've implemented "Tree Shaking" in their compiler: essentially cross-library dead code elimination. This would probably be quite tricky in Java land where reflection does add new entry points, but it could be used to solve the problem of "I only need this one function from this library, don't compile in anything else". I was personally quite surprised when I por…

You can only tree-shake a whole program compilation, but then you cannot use compilation units, modules and modularity efficiently. You have to choose one or the other.

Every normal compiler implements simple (i.e. module level) dead-code elimination already.

EDIT: Of course you could use static libs, which does pull in only used symbols, but then you cannot share them across apps and update independently.

I implemented a tree shaker for my lisp and was very happy with it, esp. for delivery. Like Go does it nowadays.

Re: Software bloat makes me sad

#150

Earlier quoted context omitted.

As demand for software grows, a lot more code made by immature (as in beginner, junior, green) developers finds its way to production. Part of it is not code reviewed by senior developers. Another part is but too late in the cycle and goes in anyway because features. The bloat is technical debt accrued in favor of shipping. It probably happens to both types you described, but shipping is a business decision.

It's not always a business decision. GNOME, KDE, X, systemd, dbus... The list goes on and on. None of this software is business derived. Honestly, an engineer that cares about the performance of their code has several options available: - design the project first, then code later. - design the code for the architecture (arrays of objects vs. objects of arrays). - use tools that can optimize out inefficiencies. - hand…

Go far back enough and you find corporations everywhere.

At the time of X's creation, DEC and IBM was looking for a GUI for their unix offerings.

And dbus came out of trying to make it easier to get the various Linux GUI toolkits to talk to each other, under the stewardship of Freedesktop (where also Systemd was housed until very recently). Thing is that RH was a big backer of that, and was out to win against the big unixes (A recent video interview with various employees there pretty much proclaim "we won the unix war(s)").

Post reply on HN