Live data from Hacker News

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

twitter.com

211–220 of 451 posts

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

#211

"amber-screen library computer in 1998: type in two words and hit F3. search results appear instantly" Bullshit. The search results appear instantly if you are searching a small text file in an editor. But if your app is actually fetching the data from somewhere, a dBase database on a network disk mounted from a Netware server, good luck. You type your words, you hit the search key and then you wait. There is no indi…

Exactly so. I used those computers back in the day. I actually designed library software in the 80s. Users today would go crazy waiting for the hard drive a 10Mbps Ethernet connection away to slowly pull data out of dBase database.

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

#213

This is a very hard rant to read. The examples either aren't factually true or are poorly explained and the "solution" is largely nebulous. I feel like this topic has merit and with a well written article with real examples (both 2019 and 83) it could be something special, but this isn't that. I'd be interested to know how many upvoted based on the title/what they expected this to be, rather than after having tried t…

I read the whole thing. I thought it was a pretty trash rant. My thoughts while reading roughly went:: "Everything was blindingly fast in the 80s!" - Yes you fuckwad, it was the 80s and the vast majority of content was local to your machine, or your machine was really just a terminal wired to a nearby mainframe. Do I need to link the "latencies every programmer should know?" article yet again? https://people.eecs.ber…

>"Everything was blindingly fast in the 80s!" - Yes you fuckwad, it was the 80s and the vast majority of content was local to your machine, or your machine was really just a terminal wired to a nearby mainframe. Do I need to link the "latencies every programmer should know?" article yet again?

No, fuckwad, that's not it.

Totally local UIs are much slower too, as often are local actions of remote UIs (e.g. typing, before anything is sent to the internet for that latency to be involved).

There's the added latency of modern OS, hardware, and application layers (e.g.: https://pavelfatin.com/typing-with-pleasure/).

Plus, of course, fuckwad, there are tons of apps that could be local, but are just made either remote, or with slower web layers like Electron, just because (it might be easier or more convenient to port, but the author's point still remains: it's less responsive).

P.S. Did you enjoy being called fuckwad? If not, don't calls other that.,

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

#214
Hey, the purpose of a computer is to consume electricity while running IA-mandated corporate policy enforcement and virus scanning software. That we provide users with monitors and input devices so that they can use any remaining spare CPU cycles on whatever machines just happen to be located near their desks to help themselves do their "jobs" is just icing on the cake.

They should be grateful if opening a modestly-sized word document takes less than 10 seconds.

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

#215
post #145

Earlier quoted context omitted.

I appreciated his complaints, but not his solution. Only a programmer would think that going back to keyboards is a good idea. Most people are happy waiting for a few seconds for their webpage to load, if it means they can do it without learning anything new. Programming is a profession, and we design software for people who have other interests than software. Many of us would be better off if we got better at empath…

> Only a programmer would think that going back to keyboards is a good idea. He goes too far and his suggestions are nebulous. But it sure would be nice to go back somewhat to the keyboard. There are so many apps with broken tab-orders; so many common operations without common shortcuts; so many badly tuned completion engines; bad interactions with autofill, etc. There's a whole lot of stuff that I could do faster on…

And you have to have 3 browsers because 2 of them are broken on some field. I wonder how often updates cratered green consoles back in the day. Curses could be tricky at times.

The path for many commercial UIs seems to be to map out complex processes into the most linear common path so that anyone off the street could do it. All that mouse action kneecaps productivity, and as soon as you come to an exception you enter a hell of popups or bazaar of UI elements.

Then of course they chop out all the keyboard ahortcuts.

Great UX is sort of like fusion, it’s always 30 years away.

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

#216
> Suppose during my regular game development everyday life I've installed Photoshop recently and I want a look at a screenshot of the game - someone reported a problem or something.

> So I double-click on the thing ... one ... two ... three ... four ... five ... six ... it's about seven seconds before I can actually see the image. [...]

> So that's really slow and I'm going to talk about that for a bit, but there's an element of severe irony to this which is that as soon as I double click this thing within one second it draws an image and it's a pretty high resolution interesting image. It's just not the image that I care about.

> So obviously it's not hard to start a process and draw an image on the screen in much less than seven seconds. They just don't manage that.

> Now. I gave a speech a year ago that started this same way. That was 2016. It's now 2017 and of course a new version of Photoshop has come out and of course what will align directly with my point in the next few slides: they've made it worse. And the great way in which they've made it worse is: say there's some operation that you want to do maybe once in a while like create a new image... So I'm going to go to file, new ... Urghh. And that menu takes - it probably takes about a second to come up.

> And you might think "Oh, well, you know it was just all these assets were cold or something.. Maybe they come off the hard drive. It'll be faster next time." And it's like: "Well, let's test that out. Nope." Like every time. I'll use the keyboard shortcuts. File. New. Nyeaarghh. [...]

> Imagine if the people who programmed this were trying to make VR games. Everybody would be vomiting everywhere all the time.

