Software bloat makes me sad • Hacker News Board

Re: Software bloat makes me sad

#91

Post by adrusi » Fri, Jul 03, 2015, 3:37 PM UTC

fullwedgewhale wrote: post #59

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…

This is one of the biggest sources of bloat. In the node and ruby ecosystems especially, dependencies proliferate exponentially, where an application pulls in 12 libraries, each of which pull in 12 of their own, which each pull...

Downloading the depedencies for Ghost, the node blogging platform with the explicit goal of simplicity and minimalism, takes me minutes.

Compare this with the status quo when writing programs in C, where you might link to 4 libraries total, one of which pulls in 2 others as dependencies.

I've come to suspect that the super convenient package managers that all the "modern" languages have are at fault for this.

Re: Software bloat makes me sad

#92

Post by prof_hobart » Fri, Jul 03, 2015, 3:37 PM UTC

TeMPOraL wrote: post #53

bloateddevtards wrote: post #45

Earlier quoted context omitted.

I am not sure we need to go as lean as hand-rolled asm, but we sure went down a wrong path when we just accept that word will get bigger and bigger with each release. No one asks why.

I think so too. It's not about ASM snippets; it's about people not knowing what their software actually does. Software bloat isn't magic, nor is it static; your CPU is doing something . If with time application gets bigger and slower, and yet no extra features appear to explain it, it means your CPU is running code that shouldn't be run, wasting its cycles on pointless and irrelevant computations. That's laziness and…

It's not laziness or stupidity (well, it might be sometimes, but certainly not always).

It's using your time to do something else, such as improving security, or adding a new feature. Some people seem to be talking as if it automatically takes the same amount of time to create efficient code as inefficient code, and the idiot developer has simply forgotten to add the -run_faster option on the compiler.

I'm involved in a project at the moment where a team of developers and engineers have spent much of the last month trying to get response times in some very specific circumstances in an application down to an acceptable level. That's not because they are either stupid or lazy. It's because these things are hard - there's an awful lot of moving parts, and an awful lot of things that can go wrong in each of them.

When they get it down to an acceptable level, they'll ship it to the users. It won't be blazingly fast, but it'll be good enough. They could definitely spend longer tuning it further and getting it going even faster. But every day they do that will be a day longer until the features that the users want are actually available to them.

Re: Software bloat makes me sad

#93

Post by XorNot » Fri, Jul 03, 2015, 3:37 PM UTC

nlawalker wrote: post #65

TeMPOraL wrote: post #47

Earlier quoted context omitted.

That's probably because you have SSD, but anyway; I could do the exact same process 10 years ago (with "winword" instead of "word"), get similar response times, and yet the software was an order of magnitude smaller and more responsive. And it's not like Word gained many actually useful features during that time.

>> And it's not like Word gained many actually useful features during that time. Then use the 10 year old version! Unless, of course, one of those few "actually useful features" is something you can't live without. A lot of people use Word for a lot of use cases. The value of an added feature that someone needs always trumps the performance cost of adding it until the performance becomes so bad that it becomes the re…

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

Re: Software bloat makes me sad

#94

Post by emsy » Fri, Jul 03, 2015, 3:38 PM UTC

falcolas wrote: post #63

emsy wrote: post #17

Atom and Vim (and imo even Ubuntu) aren't good example of software bloat. While they might be slow and use a lot of memory, they're usually shipped with basic functionality and more functions can be added and removed at any time. Good examples are iTunes, Office, iOS and Android (the latter two are usually shipped with non removable bloatware).

In my (controversial) opinion, Atom is a great example. It includes/requires Nodejs, an embedded web browser, and runs Javascript, to run a rather basic text editor. And in many cases, it's slow, CPU hungry, and memory intensive. Those three characteristics are the very definition of bloat to me.

I don't think Atom wants to be a basic text editor in the first place. It's shipped as a basic editor but the killer feature is that you can easily hack together extensions to suit your needs. It's a tradeoff: you pay for the html+js engine, but get a lot of potential developers. That being said, having worked with Atom on a larger project I can't confirm it's slow.

Re: Software bloat makes me sad

#95

Post by XorNot » Fri, Jul 03, 2015, 3:39 PM UTC

vezzy-fnord wrote: post #27

zimpenfish wrote: post #20

"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. If that's what you need, you've got options..." http://www.jwz.org/doc/easter-eggs.html

That doesn't excuse resource inefficiency, which is really the main point. The issue of size can be further addressed by separation of mechanism and policy, and building for extensibility.

