Live data from Hacker News

Code Inflation (2015) [pdf]

spinroot.com

31–39 of 39 posts

Re: Code Inflation (2015) [pdf]

#31

Some days I'm inclined to rant about software bloat. I've often quoted or paraphrased a bit of dialogue from the Scott Meyer novel _Off to Be the Wizard_ that's kind of funny but also pretty sad: Phillip (time traveler from 1984): What on earth can a person do with 4 gigabytes of RAM? Martin (from 2012): Upgrade it immediately. But on the other hand, some of what might be perceived as bloat is really useful, even nec…

> Accessibility requires extra code. In Windows 10, UIAutomationCore.dll is about 1.3 MB, and will no doubt get bigger as Microsoft continues to improve the accessibility of Windows. But you can't write that off as bloat.

I'm convinced that's not true. Consider the case of CSS and ARIA roles. You could very easily write CSS/JS components defined on roles using CSS 2.1 attribute selectors, and accessibility just follows naturally. For instance, define your tab panels using role="tab", and screen readers should immediately understand it, while for visual designs, your CSS and JS just select on the appropriate roles. You then use classes for non-semantic content, like font and colour instead of using classes for everything as is currently standard.

So you're not duplicating code, you're writing better semantic markup once which can be properly interpreted multiple ways in different media.

Not how it's currently done, but there's no reason it can't be done that way, even for desktop UIs.

Re: Code Inflation (2015) [pdf]

#32

Earlier quoted context omitted.

In cases where you might not be using a shell. Like, say you have a program that uses a user-specified program + arguments, like parallel or find -- but for evaluating a boolean condition. true/false would help.

The undeniable fact is that there will be a case for any scenario, and that fact is the essential driver for code inflation. You can't shed the code since that code is there for a potential case; and you can't help adding code as you keep discovering/imagining new cases. This is where a bit wisdom differentiates people. There is no winning trying to match exponential generality with our finite ability. So wise people…

Okay.

But if anything is the bloat it's the true/false shell built-in.

Re: Code Inflation (2015) [pdf]

#33
post #10

"the probability of non-trivial defects increases with code size." Intuitively this feels correct, I wonder if anybody has studied it.

Why does he specifically say "non-trivial" defects? The probability of any defect surely increases with code size?

Maybe because these are the most relevant ones? Trivial defects are easily detected and fixed. Or else they're not trivial.

Re: Code Inflation (2015) [pdf]

#34

Some days I'm inclined to rant about software bloat. I've often quoted or paraphrased a bit of dialogue from the Scott Meyer novel _Off to Be the Wizard_ that's kind of funny but also pretty sad: Phillip (time traveler from 1984): What on earth can a person do with 4 gigabytes of RAM? Martin (from 2012): Upgrade it immediately. But on the other hand, some of what might be perceived as bloat is really useful, even nec…

I don't disagree with your point, but I think you are over estimating how much code some of that takes.

The reality is that we use so much code because it is easier that way. And the added ease is very hard to remove.

Then there is data. A single picture is more storage than my first few computers had. Compression isn't magic.

Re: Code Inflation (2015) [pdf]

#35
post #6

Code inflation nicely cancels out gains from Moore's law. But there's also another interesting phenomenon seen in embedded hardware - it seems that each generation of devices has more (exponentially more?) computing power on-board, while the user-facing functionality stays the same or even slightly degrades. For example, the functionality of today's fridges, kettles and washing machines is equivalent to those made 20…

Which reminds me of this classic http://www.danielsen.com/jokes/objecttoaster.txt

Re: Code Inflation (2015) [pdf]

#36

Earlier quoted context omitted.

> while the user-facing functionality stays the same or even slightly degrades I would disagree with that on so many points. Today, more than ever we have massive differences. "Hey Siri/Google", the camera functionality is just incomparable, the maps, ... In the case of consumer white goods the business case is that expensive mechanical components and security mechanisms are replaced by electronic ones that are cheap…

But they're 1/10th to 1/5th of your monthly pay, and last 2-10 years, so why bother ? 2-10 years is an extremely short lifespan for white goods; 20-30 years is more like it, and 40-50 years is not uncommon. In the case of consumer white goods the business case is that expensive mechanical components and security mechanisms are replaced by electronic ones that are cheaper. It's not just that, but even mechanical compo…

Even the industry admits that white goods aren't built to last as long as they were the past. 40-50 years is unreasonable now. I'd be happy with 20.

Re: Code Inflation (2015) [pdf]

#37
post #34

Some days I'm inclined to rant about software bloat. I've often quoted or paraphrased a bit of dialogue from the Scott Meyer novel _Off to Be the Wizard_ that's kind of funny but also pretty sad: Phillip (time traveler from 1984): What on earth can a person do with 4 gigabytes of RAM? Martin (from 2012): Upgrade it immediately. But on the other hand, some of what might be perceived as bloat is really useful, even nec…

I don't disagree with your point, but I think you are over estimating how much code some of that takes. The reality is that we use so much code because it is easier that way. And the added ease is very hard to remove. Then there is data. A single picture is more storage than my first few computers had. Compression isn't magic.

True. It's particularly sad that so many desktop apps these days bundle a full browser engine (through Electron or the like) because it's so convenient. And I hadn't really thought about how much space photos take up because gasp I don't have a photo library. Music, though? That eats up space too.

Re: Code Inflation (2015) [pdf]

#38
post #6

Code inflation nicely cancels out gains from Moore's law. But there's also another interesting phenomenon seen in embedded hardware - it seems that each generation of devices has more (exponentially more?) computing power on-board, while the user-facing functionality stays the same or even slightly degrades. For example, the functionality of today's fridges, kettles and washing machines is equivalent to those made 20…

To bring us closer to this future:

https://www.youtube.com/watch?v=LRq_SAuQDec

Re: Code Inflation (2015) [pdf]

#39
post #34

Earlier quoted context omitted.

I don't disagree with your point, but I think you are over estimating how much code some of that takes. The reality is that we use so much code because it is easier that way. And the added ease is very hard to remove. Then there is data. A single picture is more storage than my first few computers had. Compression isn't magic.

True. It's particularly sad that so many desktop apps these days bundle a full browser engine (through Electron or the like) because it's so convenient. And I hadn't really thought about how much space photos take up because gasp I don't have a photo library. Music, though? That eats up space too.

Yeah, a ton of data goes to music and video. On the plus side, I no longer spend a ton of physical space on these. Not sure what is more wasteful, tons of movies and music I don't get to on my computer, or bookshelves of the same.

And I still have a fair number of books.

Post reply on HN