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...
Software Disenchantment (2018)
141–150 of 504 posts
Re: Software Disenchantment (2018)
#142Earlier 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…
Also I'll bet you that your neural net is > 100x slower than straight line code.
Re: Software Disenchantment (2018)
#143The 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)
#144One 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/
Fascinating talk. Thanks for the link.
Re: Software Disenchantment (2018)
#145One 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.
Re: Software Disenchantment (2018)
#146> Modern text editors have higher latency than 42-year-old Emacs. Hmmm. Let's think about this.
Re: Software Disenchantment (2018)
#147Earlier 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…
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)
#148Earlier 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…
Re: Software Disenchantment (2018)
#149I 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.
If you mean UX, then fair enough.
Re: Software Disenchantment (2018)
#150> 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…
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.