Software bloat makes me sad • Hacker News Board

Re: Software bloat makes me sad

#131

Post by scrollaway » Fri, Jul 03, 2015, 5:29 PM UTC

Twirrim wrote: post #87

scrollaway wrote: post #50

Earlier quoted context omitted.

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

> Fun fact: KDE 4.x depends on ruby in most distros. Do you know why? Dolphin ships with a ruby script to update some folders (don't remember what it does). Nobody runs it. That's it. Why did they allow an additional dependency on Ruby in? It seems like perl or python would be the more logical choice, given they'd already be on the system (heck.. maybe bash?)

Bash would have been more appropriate, yes. I don't think the author of the script even thought it was going to be run by users, but some debian package checker probably flagged ruby as a dependency and there it was.

Re: Software bloat makes me sad

#132

Post by ZenoArrow » Fri, Jul 03, 2015, 5:46 PM UTC

mondoshawan wrote: post #126

ZenoArrow wrote: post #120

Earlier quoted context omitted.

Then use something else. It's not like you don't have a choice. https://en.wikipedia.org/wiki/List_of_web_browsers Based on your stated requirements, perhaps you'll like Dillo. http://www.dillo.org

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.

Re: Software bloat makes me sad

#133

Post by Shorel » Fri, Jul 03, 2015, 5:48 PM UTC

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 single Ubuntu user has complained at one point that pressing the Win/Super key does not bring the menu fast enough, or that the search results are not fast enough.

So, there's bloat.

Re: Software bloat makes me sad

#134

Post by Shorel » Fri, Jul 03, 2015, 5:54 PM UTC

Kaali wrote: post #70

tormeh wrote: post #55

Earlier quoted context omitted.

It's not that they have poor algorithms or whatever, it's that they're part native, to handle the desktop interaction and the rest is a bunch off html/css/JavaScript running in an embedded browser. At least that's how Spotify works. The problem is that our tools for making multiplatform native GUI's suck so bad we'd rather just embed an entire Web browser into everything.

There are some okayish cross platform frameworks, such as QT and even JavaFX. One of the main complaints of cross platform GUI's has been that they don't work like native applications. But for some reason nobody cares when the app works like a single page web app, which in many cases is a lot worse than even plain old Swing apps. Which at least supports right-click properly. I think the main reason that node-webkit a…

> One of the main complaints of cross platform GUI's has been that they don't work like native applications.

wxWidgets applications work like native applications because they are in fact using the native toolkits, and some successful applications, like Audacity, are written using wxWidgets.

And it runs fast, as it is C++, as expected. Why it is not used more fits perfectly with the content of this article.

Re: Software bloat makes me sad

#135

Post by Shorel » Fri, Jul 03, 2015, 6:04 PM UTC

bryanlarsen wrote: post #123

Lotus 1-2-3 is the textbook example of the benefits and costs of the speed / feature trade-off curve. A major reason for 1-2-3 becoming dominant was its speed and memory efficiency; it was written in assembler. If you had a 640K machine, 1-2-3 let you write bigger spreadsheets than anybody else could. But 1-2-3 was killed by Excel because it lost the feature race. It's origins in assembly language gave it a significa…

> But 1-2-3 was killed by Excel because it lost the feature race. It's origins in assembly language gave it a significant disadvantage in this race.

Yet the winner was written in C++ for many years, while the world was distracted with the less inefficient VB.

Now some parts are .Net, but the crucial parts are still C++.

Re: Software bloat makes me sad

#136

Post by lispm » Fri, Jul 03, 2015, 6:17 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…

Lisp still does that. The commercial Lisps Allegro CL and LispWorks have that as a part of their respective delivery toolkit.

See for example the LispWorks documentation: 4.6 How Delivery makes an image smaller, http://www.lispworks.com/documentation/lw70/DV/html/delivery...

Re: Software bloat makes me sad

#137

Post by fullwedgewhale » Fri, Jul 03, 2015, 6:36 PM UTC

XorNot wrote: post #103

adrusi wrote: post #91

Earlier quoted context omitted.

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

And you're giving what would be described as the exact opposite example to the parent post: why do node projects have hundreds of dependencies? Because those dependencies do exactly 1 thing most of the time (and usually pull in some other exactly 1 thing dependencies to do it).

That may be true in Node, but as a counter example, in Ruby, I saw dependencies creep into projects where there would be some minor point like "I need to do X" and that's done by library Y. In addition, Gem Y does A, B, C and D. In order to do all that it drags in several dependencies which are not directly needed. When you actually look at X, you realize it's not that difficult to do yourself. So at what point should you just write the functionality yourself and at what point do you rely on external libraries (and any baggage they can bring with them.) You have to maintain that code (even if it is fairly trivial), but you then have to maintain your dependency (keeping the gem up to date, maybe making small code changes to accommodate breaking changes in the gem). It can be a real mess.

Re: Software bloat makes me sad

#138

Post by a15971 » Fri, Jul 03, 2015, 6:43 PM UTC

The bloat is simply a side effect of the evolution. Software is not as much designed as evolved.

You make a name for yourself in SW development by adding features that others deem useful. You get money (in commercial setting) or prestige (in freely distributed software) if you seem to be producing something useful. It's trivially easy to recognize a contribution that adds code, but it's hard to recognize a contribution that means absence of something (e.g. absence of bloat, absence of memory hogging, ...). You get inclusion in newer, larger or more important projects easier the more you make yourself recognized.

So any useful software gains more contributors that add things than those who remove things. Commercial code can and does gain developers if it earns money, open source software gains developers if it is deemed useful by programmers.

This is a force that shapes both the group of involved developers and the resulting software in a process akin to evolution. In both cases the selection is biased towards adders of code. There's also always possible to add improvements that help some use cases and audiences. On the other hand, arguing for removing something or limiting might make you unpopular (you are seen as an obstacle to everlasting progress) and removed from the group of developers. Rare people have enough recognition and clout to prevent inclusion of something (Linus Torvalds is one of them - he can get away with rejecting patches to Linux kernel and he can play the role of the kernel guardian).

On the whole, software expands until it fills the resources available.

Re: Software bloat makes me sad

#139

Post by fullwedgewhale » Fri, Jul 03, 2015, 6:48 PM UTC

vlad wrote: post #58

I don't care if an app is 20% bigger in file size as long as the user interface makes sense and the product actually works, especially if the bloat is due to a programming language or architecture that makes it easier to add new features or fix bugs.

But what if it's 200% bigger? I remember reading an article that looked at the time it takes to load MS office under Windows. Even though computers over the last 15-20 years or so are much, much faster, the wall-clock time to get Word or Excel up and running has pretty much stayed constant. Granted, disks haven't kept pace with CPUs, but when your computer is 100 times faster and it still takes just as long... Is that a good trade off?

Re: Software bloat makes me sad

#140

Post by TheOtherHobbes » Fri, Jul 03, 2015, 7:33 PM UTC

pjc50 wrote: post #86

tormeh wrote: post #55

Earlier quoted context omitted.

It's not that they have poor algorithms or whatever, it's that they're part native, to handle the desktop interaction and the rest is a bunch off html/css/JavaScript running in an embedded browser. At least that's how Spotify works. The problem is that our tools for making multiplatform native GUI's suck so bad we'd rather just embed an entire Web browser into everything.

Hmm. Java went through this with AWT and Swing. You can have "identical on all platforms, nonnative, missing some native features and look&feel" OR "native features, look and feel, but different across platforms". Embedded browsers are closest to the former. It sounds like solution (for spotify at least) is better methods for each platform of creating a GUI around web services. Microsoft have sort-of had a go at this…

The solution is to promote the browser to a full VM container, with both low level and high level APIs for graphics, sound, networking, and so on.

Browsers are already closer to this than most people realise. By the time you've included websockets, openGL, webaudio, and bunch of other stuff, you're 90% of the way to a useful OS.

The problem is that the current state of the web "OS" is a random collection of ad hoc APIs hacked together for a completely different job, and it's very badly designed for what it's trying to do now.

In a perfect world the FOSS world would collaborate to thrash out a new spec, and also design a new browser to follow the spec which was backwards compatible with standard HTML etc, but also included new and more efficient APIs for much faster performance.

Something like this has already happened on servers - see also, containerised VMs running RoR or Node or whatever you want - and it's only a matter of time before it happens in browsers too.

The problem is that the current plan seems to be to build a VM layer on top of the existing DOM/js/etc layer, which will kill performance even further. It should really replace it and emulate it.