Are you sure there's inefficiency? Do you have specific points in the code or behavior which are obviously inefficient, or does it just feel "too big"?

Re: Software bloat makes me sad

#96

Post by JoeAltmaier » Fri, Jul 03, 2015, 3:42 PM UTC

XorNot wrote: post #93

nlawalker wrote: post #65

Earlier quoted context omitted.

>> And it's not like Word gained many actually useful features during that time. Then use the 10 year old version! Unless, of course, one of those few "actually useful features" is something you can't live without. A lot of people use Word for a lot of use cases. The value of an added feature that someone needs always trumps the performance cost of adding it until the performance becomes so bad that it becomes the re…

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.

Re: Software bloat makes me sad

#97

Post by adrusi » Fri, Jul 03, 2015, 3:45 PM UTC

cbd1984 wrote: post #88

lsaferite wrote: post #81

Earlier quoted context omitted.

But doesn't static linking JUST link in the used features of the linked libs? Wouldn't that actually be better? Then I don't have 5 versions of a huge dynamic lib for 5 programs that all use slightly incompatible version and that only use 1 or 2 methods.

> But doesn't static linking JUST link in the used features of the linked libs? No, not if it works like it does in C and C++. Lisp used to do that, back when Symbolics still existed; it was called tree-shaking, as in "shake the call graph tree to see what falls out". The main function calls functions FOO, BAR, BAZ, which call FROTZ and QUUX, which call... and remove everything not in that tree. Of course, this gets…

In C and C++ you can conservatively eliminate unused code for statically linked libraries using --gc-sections and -fdata-sections.

Go uses the Plan9 compiler architecture, which means that its linker knows more about the code and is responsible for more optimizations than its Unix equivalent, so it quite effectively eliminates dead code.

Of course, libraries are often highly coupled within themselves, so not much code can be eliminated, and then they might pull in additional dependencies, etc., etc.

Re: Software bloat makes me sad

#98

Post by mwcampbell » Fri, Jul 03, 2015, 3:46 PM UTC

pjc50 wrote: post #83

mwcampbell wrote: post #26

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…

If I don't mind not having those features, can I have the light version?

Just make sure your use of the light version won't impact anyone else who would mind the missing features.

For example, suppose you're developing an application, and you want to use a lightweight GUI toolkit, or roll your own as Spotify apparently used to do. Unless the toolkit is just a thin wrapper over the underlying OS's native GUi facilities, like wxWidgets or SWT, the resulting application is very likely to have accessibility problems, unless you do the hard work of implementing the accessibility APIs for your target platform(s).

Re: Software bloat makes me sad

#99

Post by JoeAltmaier » Fri, Jul 03, 2015, 3:46 PM UTC

prof_hobart wrote: post #92

TeMPOraL wrote: post #53

Earlier quoted context omitted.

I think so too. It's not about ASM snippets; it's about people not knowing what their software actually does. Software bloat isn't magic, nor is it static; your CPU is doing something . If with time application gets bigger and slower, and yet no extra features appear to explain it, it means your CPU is running code that shouldn't be run, wasting its cycles on pointless and irrelevant computations. That's laziness and…

It's not laziness or stupidity (well, it might be sometimes, but certainly not always). It's using your time to do something else, such as improving security, or adding a new feature. Some people seem to be talking as if it automatically takes the same amount of time to create efficient code as inefficient code, and the idiot developer has simply forgotten to add the -run_faster option on the compiler. I'm involved i…

Perhaps too many moving parts. Engineers are criticized for 'reinventing the wheel' and writing code when open source is available. But use too much open source, and you have too many moving parts, you don't know how they work, and things like locks and latency are uncontrollable. A familiar storey!

Re: Software bloat makes me sad

#100

Post by tomjen3 » Fri, Jul 03, 2015, 3:47 PM UTC

Kaali wrote: post #22

There is another side of extra resource use that I don't really see addressed except in the mobile space: ecology. Even though my computer can run all applications without a hitch, it is still very wasteful to constantly use CPU power because of technology choices or plain laziness. As an example, Spotify and Slack are two applications that seem to use most of my CPU after Chrome. Spotify and Slack combined seems to…

As students we learn of the cpu/memory tradeof. In the real world it is engineering time/cpu/memory that is involved in the tradeof. Given how much money we make the business case often doesn't come close to existing for moving the tradeof to CPU time. Take Slack - they are adding tons of new users and their users love them, the company has a high valuation. Focusing on getting that percentage down to nothing would have torpedoed their company.