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

Software Disenchantment (2018)

tonsky.me

Post reply on HN
Print view View original

231–240 of 504 posts

Re: Software Disenchantment (2018)

#231

Post by lxe »

I’m tinkering with the Atomic PI SBC — Quad Core 1.5ish GHz Intel Atom with 2 Gigabytes of RAM. You can load up an OS and launch Firefox with maybe 3 tabs until you run out of memory and have to page out (which will basically hang the device due to eMMC/flash I/O speeds).

These kind of specs are incredible for a high-end desktop machine from 15 years ago that would be good for almost anything — gaming, browsing, etc... What happened to software (Linux & Friends, Firefox, etc) that renders hardware obsolete so quickly? Is it just purposeful optimization that uses more RAM to benefit performance elsewhere, or is it truly this disenchantment?

Re: Software Disenchantment (2018)

#232

Post by ratww »

saberience wrote: post #73
thanhhaimai wrote: post #45

Earlier quoted context omitted.

> "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. I'll prioritize the 0.005L per 100km car for sure. That means the car can be driven for all its expected lifetime (500k km) in a single tank of gas, fill…

The big problem is this, if we related this back to software it would mean the software being delivered in 10-15 years, rather than in 6 months. Kind of a big downside...

That's the old Ruby on Rails argument. In that specific case it only made sense when there were no similar frameworks for faster languages, but that's hardly the case today.

Re: Software Disenchantment (2018)

#233

Post by wtetzner »

ljm wrote: post #30
rogerdb wrote: post #20

> Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? I think the analogy here is backwards. The better question is "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. If bas…

I have to be careful about what I describe, but I don't think people care about speed or performance at all when it comes to tech, and it makes me sad. In fact, there are so many occasions where the optimisation is so good that the end user doesn't believe that anything happened. So you have to deliberately introduce delay because a computer has to feel like it thinks the same way you do. At my current place of emplo…

I’m sure some sort of instantaneous indicator (e.g. a checkmark icon appearing) could be used instead of inserting artificial delays.

Re: Software Disenchantment (2018)

#234

Post by Wowfunhappy »

zozbot234 wrote: post #25
criddell wrote: post #24

Earlier quoted context omitted.

The overpowering desire is to make more money for your shareholders. That sometimes isn’t going to align well with the interests of end users.

Except that it also happens with internal software, where there's no separation between developers and end-users. It's second-system effect writ large. "We'll rewrite this old, outdated software and add plenty of bells and whistles! This time will be different, we'll finally be doing it right."

See, to me, internal software may be the one place where "developer time" really is more valuable (depending on the size of the organization), because you're developing for far fewer uses.

One second times five million users is almost two months. One second times five thousand users is less than 90 minutes.

Re: Software Disenchantment (2018)

#235

Post by lallysingh »

avip wrote: post #108
thrower123 wrote: post #100

Earlier quoted context omitted.

Google Maps is just horrible on mobile when you aren't on Wifi. I'd like to wireshark it some day to figure out just how many different web requests it is making.

You don't need wireshark - open dev console and observe that any map operation (drag/zoom/draw and anything else) requires an api request to gmaps. You can contrast that with mapbox which seems to have been designed upfront with offline mode in mind.

Google probably wants the usage data, so they take additional load to handle more requests.

Re: Software Disenchantment (2018)

#236

Post by gonational »

mtm7 wrote: post #176
anilakar wrote: post #127

An unpopular but effective short-term solution: Developers ought to use five year old hardware for development and testing tasks. FWIW, my work laptop and mobile phone are both 2015 models and I feel they're completely adequate for running all the software I've written.

I remember a story about an electronic musician who preferred to mix his songs with earbuds/headphones instead of with a high-end megabucks studio sound system. His reasoning was basically, “that’s how my fans will listen to my music, so I need to make sure it sounds good to them.” I can’t remember who it was, but the idea always stuck with me. Anyway, I agree that we should test our applications with the same hardwa…

That’s funny; I’m always debating my brother, talking about how earbuds sound much better than even high-end monitors, largely because of the surrounding environment (or lack thereof, when earbuds are in).

When I make music I have to do the opposite; take my earbuds out and listen to the music over my car stereo or via my MacBook Pro speakers, to make sure it doesn’t sound good only through earbuds.

Re: Software Disenchantment (2018)

#237

Post by davnicwil »

> Linux kills random processes by design. And yet it’s the most popular server-side OS

There's no reference for this in the article, and it caught my attention - anyone have any idea what the author is talking about here? Never heard of this before

Re: Software Disenchantment (2018)

#238

Post by jakear »

Yet another Electron hit-piece... curious, how do other cross-platform frameworks compare in both build time and live-reload time? For comparison, VS Code clean builds in about a minute, and a change-build-reload dev cycle is about a second or two.

Re: Software Disenchantment (2018)

#239

Post by coldtea »

juststeve wrote: post #158
coldtea wrote: post #62

> You’ve probably heard this mantra: “Programmer time is more expensive than computer time.” What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time. The argument is incomplete. The correct question (to maintain the analogy) is: "Would you buy a car if it eats 1000 li…

But in your example, your only describing one specific task (n=1). The issue is that time accumulates non linearly as the number of tasks increase. i.e the petrol stations must be able to supply enough petrol to all customers that drive the most inefficient car. The culture of "developer time is most important", makes overall system performance someone else's problem, because "my program is fast enough when I measure…

>But in your example, your only describing one specific task (n=1).

That's to maintain parity with the example TFA gives. I'm not saying it's never worth it... Of course you'll optimize often repeated tasks, loops, etc.

Here's what TFA quotes as bad reasoning, because it makes fun of optimization effort in some cases:

"@tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I’ll make my time back in 41 years, 24 days :-)"

Unlike TFA I agree with the twitting guy above that the efficiency improvement here wasn't worth it.

Re: Software Disenchantment (2018)

#240

Post by TeMPOraL »

AgentOrange1234 wrote: post #210
johnr2 wrote: post #35

One thing nobody seems to mention is the environmental cost of inefficient software. All those wasted CPU cycles consume electricity. A single laptop or phone on it's own is insignificant, but there are billions of them. Combine that with the energy wasted shovelling unnecessary crap around the internet, and it adds up to a big CO2 problem that nobody talks about.

Sure: If you can optimize the software that runs on many millions of computers then you can have a huge impact. If you run those computers yourself you can even save money. But the vast majority of software is one-off stuff. It makes no sense to optimize it for performance instead of features, development time, correctness, ease of use, etc.

> But the vast majority of software is one-off stuff.

Is it now? I can't think of any example, except a few tools we use internally in a project. Everything else I use, or I see anyone else using, has an userbase of many thousands to millions, and a lot of that is used in context of work - which means a good chunk of the userbase is sitting in front of that software day in, day out.

Post reply on HN