Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

141–150 of 504 posts

Re: Software Disenchantment (2018)

#141

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

Not necessarily. For one, relating this doesn't remove the ability for incremental development. Another thing, there's very little actual innovation in software being done. Almost anything we use existed in some version in the past two or three decades, and it was much more faster, even if rougher at the corners. Just think how many of the startups and SaaS projects we see featured on HN week after week are just reimplementing a feature or a small piece of workflow from Excel or Photoshop as a standalone web app?

Re: Software Disenchantment (2018)

#142

Earlier quoted context omitted.

> I'm thinking why not train a LSTM to take in http requests and generate the http response? Why? With responses generated according to what? Are you really just suggesting using neural networks in the compiler's optimiser? > Then try using a smaller network until something like your registration flow, or a simple content management system was just a bunch of floating point numbers in some matrices saved off to disk.…

I'm suggesting that you take an existing system and build up a corpus of request/response pairs. Then you use the LSTM to build a prediction model so that given a request it will tell you that the current production system will produce the following sql statement and this http response. Once the LSTM's output is indistinguishable from your current production system , for all use cases, then you replace the production…

What if your app has literally any mutable state? Registering accounts, posting comments, etc.

Also I'll bet you that your neural net is > 100x slower than straight line code.

Re: Software Disenchantment (2018)

#143
While I agree with the author's observation on efficiency and simplicity in modern software, I think that the article's tone is needlessly antagonistic. It read like a diatribe about all of us these terrible programmers screwing up software for him. Perhaps I am an exception, but so far the majority of programmers I've worked with were very conscious of their software's performance and worked hard on making it as fast as they could.

The problem is that when your software is built on top of a framework and/or uses X different web APIs etc then you often run into issues where a part of the system that you don't have control over causes performance issues and you don't have the expertise/time to profile it in order to fix it. So I think what's causing problems is that software has become a lot more about putting together frameworks, libraries and reusable components and when faced with such a complex system a programmer will often give up and say "there! it's as fast as I can make it without rewriting everything from scratch".

Therefore, the issue seems to be that programmers are building on top of other systems that they don't know enough about to use efficiently. The author does mention this issue in his article as well, but in a slightly derogatory fashion blaming programmers for bringing in dependencies they don't need.

I think if everybody had the time and ability to write everything from scratch like Jonathan Blow is doing with Jai then yes, things would be more efficient. It is far easier to profile and debug code you've written yourself. However, seeing how this isn't feasible for most projects, I think more focus should be put on better documentation of frameworks and libraries.

Re: Software Disenchantment (2018)

#144
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.

> it adds up to a big CO2 problem that nobody talks about if you haven’t seen it already, you’d probably be interested in the below talk by chuck moore, inventor of forth. https://www.infoq.com/presentations/power-144-chip/

> https://www.infoq.com/presentations/power-144-chip/

Fascinating talk. Thanks for the link.

Re: Software Disenchantment (2018)

#145
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.

I'm not sure in the accounting of the environmental costs of modern life that inefficient software counts for much. Doing totally pointless crap with highly efficient software might be worse.

Re: Software Disenchantment (2018)

#147
post #86

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…

This is definitely an interesting take on the car analogy so thanks for posting it! I don't know that I agree 100% (I think I could 'settle' for a car that needed be be fueled once or twice a year if it came with some other noticeable benefits), but it is definitely worth remembering that sometimes an apparently small nudge in performance can enable big improvements. Miniaturization of electronics (including batterie…

V8 would be one example. Some time ago, JavaScript crossed a performance threshold, which enabled people to start reimplementing a lot of desktop software as web applications. In the following years, algorithms for collaborative work were developed[0], which shifted the way we work with some of those applications, now always on-line.

That would be the meaningful software improvements I can think of. Curiously, the key enabler here seems to be performance - we had the capability to write web apps for a while, but JS was too slow to be useful.

--

[0] - They may or may not have been developed earlier, but I haven't seen them used in practice before the modern web.

Re: Software Disenchantment (2018)

#148
post #105
post #48

Earlier quoted context omitted.

> These days, I think most users will lose more time and be more frustrated by poor UI design, accidental inputs, etc. than any performance characteristics of the software they use. I’m willing to bet that a significant percentage of my accidental inputs are due to UI latency.

Don’t get me started with all the impressive rotating zooming in Google Maps every time you accidentally brush the screen. The usage story requires you to switch to turn-by-turn, and there’s no way to have bird eye map following your location along route (unless you just choose some zoom level and manually recenter every so often.) It’s awful, distracting and frankly a waste of time... just to show a bit of animation…

Well, Google Maps is its own story - it's like the app is being actively designed to be as useless as possible as a map - a means to navigate. The only supported workflow is search + turn-by-turn navigation, and everything else seems to be disincentivized on purpose.

Re: Software Disenchantment (2018)

#149
post #125
post #43

I was in Rome recently, and google maps were basically unusable on EDGE (dsepite pre-downloading the area before the trip). We'd wait a minute (or more) for a timetable of a bus stop and a route of the bus to be show on the map. Try planning a route in an unfamiliar area with this slow an UI when you are standing outside and there's no place to sit and rest, and you need to click around on a bunch of stops just to se…

I've found OSMAnd~ on F-Droid to be a good offline-only alternative, but it certainly has much worse efficiency problems than GMaps.

Do you mean computationally? Because I don't think that's a fair comparison.

If you mean UX, then fair enough.

Re: Software Disenchantment (2018)

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

A single dropped can on the grass is a small impact. Everyone dropping their litter everywhere, because "a piece of litter doesn't matter" is a large impact.

I can deal with a 1 second delay to run a script. I can deal with a 20 second delay to launch a large program. I resent dealing with hundreds of 1 second lags every day for tasks which didn't used to have any lags ten years ago.

Post reply on HN