Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

41–50 of 504 posts

Re: Software Disenchantment (2018)

#41
post #30
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…

Regions that use the metric system use liters per kilometer. "The less fuel needed for the same distance, the better."

Re: Software Disenchantment (2018)

#42
I agree with the overal sentiment, yet the examples could be better.

> Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and also process input, recalculate the world and dynamically load/unload resources. How come?

Text is very complicated. Does your 42-year-old Emacs support Unicode? And not just accents, but whole different scripts?

See https://news.ycombinator.com/item?id=21105625 for some discussion and a good link about the complexities of rendering text.

Re: Software Disenchantment (2018)

#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 see what busses are going through a stop and where they are heading.

So yes, optimization is still important.

We replaced the glorious and easily iterated and expanded google maps app with a photograph of a public transport map, and we could get an answer of how to get from any A to any B within seconds of looking at the map without typing or searching or waiting for anything.

Which also shows that, sometimes, slow software is less than useless.

Re: Software Disenchantment (2018)

#44

I agree with the overal sentiment, yet the examples could be better. > Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and…

I'm not sure if the author meant current versions of emacs (with their 42 year lineage) or not. But if that's the case, then I think emacs was one of the very first to support Unicode and whole different scripts. If my memory does not fail me, emacs had extensive wide character support long before Unicode. With an extraordinarily broad treasure trope of different input methods on top.

emacs has also always been (in)famous for its text update render algorithms, that probably still work well over the old slow terminal lines it was originally used for.

Re: Software Disenchantment (2018)

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

> "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, filled up at the time of purchase! That means there is a huge opportunity to further optimize for many things in the system:

- The car no longer needs to have a hole on the side for filling up. A lot of pipes can be removed. Gas tank can be moved to a safer/closer location where it is used.

- The dashboard doesn't need a dedicated slot for showing the fuel gauge, more wirings and mechanical parts removed.

- No needs for huge exhaust and cooling systems, since the wasted energy is significantly reduce. No more pump, less vehicle weights...

Of course, that 0.005L car won't come earlier than a good electric car. However, if it's there, I'd totally prioritize it higher than other things you listed. I think people tend to underestimate how small efficiency improvements add up and enable exponential values to the system as a whole.

Re: Software Disenchantment (2018)

#47
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 hear that argument very frequently and I don’t buy it.

Think about all the gas that is saved because people don’t have to drive to the library, all the plane trips saved by video conferencing, all the photo film, all the sheets of paper in file cabinets, all the letters being sent as emails, all the mail order catalogues, ... you get the idea.

Does anybody know of a comprehensive study on this?

Re: Software Disenchantment (2018)

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

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

Re: Software Disenchantment (2018)

#49
post #36

Something no one has said which probably should be mentioned is that programmers today are just not as good as programmers of yesteryear.

Perhaps it's more that most (not all) of the many programmers today are not as good as the (relatively fortunate) few who had access to computers in the past.

In fact, I'd go so far as to suggest there are more good programmers about today then there were in the past. Though having said that, percentage-wise I'd say the profession is definitely being deskilled (good thing if you're a manager, bad thing if you're a good programmer).

Re: Software Disenchantment (2018)

#50
I agree with this.

I think we need a guild. We need licensed software engineers.

Not every programmer needs to be one, just like not every engineer needs to be licensed, but there needs to be a licensed engineer on every team. And, of course, sometimes there doesn't need to be. But I sure wish there was the option.

And hell, bring back apprenticeships and mentoring with the guild. There is so much we could learn from the physical science engineering disciplines

Post reply on HN