> Well what machine am I running this on? It's actually a pretty fast machine, it's a Razer Blade laptop with a pretty high-end i7 in it, and you can talk about how fast the CPU is or the GPU is and some arbitrary measurement and I'm going to discuss CPU speeds here and I want to say in advance that none of what I'm about to say is meant to be precise or precise measurements. I'm making a general point.

> And the general point is that the CPU of this thing would have been approximately the fastest computer in the world when I was in college. Or the GPU would have been the fastest computer in the world in the year 2000 or thereabouts.

> Now you might say "That's a really long time ago. This is ancient Stone Age." Well. Photoshop was released in 1990 before either of those dates. And Photoshop 6, which I used heavily during my earlier days in game development is from the year 2000. And this is what it looks like. This is a screenshot of Photoshop 6. It's got all the same UI that Photoshop has today. It's got all these same control widgets and it's got our layers and channels and all that stuff. Today the UI is a different colour but apart from that it's essentially the same program.

> Now I don't doubt that it has many more features. But you have to ask how many more features are there and what level of slowdown does that justify?

- Jonathan Blow, Reboot Develop 2017: https://www.youtube.com/watch?v=De0Am_QcZiQ&t=155

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

#217
post #72

I had an Atari ST in a closet, and decided to get rid of it a while back. I pulled it out to test it. The boot sequence, all the way to a desktop with a mouse that moves, takes less than one second. If you boot from a hard drive, maybe another second. For a while I just kept hitting the reset button, marveling at the speed at which the ST came up. Most machines I work with these days take minutes to get rolling. Okay…

Corporate windows installations are unnecessarily slow because they run antivirus and all kinds of domain membership stuff in the boot and logon path. A clean install with fast boot and without that gunk takes seconds. A headless linux can come up in seconds (UEFI fast boot + EFI stub) or even less than a second if you're in a VM and don't have to deal with the firmware startup. Booting to a lightweight window manage…

I'm actually relatively confident that you could get it down to 8-9 seconds to the basic X environment with an NVMe SSD and maybe even less if you were to cache some application states.

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

#218

Earlier quoted context omitted.

The example for maps is not a "hyper specific use case": "The process you WANT: pick your start and end. now start searching for places in between. Your start and end are saved. When you find someplace interesting, add it to your list. Keep doing that, keep searching and adding." That's a common use case. The problem with Google maps (and the problem with a lot of modern software) is, as you say, it makes a lot of gu…

> The process you WANT: pick your start and end. now start searching for places in between. Your start and end are saved. When you find someplace interesting, add it to your list. Keep doing that, keep searching and adding Am I missing something - this use-case is already supported! You choose start & endpoints, then your start the trip (which "saves" them) - you can now search and add as many waypoints as you desire

That's what I was thinking, I do that all the time.

For example, do a map of San Francisco to New York City. Now you want to visit the world's largest ball of twine, so you add a waypoint, and start typing "Ball of Twine" and a drop-down will appear with a few choices, pick the one you want and it'll add to the map. You can re-order them as needed to optimize your route.

You still need to know the name or address of the waypoint you want to add, but that's the case with paper maps and is a good use of browser tabs to search for it.

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

#219

There are some good points here, but of course I am going to ignore those to talk instead about the stuff I disagree with! The section about google maps follows a form of criticism that is widespread and particularly annoys me, namely => popular service 'x' doesn't exactly fit my power user need 'y', therefore x is hopelessly borked, poorly designed, and borderline useless. There is always room for improvement, but a…

>But balance that against the 100s or 1000s of times you used google maps and it just worked, perfectly, because it reduced the number of inputs needed to use it to the bare minimum.

I can't, because the autocomplete/dropdown/prediction for saved locations is disabled if you don't enable Google's device-wide "Web and App Activity" spyware function. This means I have to type my address every time I want directions home, even though I manually saved it. It's hot garbage.

Another very common usecase which is impossible: getting directions to a place and then looking at the street view so I'll know what it looks like. I have to remember to check street view before the search or redo the search entirely. Again, hot garbage, and inexcusable for a company spending bazillions of dollars on UX people.

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

#220
post #13

Earlier quoted context omitted.

The central reason is that modern video codecs use I-frames and P-frames (sometimes also B-frames; even though as far as I am aware, these are not used for TV broadcasts); see https://en.wikipedia.org/w/index.php?title=Video_compression... I-frames are only sent, say, once or twice a second. When a channel is switched, the TV has to wait for the next I-frame, since P-frames (and B-frames) only encode the difference t…

The tuning chip costs maybe 50 cents or something. Just have 3 or 4 of them and pretune the next few channels.

> The tuning chip costs maybe 50 cents or something. Just have 3 or 4 of them and pretune the next few channels.

That's 50 cents the shareholders can pocket, and everyone has already inured themselves to the slower experience.

Isn't progress great?

Post reply on HN