Software bloat makes me sad • Hacker News Board

Re: Software bloat makes me sad

#81

Post by lsaferite » Fri, Jul 03, 2015, 3:26 PM UTC

tribaal wrote: post #2

That's pretty much the only reason I cringe every time somebody writes a piece of client code in golang. While I really like the language itself, statically linking everything is creating exactly what this article describes. Burn karma, burn. I don't care.

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.

Re: Software bloat makes me sad

#82

Post by al2o3cr » Fri, Jul 03, 2015, 3:29 PM UTC

"In fact, in my experience the process of finding such bottlenecks on running systems is itself quite time-consuming - time which cannot be spent actually reducing bloat."

Wow. Talk about a self-refuting argument. If it's hard to figure out where to optimize a RUNNING system, how is it supposed to be easier to do so when the system is being created?

Arguing "bloat" is "bad for performance"? No problem - graphs or GTFO. Otherwise all you're left with is the emotional "OMG NUMBERS ARE HIGHER NAOW THAN BEFORE" drivel.

Re: Software bloat makes me sad

#83

Post by pjc50 » Fri, Jul 03, 2015, 3:30 PM UTC

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?

Re: Software bloat makes me sad

#84

Post by kazinator » Fri, Jul 03, 2015, 3:31 PM UTC

redcalx wrote: post #37

kazinator wrote: post #28

Earlier quoted context omitted.

Firstly, lack of optimization for software size or execution time is a form of optimization: it's optimization of someone's time. Not writing a compiler for your scripting language saves you years. Not choosing carefully what features to include in a program, or what packages in a system image: design time saved again. It also saves considerable time if a user wants the program to do something, and by golly, "look, t…

I agree with the general point, however, I believe it's commonplace for software to be poor on those other metrics you mention too, i.e. the one metric that /has/ been optimised is development cost. All of the optimal outcomes define a Pareto front, i.e. spend time optimising feature A versus speed, cost, etc. But as soon as you bring in low(er) quality engineers you're moving away from the Parento front, probably qu…

I.e. not only will there be bloat, but users won't find the features they need, it will be delivered late, and with bugs, etc. :)

Re: Software bloat makes me sad

#85

Post by Kaali » Fri, Jul 03, 2015, 3:33 PM UTC

mwcampbell wrote: post #76

Kaali wrote: post #70

Earlier quoted context omitted.

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…

> 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. There's more to non-nativeness than just…

Accessibility is a point I didn't think about at all. Thanks for reminding me, it's really something that is all too often forgotten. JavaFX supports ARIA and all standard controls have accessibility built-in. But I have no expertise to actually comment on the quality of accessibility features in JavaFX.

Re: Software bloat makes me sad

#86

Post by pjc50 » Fri, Jul 03, 2015, 3:34 PM UTC

tormeh wrote: post #55

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…

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.

Re: Software bloat makes me sad

#87

Post by Twirrim » Fri, Jul 03, 2015, 3:35 PM UTC

scrollaway wrote: post #50

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…

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

Re: Software bloat makes me sad

#88

Post by cbd1984 » Fri, Jul 03, 2015, 3:35 PM UTC

lsaferite wrote: post #81

tribaal wrote: post #2

That's pretty much the only reason I cringe every time somebody writes a piece of client code in golang. While I really like the language itself, statically linking everything is creating exactly what this article describes. Burn karma, burn. I don't care.

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 to be equivalent to solving the Halting Problem the moment the EVAL function is called, so if the tree-shaker found any mention of EVAL anywhere in the code (probably after it had removed the provably dead code) it punted and linked in the whole Lisp runtime. It was the only viable solution, really, especially given how creative Lispers can get...

Re: Software bloat makes me sad

#89

Post by deckiedan » Fri, Jul 03, 2015, 3:35 PM UTC

I agree in general, but the 'vim in combination with a few small plugins may lead to your whole computer locking up' is extremely misleading.

It's the editor which has frozen, not the whole computer. And the plugin in question is a fairly complex autocompletion / analysis plugin for python. There's a bug listed in that thread, to do with it scanning all the files millions of times, but the big problem actually isn't bloat, in this instance, it's the non-async nature of vim. neovim should, I hope, solve the 'totally unresponsive' problem, and hopefully someone fixes the rope/vim interaction re-scanning all the files bug.

But it's not bloat, per se.

If your whole computer is locking up due to this, then that's a scheduling issue, and you could try switching scheduler, or lowering the 'nice' priority of that program.

Not that we should have to care about such things - that's pretty terrible.

Re: Software bloat makes me sad

#90

Post by kazinator » Fri, Jul 03, 2015, 3:36 PM UTC

omegaham wrote: post #62

drabiega wrote: post #38

Earlier quoted context omitted.

Because bloat is like government. Multiple people might agree that there's too much of it, but they don't necessarily agree on which parts should be gotten rid of.

This. As always, there's a relevant xkcd[1]. Features that I might decry as bloat are probably someone else's "necessary, to be preserved at all costs" features. If you want to cover a large number of use cases, you have to include all of them. And with that comes bloat. There's a reason why even a minimalist CLI-only Linux installation requires more than 24MB of RAM when Windows 3.1 runs on 3MB - the Linux kernel is…

A minimalist CLI-only Linux installation was still possible in around in 2 megs of RAM in 1994.

A minimalist XWindow installation was possible with a 40 megabyte hard drive and 4 megs of RAM over a 386 CPU. (That's similar specs to what 68K-based Sun workstations had perhaps a decade before that.)