Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software bloat makes me sad

remarkablyrestrained.com

Post reply on HN
Print view View original

151–160 of 165 posts

Re: Software bloat makes me sad

#151

Post by garthk »

prof_hobart wrote: post #57
bloateddevtards wrote: post #16

Earlier quoted context omitted.

I could edit a doc with a word processor that could fit onto a floppy, and it worked well. Now, why does the same task require a multi GB pos bloatfest to do the same job? And oftentimes, more slowly! Imagine for a second, the power of today's hardware running optimised lean code. It could be so good, but we accept bloated crappy bug ridden shitfests of OS and application software. We seem to care more about glossy a…

How often do you need to edit a doc using a word processor that's running on a floppy? I'm guessing that it's not very often. If you really need a lightweight word processor, there's plenty out there. They just probably won't have a lot of the features that the big hitters have now. And if you really want a lightweight OS, there's a fair few Linux distros aimed at that market. What do you want your code to optimised…

Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. – Blaise Pascal, Lettres Provinciales, 1657

Re: Software bloat makes me sad

#152

Post by prof_hobart »

JoeAltmaier wrote: post #99
prof_hobart wrote: post #92

Earlier quoted context omitted.

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!

Apart from the OS (which isn't where the problem lies), there's no open source in it.

The reason there's lots of moving parts is because modern computers, OSs, languages, application servers, libraries, databases etc are built to do a lot of very complicated things.

We could have written the entire application from scratch, not using any 3rd party elements so that we had full control over every element. But that would have taken several orders of magnitude longer to deliver actual useful working software to the users.

Re: Software bloat makes me sad

#153

Post by prof_hobart »

Shorel wrote: post #133
prof_hobart wrote: post #10

>The usual counter to this is that the actual (as opposed to imagined) bottlenecks will only become apparent after intense usage. The usual counter is that "optimising" takes time. And all of the time that you're spending trying to optimise before release is time that no one is able to use your software at all. And the reality is that a lot of the bottlenecks can't be predicted in advance - who knows how may files th…

> Take his Ubuntu example - for what percentage of users does the fact that it doesn't fit on an actual CD really matter any more? That's only one thing among many mentioned, to prove a point. The fact that it doesn't run well with only 2GB of RAM certainly affects plenty of actual and potential users. So the point stands. Not about the CD per se, but some optimizations are general and apply everywhere. And every sin…

There's less feature-rich versions of Linux out there that will run comfortably in less than 2GB. If that's what you're after, use one of them.

Of course all software could be faster. It could also be more secure, more feature-rich, more user friendly, smaller and "better" in any number of other ways. But developers don't have infinite time to focus on all of them.

So they have to make tradeoffs, and the fact that most people default to the more feature-rich OSs rather than the lightweight ones, suggests that this is the place that the average user would rather the devs spend most of their time.

Re: Software bloat makes me sad

#154

Post by Freaky »

falcolas wrote: post #61
Freaky wrote: post #54

Earlier quoted context omitted.

It's a funny idea of sucking less where any user configuration involves editing config.h and recompiling.

Which is easier? Re-running make, or having to write and induce another library to read configuration files? Configuration files introduce a new point of failure (file not present, file corrupted, file not readable), a point of slowdown (how long does it take to read the file from disk, how long does it take to parse and load the file), and a point of complexity (parsing even ini files is pretty complicated, if you w…

> Which is easier? Re-running make, or having to write and induce another library to read configuration files?

It's certainly easier for the programmer to just leave some of the work to the compiler, but it's at the cost of being a complete pain in the ass to packagers and users.

Do you even have to do much work yourself? .Xresources is already parsed and loaded for you by xrdb if you can't afford the cost of an extra 100 microseconds doing it yourself. Is the API to interact with that mindblowing horrid or something?

> All of this for values which change once every... how long?

When I'm configuring software to taste, several times a minute. And considering this is likely to be my first exposure to the software, it better not suck completely.

Re: Software bloat makes me sad

#155

Post by JoeAltmaier »

prof_hobart wrote: post #152
JoeAltmaier wrote: post #99

Earlier quoted context omitted.

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!

Apart from the OS (which isn't where the problem lies), there's no open source in it. The reason there's lots of moving parts is because modern computers, OSs, languages, application servers, libraries, databases etc are built to do a lot of very complicated things. We could have written the entire application from scratch, not using any 3rd party elements so that we had full control over every element. But that woul…

Or, to be non-Aristotelian about it, some parts could have been dispensed with and appropriate code written for the purpose, and other more robust parts could be kept.

Re: Software bloat makes me sad

#156

Post by prof_hobart »

JoeAltmaier wrote: post #155
prof_hobart wrote: post #152

Earlier quoted context omitted.

Apart from the OS (which isn't where the problem lies), there's no open source in it. The reason there's lots of moving parts is because modern computers, OSs, languages, application servers, libraries, databases etc are built to do a lot of very complicated things. We could have written the entire application from scratch, not using any 3rd party elements so that we had full control over every element. But that woul…

Or, to be non-Aristotelian about it, some parts could have been dispensed with and appropriate code written for the purpose, and other more robust parts could be kept.

Until you discover the issues, you don't know which bits aren't robust enough.

And rewriting them, along with modifying the rest of the application to use them, takes time and can lead to further unexpected behaviour.

Re: Software bloat makes me sad

#157

Post by JoeAltmaier »

prof_hobart wrote: post #156
JoeAltmaier wrote: post #155

Earlier quoted context omitted.

Or, to be non-Aristotelian about it, some parts could have been dispensed with and appropriate code written for the purpose, and other more robust parts could be kept.

Until you discover the issues, you don't know which bits aren't robust enough. And rewriting them, along with modifying the rest of the application to use them, takes time and can lead to further unexpected behaviour.

The opposite of that. Using somebody else's code, written for a different app in a different environment, is where most unexpected behavior comes from.

Here's the bits that aren't robust enough: any open source that isn't either used by thousands, or used in exactly the way you will be using it.

Re: Software bloat makes me sad

#158

Post by Eridrus »

vorg wrote: post #142
Eridrus wrote: post #113

Earlier quoted context omitted.

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?

Given my own code was only 1MB total, neither. 97% of the size was from external dependencies. FWIW, it was a "shaded" jar that had all its dependencies linked in statically.

Re: Software bloat makes me sad

#159

Post by Eridrus »

rurban wrote: post #149
Eridrus wrote: post #113

Earlier quoted context omitted.

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 implemen…

Right, I guess I wasn't clear, this was a shaded/fat jar, so it had all its dependencies included statically.

I feel like our computing infrastructure has gotten to the point that dynamically linked libraries are no longer a good choice. I think dynamic linking has only caused us problems at work (devs install Node deps on the staging server, forget to tell ops, service crashes when deployed in prod), and the memory/disk/transfer overhead are practically irrelevant at this point. The only remaining reason to have dynamic libs is the idea that they can be updated without help from upstream, but that really only works if the software is compatible with the latest libraries, which isn't always true.

Supposedly ProGuard has some cross-module dead code elimination for JARs, but I haven't tried it: http://proguard.sourceforge.net/

Post reply on HN