Live data from Hacker News

Almost everything on computers is perceptually slower than it was in 1983

tttthreads.com

81–90 of 349 posts

Re: Almost everything on computers is perceptually slower than it was in 1983

#81
post #2

Given the speed of modern computers, I'm fascinated by the fact that so many processes complete in human-scale time (seconds-minutes), rather than milliseconds or years+, depending on problem complexity. If times for compute tasks have some power law distribution (a big if...), I'd expect a very small part of that distribution to overlap with the 'seconds' range. Then again, computers do so many things in the millise…

It's a relief to do a bit of Go from time to time, render a complete html template in 40 ms (with almost 2 MB of JSON data) instead of spending forever figuring out the JS framework du jour to do the same thing, only with it feeling a lot more involved, heavyweight, and slow - even if said framework claims to be faster than all the other JS frameworks. I think I want to do back-end or terminal-based interfaces again.…

This has nothing to do with Go and a lot to do with choosing the right tool for the job. Maybe Go is the best tool for you in this job, but a given js framework can serve someone else just as well if it is in their expertise area. Don't confuse your expertise with language/ecosystem pros and cons.

Re: Almost everything on computers is perceptually slower than it was in 1983

#82
My terminal responds more quickly than it did in 1983. In every other way computers have subsumed televisions as entertainment devices, and have performance characteristics appropriate to their main uses.

Because of Moore's law advances, the industry has learned to design for the next generation CPU. Before Moore's law was understood, industry designed for the current hardware and everything was extremely fast.

In a way I wish RIM had won the smartphone wars, but after the patent loss and removal of the click wheel, the devices were far less usable.

Apple's foray into Skeuomorphism offers us a history of the competitive landscape for usability and design. Skeuomorphism is a way of avoiding the learning curve associated with abstractions. If the software is meant to let the user take notes, making the screen yellow with lines on it helps the most abstraction-resistant users grok what is going on.

Most adults can't do basic algebra, so it should be no surprise that the dominant mobile software platform succeeded only after substantially dumbing down the UI to the point where it was essentially abstraction free.

With Jony Ive taking more control of iOS we are finally breaking free of the Skeuomorphic training wheels. Google's material design is an ambitious attempt to create an abstraction that retains some of the more textural and familiar "material-ness" of real-world objects, without resorting to crude mimicry. I wouldn't say it's close to perfect, but it is promising.

So consider the need for a fast GPU and high res graphics in a mobile device to be (in a sense) a tax that we must pay to help the small percentage of abstraction-phobic luddites understand how to write a note or add a meeting to the calendar. It also makes the device useful for gaming and for watching TV, which many people enjoy doing and which create massive revenue for content companies.

Apple came to dominate the smartphone market because it understood that consumers wanted an all-purpose device that didn't shove too many abstractions down anyone's throat, had decent video games, would let you watch TV and movies, did not feel like using a computer.

With Android, Google has mostly stayed behind by about one year to cut costs and capture market share, but has increasingly been focusing on delivering a top-tier experience and offering/supporting top-tier hardware.

Movies, shows, and songs make up 99% of most users' stored data. So of course the device needs to work with that data. Any comparison to 1983 cannot consider such massive data because it was unfathomable. Back then we thought calendars, note taking, simple spreadsheets, etc., were what computers were good for. Nobody realized that they would become handheld TVs with a built-in gossip rag with custom content about all of our friends.

We will someday reach a point where a mobile device reaches "peak dopamine", meaning that no further improvements will be necessary to make the device more entertaining or more addictive. We have a long way to go, and a lot more transistors will be needed in the hardware to reach peak dopamine, so we can expect the trend to continue. UI responsiveness figures in somewhere, but is obviously not the main driver of hardware cost increases.

Re: Almost everything on computers is perceptually slower than it was in 1983

#83

It's a tragedy of the commons. It's very rare for one piece of software to be solely responsible for slowness, but each individual piece contributes just ever so slightly. I happen to know quite a bit about front-end technologies, so I'll speak to those. Bootstrap is around 100 kilobytes. One hundred thousand bytes - after gzip and minification. By itself, is it slow? Not very. Bootstrap fans will point you to endles…

> I spent years of my life working on a CSS framework 100x smaller than Bootstrap

Interesting! Can you share that?

Re: Almost everything on computers is perceptually slower than it was in 1983

#84
post #4

The core point of the entire thread can be summed up by one of the tweets; "I believe well designed keyboard interfaces and well designed GUI interfaces have exactly the same learning curve." I agree with this. A properly and well designed keyboard interface is faster than any mouse. On the other hand, a properly designed mouse interface can be fast too. Both need to be applied when it makes sense. I can also resonat…

This is a really interesting idea. It suggests that there is an entire missing world of terminal-like web apps.

I suppose that search is effectively a text based app, so that's at least one mainstream terminal-like app.

Re: Almost everything on computers is perceptually slower than it was in 1983

#85
post #21

Earlier quoted context omitted.

Just last week I discovered I could disable animations in Android through the hidden developer options. It's fabulous. The only initial quirk was no visual feedback when a picture is successfully taken, so it felt like i missed the button, but I've gotten used to it already.

!!!!! That is a amazing!!! I had no idea developer meant "interested user". > Make sure developer options are enabled. If they're not, go to Settings > About phone, then tap on Build number several times to enable it > Go to Settings > Developer options, and scroll down to Window animation scale, Transition animation scale, and Animator duration scale. > Tap on each of the animation options and turn them off. https:/…

On my first try I accidentally tapped "Android version" instead of "Build number" :)

Re: Almost everything on computers is perceptually slower than it was in 1983

#87

This! I once took over programming a point of sale system that our (internal to the company) users were complaining about. Turns out there was no concept of tab sequence, you had to use the mouse for everything. I asked the previous programmer to show me how to use the form he created, and he started typing a phone number using the top row of the keyboard instead of the numpad. But hey, it had lots of javascript!

I don't get your point about typing phone numbers. When I was being taught to touch-type in first and second grade, my teachers told me that I should type on the top row, not the numeric keypad. Not sure why. Maybe because it takes less time to move to the top row and back? Anyway, to me, typing numbers on the top row is not an obvious problem.

When most of the stuff that you type are numbers then numpad makes more sense than top row (also, many non-english keyboard layouts have numbers in top row shifted).

For POS and similar applications it actually makes sense to design the UI such that it can be used only with numpad, for example by using +,-,*,/ as function keys for common operations.

Re: Almost everything on computers is perceptually slower than it was in 1983

#88

It's a tragedy of the commons. It's very rare for one piece of software to be solely responsible for slowness, but each individual piece contributes just ever so slightly. I happen to know quite a bit about front-end technologies, so I'll speak to those. Bootstrap is around 100 kilobytes. One hundred thousand bytes - after gzip and minification. By itself, is it slow? Not very. Bootstrap fans will point you to endles…

I've written many sites with React, Bootstrap, and a dozen or three other third party dependencies, but I've never run into a case of a button not responding when clicked or things taking a noticeably long time to load (assuming that the server processing or sheer size of the payload over the network isn't the cause).

I think a lot of it boils down to "don't do work you don't have to." But there's nothing about a framework that causes -- or saves you -- from that.

Re: Almost everything on computers is perceptually slower than it was in 1983

#89

I wonder how much of this is a result of UI designers deliberately putting tiny delays/animations into their UIs to make them more "usable"? For example, it was a common piece of advice that if clicking a button opens up a dialog box, there should be a brief animation showing the box expanding from the direction of the button, so the user would associate the clicking of the button with the appearance of the box and u…

Maybe those animations could be sped up with continued use. Then new users get the visual connection between their actions and the response, while experienced users don't have to wait as long for the animation to play.

Re: Almost everything on computers is perceptually slower than it was in 1983

#90
post #54
post #6

Earlier quoted context omitted.

You have it on the head. The tasks we pick for computing are the ones that can be completed in seconds. There is plenty of interesting computation we could and would do if what now requires a year would only require a second.

I think the opposite direction is actually more telling. Developers tolerate bloat and BS up to the level of seconds. So there is plenty of computation being done that only requires milli or microseconds, but due to development practices now stretches just out into the annoying time frame. (Prime example: the growth of web pages to match increases in processing, RAM, and internet speeds, means that the web is actuall…

When the web was young and most people were on dialup, having access to a T1 meant that everything happened nearly instantaneously. All the sites were optimized for dialup levels of complexity. Now that everyone has broadband there is no equivalent. The slowness is either because the page is so heavyweight in terms of memory or processing power (note that more money does not buy much single-threaded performance), or because it's making so many network requests that everyone faces at a similar latency.

Even the fastest computer and the highest-end Internet access can't get you such a huge advantage in performance that it can make the web feel snappy again.

Post reply on HN