Yes, like typing a message in Slack takes longer to render on screen (at least a half second delay in some cases) than typing the same message on a Commodore 64.
Statement simply not true. First example is comparing offline interface to online one - more realistic comparison would be to something like first BBS's and the experience with those was generally insanely slow.
I didn't bother reading the rant because I think it doesn't make sense but is just personal "feeling" of the author. Objectively speaking computers are insanely faster and can do much more things. For exmple I use Sublime Text editor with multiple plugins and features, and all those feel instant. Also with web apps that I use 95% of time the experience is very instant-like.
Don't know about 1983, but a lot of software is definitely slower than it was 10, 20 years ago.
Something that used to result in 2MB application with 5MB in memory requirement is now done as half a gigabyte of resources that will spawn dozens of processes totaling at least 1GB of memory. Sure, computers are faster, but not by that much apparently.
Looking at all those electron (et al) apps. Cheap to write beats user experience I guess.
Scrolling text in text editors. Was always buttersmooth on 7 MHz Amiga. Is choppy in many of today's IDEs. I get that IDE does more than a text editor, but it would be great if adding extra features would not compromise existing ones.
I guess the underlying point is that in the same time period CPU speed has increased thousandfold, so you'd expect that to compensate for the few extra features that were added.
Bare syntax highlighting in a text editor on a large file. Nothing extra fancy like indexing or analysis. Not an issue 15 years ago, in VS code you can scroll faster than that.
Here is one: when you switched on a C64, the booting(startup) took probably less than 3 seconds. Booting a notebook these days takes longer (luckily it is not as bad as when we didnt have SSDs).
But generally I do not think the premise is correct. Loading a game from a datasette took easily 15 minutes (later there was acceleration only a few minutes)
Why isn't it a fair comparison? If my mother's only criteria is how fast does something load then why should she care about anything else?
It's a fact that nowadays a lot of apps are very slow, on computers and phones alike -- and socially and culturally that's unacceptable for non-technical people.
If the speed is the only criterium then you can just play old games.
It's not fair comparison since the games are completely different beasts today - huge open worlds, detailed textures, complex AIs.
Game studios could design games which are super fast to load and play but some other aspect would suffer instead. It's a trade off and it looks like users are OK with waiting a little bit if it means better gameplay.
Okay, but how did games enter this global thread's discussion? That's definitely way off-topic.
My mom simply wanted instantly loading calendar and grocery list apps. I know that's achievable because I've done (parts of) such apps in the past and they were faster than others.
It's not such a stretch to imagine people being frustrated with lags everywhere (and those lags do objectively exist). And I've met a good amount of people frustrated with the current breed of software as well.
Modern apps don't bring almost anything new or improved to the table. They should be lightning fast but they are not.
Cartiges don't have a loading time, and are a technology that is available today, but that people abandoned because they are expensive and difficult to update.
All true. I just feel we lost something along the way of ditching the old tech. Responsiveness, less input lag, stuff that you don't dread will spit out a cryptic message while rebooting... And another metric ton of these.
Oh, by all means, things should load faster today than what we got with floppy disks, and response should be faster than what we got in an interpreted program in a 8MHz machine.
It's just the load time of cartiges that aren't a fair goal.
IDEs are I think a good example. There were IDEs in the 80s and 90s but they are very different from now.
For example back then they did not index files at startup since there was no function for that (like "find references"). These days IDEs provide a lot of "intelligence" and static analysis for which you need memory, a lot of reads and processing.
So yeah, I guess VS got slower but it's because it's now doing much more (useful) things.
Let's go with emojis in Slack. That was not an issue in any chat sowftware offering them decades ago. In 2020 I can't have them enabled on MacBook Pro, because if someone were to use many of them, the CPU usage would spike (A LOT), even on background. Since this has been the case for at least three years now, I don't consider it a random bug, but rather an issue with the technologies used.
As mentioned in a reply bellow, syntax highlighting is a feature that was (and is) blazingly fast in every software except atom-based editors. Startup times are atrocious too.
Spotify.
And as mentioned in my comment, speed can be influenced by the size or memory requirements. And that becomes issue on its own when you want to use multiple of these applications. I constantly run into full ram and swapping with 16GB. Mostly caused by web applications, but the root cause is the same. Size on disk (or when updating) also matters on phones a lot.
It may not be slower, but it's definitely less efficient.
You can really see the loss of efficiency in modern software by using the same program/application on a modern machine vs a 10 or 15 year old machine. I have a couple of older laptops (2001 era Dell Latitude CPx with a PIII 500MHz, 2011 Lenovo Ideapad netbook with the Atom N450 1.6GHz) that I will occasionally play around with. I've found that most of what the article author said applies; textual interfaces with minimal or no mouse usage runs perfectly well on either of those old beasts, even with code written in 2020 and optimized for modern hardware. The "suckless" suite of tools in particular (dwm, st, surf, etc.) make those otherwise unusable machines into something approaching modern workstation utility. You don't want to even try to run any modern graphically rich software on those devices as you'll be frustrated immediately, and it will be clear just how bloated and unnecessary a lot of modern design has become.
I feel as long as we keep advancing in raw computing power, the software can be allowed to grow and make use of the extra power, but we will eventually reach a standoff where the hardware stops advancing and at that point we will need to focus on reducing, not increasing, software bloat if we wish to maintain efficiency.
Actually it does albeit indirectly, because you are not running a single application on a modern computer. When they all start starving for memory they get slower.
If 5MB of memory means swaping out to a floppy disk 30 years ago and 1GB usage doesn't today because your macbook has 32gb of ram the older program is still going to be slower. I think there's an important distinction between "modern programs could be faster" (which is unambiguously true) and "modern programs are slower than older programs or even analogue equivalents" which ends up often relying of invalid comparisons or rose colored glasses about what computing was like.
Often times what's being optimized for isn't even the speed of experience and maybe that's ok. Chrome spawns a million processes so if a tab crashes it doesn't end your browsing session, VS code being written in electron means writing plugins is a breeze and thus has built a thriving ecosystem in a record amount of time. If nothing else the world of software is a lot more flexible in 2020 than 1990 and maybe people prefer that to raw speed (given there's not a huge demand for native terminal based applications there's an argument to be made)
Has document writing or spreadsheet creation changed much since the 90s? Word and Excel 6 were significantly faster than current versions and were running on PCs with 8 or 16MB of RAM and, at least for my use cases, did effectively the same job they do today. In some cases they did it better.
How has document creation changed in two decades that justifies two orders of magnitude more RAM and CPU performance, 10x power draw, etc.?
If your house was built with 100x the resources and consumed that much more power, and it took longer to turn on the lights or cook a meal would it be justified because the building process was easier and you could add new light fixtures more easily? That would be lunacy, but for some reason we think it’s OK in software to avoid the craftsmanship the profession demands while treat users like fools who should just accept that computers are faster so their apps should be slower. It’s garbage reasoning. The ergonomics of developers should always come second to providing the best for customers.
It's hard to stay in business offering a product that touts "fewer features, but smaller memory footprint and snappier UI response" vs. its competitors. There are a few exceptions to this rule, but they are exceptional. That's why organizations pay for big, slow Slack instead of using fast, free, svelte IRC clients.
In other industries these are things that become commodities. They aren't thrown out and replaced with something new, the business move into a different phase (or shed that business to someone else willing to take the role).
The random numbers were just that, random numbers. Startup times are noticeably slower. Even with fast SSDs, many multi-GB apps that run in background can get swapped out, and that's still slower than RAM decades ago.
> Chrome spawns a million processes so if a tab crashes it doesn't end your browsing session
This one is funny, because
1) before Chrome pages didn't seem to crash (js could, but not the whole "page")
2) Chrome still crashes completely loads of times
(also it's not really related; Chrome is a fast application written relatively effectively)
But I get your point, and you are not wrong. I just wouldn't discount "cheap development" to be the primary reason.
As you "program" in React Native, are you really qualified to speak on who "at least half" of the issues are attributed to?
What do you mean when you say that the problem is half Apple's fault? Or, like every other comment your account hasd made in the last 24-48 hours, is it just an attempt to start an Apple flamewar?
Because each successive generation of programmers grows less efficient with the resources available.
A new programmer in 2020 probably treats RAM and CPU as near infinite resources. Hence you have super simple 2D games that are 900MB in size popping up in /r/Unity2D and webpages weighing in at 15 MB and, etc. They just don't know those are unreasonable sizes because they've never tried to make a 100KB game/website.
There must have been a large increase in game size between 1990 and 1995. I remember games like Lemmings 2 the tribes and sim city 3000 requiring multiple floppy disks.
I call bullshit. The sort of attitude expressed in this thread is important, because it pushes us forward. The author identifies real UX shortcomings with current software. Nevertheless, the assertion that "almost everything on computers is perceptually slower than it was in 1983" is patently false, and the comparison between online maps and paper maps seems almost intentionally obtuse. Yes, online maps could have even more capability and better UX than they do today. No, it is not more difficult to conduct mapping activity today than it was in the 90s. (For instance, the example given about finding interesting places to stop along a route: the 90s equivalent of that would have been a book, separate from the map, not searchable, and full of things completely irrelevant to your interests. So yes, maybe putting a mark on a piece of paper is easier than doing it in online maps, but every other aspect of that process is way harder without the internet.)
>So yes, maybe putting a mark on a piece of paper is easier than doing it in online maps, but every other aspect of that process is way harder without the internet.
Only if you know where on the map the place is which you wouldn't since you found it in a book. In Google Maps, I click "Add Destination" and put in the address. Drag it to the right places and it's now part of my route. On a paper map, I need to spend 10 minutes finding the address, referring to the index on the back to find the right square.
Yes, and every time I go to the grocery store my ability to hunt mammoths is reduced. Anesthesia reduces my ability to just deal with the pain of surgery. A pen reduces my ability to chisel words into stone.
Exposing us less to the challenges of the past is not a bug, it's a feature.
Try servicing your neighbor’s P4 running XP machine, then review your position. (I recently had the pleasure of doing this) It’s not all the way back to 1983, but the snappiness compared to Win 10 or macOS on recent hardware is startling.
Adobe Photoshop 7 took literally seconds to open on my 500mhz Pentium 3. On my brand new SSD iMac, 31 seconds cold, 7 seconds from a warm start (which honestly is WAY better than I thought it was going to be).
Not if you go back far enough. Ultima 8 Pagan, whenever I switched "maps" on my 386 it literally took about a minute to load the next area. When I got my next computer it was a Pentium 100 Mhz. That thing loaded the next map area in about 1-2 seconds. Both of those computers did not use SSDs.
Linux booted faster on my Pentium 100 with a hard disk than with my i7 + SSD. The root cause is that when Linux moved to parallel “fast” boot and DBUS they didn’t add APIs to the kernel to work through all the race conditions around modules loading, etc. So, it has to sleep for a second here or there to let hardware stabilize. I first noticed this about 10 years ago (on a new, faster machine, X would fail to start because the video card kernel module hadn’t finished loading yet).
It has gotten worse since. On one machine, I have an NFS mount over WiFi. Network manager wants mount to complete before it runs because they didn’t think before they implemented it. I eventually got that machine to boot, but it takes an extra 5 seconds.
It takes longer for my bluetooth keyboard to wake up and pair then it took for Word to start back in the day.
Also, when I start typing with the keyboard, I have no idea which web page text box has default focus. At least with Word (which I really, really hated), the document body always had keyboard focus.
Also, if I go back to edit a word in the middle of a previous sentence, the operating system sometimes decides I want the first character to be uppercase (and sometimes it doesn’t).
Just now, it took 5 tries to get the damn thing to type a freaking lowercase letter. I have autocorrect disabled, or it would be even worse.
Heck, you can’t even reliably guess which direction a mouse wheel will scroll any more.
Try sitting at my 2014 quad core Core i5 with 16GB RAM, SATA SSD, and GTX950 running four 4K displays running Windows 10 and multiple instances of CAD / CAM software, Excel, Outlook, Word, task management software blah blah blah all accesible via AutoHotKey scripts and 22 button mouse.
I read your comment several times while trying to understand why you seemingly oppose higher level comment and then confirm it at the same time. Only later I understood that you state that P4 with XP was more responsive than modern HW with Win10? Come on, that's not true at all. Every action would be slower and some much slower. Opening any heavy app (like say browser) will take much more time even on older software versions.
The fact that online maps didn't even exist back then is not relevant. The point the author is making is that he feels that if it did exist then it would've had better UX (again, whether or not that is true is a different question).
Again, not 1983, but I was using a DOS (iirc we didn't buy the Windows version because it was too slow) mapping tool to create routes for trucks around 1990/91.
It was slow, awkward, and needed a few days' training to get up to speed with. Redrawing a map on the screen took a couple of seconds. Scrolling around to find stuff wasn't really possible. But give it a postcode and it knew where everything was. And give it a list of 10 postcodes and it would spit out the best route a few minutes later.
Google's UX for everything except search is utter shite. I don't know what they think they're doing. Anyone here from Google who can explain why their UX is so crap?
If you look closely you'll see that Google Maps are not a shitty general purpose application specialized on search. It's a single purpose map application that people insist on using for things that aren't search. It's laser focused on generating revenue.
The real question is why do people insist on using it? If people didn't, they would have to broaden their goals.
Google is good at search and ads. Best in the world, historic achievement etc.
You can think of everything else they do as a hobby for a rich person. They don't really need the money and they don't really care about it. Sometimes it turns out well, and sometimes not. It doesn't matter either way.
I think part of the issue is software becoming mainstream. What percentage of users need to put in ten different postcodes to plot a route that hits all of them? Barely any. So it doesn't make sense to optimise the UI for that use case. Instead it's optimised for traveling A-B, and to my eyes does a great job of it.
I need to buy groceries, get a few t-shirts, ship a package, and put gas in my car. Minimize travel time.
Alternatively (and even easier):
I need to go to Safeway, Target, the UPS store, and Chevron. Pick a route and and order.
This would be trivial to enter into the computer using the interface in the article, and trivial for a modern computer to compute and display in under a second.
You put in your first destination. Hit directions. Then hit “add stop” until yo-you have your whole route.
Why would you need to do that, though? It only makes sense if you’re going to print out directions, which no one does any more. You put your destination in the maps app in your phone and go. Then enter the next destination once you’re there. And so on. There’s very little utility in planning such a trip upfront in a world of ubiquitous GPS and internet.
> the assertion that "almost everything on computers is perceptually slower than it was in 1983" is patently false
Excessively dismissive. It's not so patently false when you recall that applications on personal computers were designed to do much less in 1983 than they are now.
The model gestured at in the assertion is (arguably) one in which perceptual speed is a function of an application's (1) proximity to the outer bounds of a machine's capabilities, and (2) the efficiency of its implementation.
I'm not sure you can call bullshit on someone's "perception". It's an opinion - if he sees it as slower, then he sees it as slower. Nothing you can do will convince his brain to see it faster.
Yeah, NOT only can you check out an ebook of Grapes or Wrath FROM HOME, you can find out the exact number on the shelf in multiple libraries if you want the actual book.
Former 1990s pizza delivery driver here. I used paper maps extensively. He's right.
He's right that speed matters. It matters when you are driving in traffic and you need to know where to take that left turn. I don't use Google Maps or any map app when I'm driving because it's too damn dangerous. Much better to take a screenshot of the map beforehand because jpgs don't take 45 seconds to load. Sure, you can pull over and wait a minute for the map to load (and sometimes I do this), but with a paper map you can just fold it so that the area you are driving in appears and with a glance you can see where that turn is. Load speed ~0.5 seconds.
The issue, as far as I am concerned, is not with the UI of the apps, but with the OS. It strikes me as completely primitive that modern OS's (and I include browsers, because they are basically a one-abstraction-layer-higher OS) don't have a proper way of prioritizing the user's needs, instead leaving it to the applications. It's an abdication of responsibility IMHO.
I'm sure there are challenges and reasons why it is that way. Maybe there are experimental OS's which do this properly or ways to tweak existing ones. I don't know enough about this. I'd be happy to learn more from those of you who do...
Funny: In JS I tried to find the maximum number of http requests a system could make. Async operations have unpredictable response time. Parsing the payload when it is returned was not an option since you end up with more parse jobs than the system can deal with at that moment which freezes the UI. (Earlier requests may arrive late, later requests might arrive soon.) So I ended up de-async-ing the tasks an doing them with setInterval (which requires checking the time or it will cluster up the parse tasks again) and tuning down the number of requests if there are many unfinished parse jobs. Now, if the user clicks something everything waits except dumping the responses into an array. Previously I couldn't lower the number of requests far enough to completely avoid UI freezes. They only got less frequent. With everything synced properly I can push the rate of the requests 20 times higher without freezes than async with 1 freeze per minute.
> one of the things that makes me steaming mad is how the entire field of web apps ignores 100% of learned lessons from desktop apps
Unfortunately it's worse than ignoring. It's intentionally abandoning, after years of A/B tests optimizing for revenue have found a perceptual sweet spot. Sadly for people who care about fast UI that point is way up on the sluggishness scale...
My Osborne 1 took a minute to load Wordstar. Searching a document would take more minutes if it was longer than about 30k because it had to swap to floppy disk. Connecting to a BBS was time for a bathroom break. So were compiles.
I think most of what is perceptually slower for the author is that it's a small percentage of the 40 years it took to get here. I loved my O1 but it did what little it could do very slowly. My phone in my hands right now is doing a trillion more things better and faster.
Indeed. Even his first example of library computers seems off. In 1998, my library was part of a small network of libraries in my city, searching the catalogue involved making network requests over ISDN, and, while impressive for the time, it was not fast.
I can definitely get behind the Gmaps UX rant, but that's nothing to do with speed.
In 1997 I was doing IT classes in secondary school. One of our preferred ways to bunk of class was to ask if we could "write up our reports in the library" on the RMNimbus 186s. 15 or so minutes for the computer to boot into some kind of menu system that gave you a "press 1 to start windows 3.1, press 2 to start BBC Basic" type menu, then another 20 minutes to boot windows and then another 5 minutes to start MSWord. Write three lines and then it's time for the next class!
Huh, in 1997 our (average) school had some decent Pentium machines. We'd boot into Window 3.1 + a Novell Netware prompt and be able to launch Encarta or Word (or Wordperfect in DOS) within a minute or two.
To be fair - we asked to go to the library because that's where the crappy old machines lived.
Excuse me while I go down memory lane...
I think when I started (1995) it was a computer room with some 486s and the library with 186s. Then we got the internet, a single ISDN line shared by all of them, which was about as fast as you'd expect.
At some point these got upgraded to pentiums with windows 98 or similar - in those happy days the IT people at the school had absolutely no idea what they were doing so we had a happy few months of installing and playing doom and quake over the network.
I once found the IT technician going around all the computers and holding down the delete key to clear out the username field grumbling about "bloody kids filling these up", he was very impressed when I showed him how to select all...
At some point the "business" teacher said whoever can get at least 120 wpm in the typing game gets 100% in his class component. That must have seemed to him like an impossible achievement to motivate us.
A week or so later, a dozen of us had 100% in his part of the course and got to sit around and play games for the rest of the 6 weeks.
PERCEPTUALLY slower. meaning, you click on something and you know instantly that at least it's processing, i.e. without perceptually detectable delay. Almost 100% of SPAs (including gmail and "electron" type apps) suck terribly at this, and they pay it with double- and triple- clicks from frustrated/clueless users
Nobody does it worse than imgur.com . You upload something and there is no indication, no feedback, nothing
seriously? it's easy to tell that something is slow to respond, because you can compare the time it takes from the audible mouse click to the change you see on screen, and primates are very very good at perceptual discrimination
That's true but might also veer into the land of "technically correct". Dedicated hardware and font lookups for screen display means that screen updates happened on the next retrace. That doesn't mean the time between hitting Enter and the spreadsheet updating or the word processor re-wrapping the text was faster in 1983 than it is today.
The first paid programming job I ever did was writing some relocatable machine code in a USR$ because the patron's BBS couldn't calculate the XMODEM CRC in BASIC fast enough to support the upgrade to his new 1200 baud modem. I know I got paid $20 and I think it was about 20 bytes of code. I wish I got paid $1/byte for code I write today!
I mean, nowadays I am not very much into the "actually" arguments: I really don't deem it that important that older computers were better specialized for lower input lag. I just want that lower input lag back.
Complexity in modern machines and OS-es has grown too much. I feel a next Linux-like revolution might be coming that addresses this -- although this time around it would be much slower and gradual so it might not actually constitute a revolution per se. More like evolution.
I think that just means that users expected nothing to happen very quickly. You push a button, and would instantly get a beach ball, so you could get up and go elsewhere while you waited to see if this time it would actually work.
I'm all for fixing the million annoyances in modern UX. The Web was built by something even worse than a committee -- it was built by a thousand committees. But let's not have rose-colored glasses, either. Computers in 1983 and 1998 were immensely frustrating, and some of what makes computers slow today is also what makes them better than the half-baked, hard-to-use, fifty-pound monstrosities of the past. We can and should do better in the future, but not if we mis-remember the past.
Computers were slower but i wouldn't call them frustrating. Windows start menu in 2000 was an 100% intuitive hierarchical menu. Today it takes me 10 minutes to remove the utterly useless spammy crap that MS ships by default.
It used to be that software would get slower due to more and more baggage (or "technologies") it accumulates, but hardware would get faster at a higher rate. The past 10 years software keeps piling up more and more libraries but CPU performance is essentially stuck and even more, we have the shift to mobile, which means underpowered computers. This inevitably leads to bloated , slow systems , or "UX".
Clearly this person never tried to load a program on a C64 with a tape drive. I could make myself lunch and the thing still wouldn't be done, and there was a non-zero chance it would screw up somehow and you'd have to rewind the tape and start it over. Upgrading to floppy wasn't much better, either, before the advent of fast load cartridges.
Contrast that with my current Win 10 install, which on a 3-year old computer goes from "off" to login screen in under 10 seconds.
Depends on what the goal is of course. A c64 started and dropped you into the interpreter in under a second.
Input latency being another absolutely astonishing difference.
But modern computers have so much more computational throughput that they’re many orders of magnitude more useful as tools.
I think the author is just saying that we lost the feel of immediacy for the common case, which I agree with, sometimes I press something and there’s either a sub second delay (text input) or a large pause (clicking an icon) before the machine seems to be doing anything.
Back in the day, you press a key and your computer is displaying it before the key has risen; you press enter and your hard disk churns immediately and a flashing light would blink merrily indicating work. That’s what perception is.
(Also, you could use a c64 with a floppy or Hard-disk which was obviously much faster than tape)
I haven't read the article and only started using computers as a kid in the early 90s.
My take on perceptually slower is:
I don't remember computers being slow back then. They were just like they were.
Whereas today, especially since I'm living in Latin America on flaky and slow mobile internet connection and low to mid-range phones, the range of speed of just taking into account websites is massive. From super snappy to barely usable. Which makes me much more conscious about it.
Maybe it is just selective memory, and the difference in my age, but I feel back then, how something will perform was more predictable and consistant from a user perspective.
In 1983/86 not much was delivered over BBS, it was almost all floppy based. The 1.44 was around 50kbyte/sec, so it took a while before people generally had broadband that would match that.
However, a BBS didn't do a bad job with interfaces. I remember pcboard or iniquity which had reasonably good interfaces, you could often type what you wanted rather than navigate the menu system.
What about phone calls from browsers, last time I looked at Teams it consumed around 250MB for the one process tab funnelling voice traffic.
Also, most TUI interfaces don't suffer the way that the post describes, aside from vi itself, I don't remember much in the years gone by that is as fast as vim to work with, though, it has accumulated some timber since.
Random fact: I've been playing with RISCOS on my Pi 3B+ and oh my gosh how snappy is it? Even relative to pure desktop, non-web apps. It's the last of the true 80s OSes and honestly, I feel it represents a missed opportunity. Computers used to have simplicity enough to start in seconds.
Nope, not on my vic20, c64, c128 and Amiga. Scrolling was slow as hell. BBSes slow. Rerendering a full page of text, slow. GEOS slow. Disk operations hellaslow.
This is an example of nostalgia goggles in action. You know how that movie you swore was amazing in your childhood sucks when you rewatch it as an adult and realize it had atrocious acting and writing?
Disk operations? You mean loading from datasette. Using Turbo Tape accelerated loading times by a factor 10, but still waiting a minute for a game to load was common.
It’s simply not possible to make a blanket statement like this. Computers today are so very different and have so many more layers than those from 1983.
I recently refurbished an old Mac Plus. Of course I couldn’t leave it stock, booting from floppies was simply too ridiculous.. So it boots from Zip. Anyways, once I had this machine up and running I was quite surprised at how snappy the interface is - once everything was in place - and that’s the difference. The old interface is paper thin and has nothing going on, no asynchronous, little to no threads, it is just what it is.
A search field in a local application opening instantly is not the same as a search field searching orders of magnitude more data on a machine thousands of miles away.
Things were "faster" because so much _blocked_. Modal windows suspended applications. Now in the ~100ms it takes to open a window your computer is still doing other things in that application, in other applications, in the kernel, on other cores. We may have traded latency for _throughput_ in some cases, but that's not necessarily a bad thing, and often perceptually much faster still.
Lastly much of the speed back then came from things that are not practical for security reasons now. Shared memory makes a lot of stuff possible, and quickly. Temple OS (for all the faults of the author) demonstrates that today there are still really neat (and fast) things that can be done when you don't have to worry about security at all, but unfortunately we don't live in that world anymore, and a cost of our connected world is that security must be a design principle from the outset, and there are performance costs to that at every level of the stack, whether it's memory protection, ASLR, stack canaries, SSL/encryption, process sandboxing, containerisation, etc.
202 comments
[ 3.0 ms ] story [ 229 ms ] threadMy terminal lags more today than it did 10 years ago.
Because the data became the hotly-guarded commodity of the "software" companies.
Well, interfaces are perceptually very different than they were in 1983 too...
I didn't bother reading the rant because I think it doesn't make sense but is just personal "feeling" of the author. Objectively speaking computers are insanely faster and can do much more things. For exmple I use Sublime Text editor with multiple plugins and features, and all those feel instant. Also with web apps that I use 95% of time the experience is very instant-like.
Something that used to result in 2MB application with 5MB in memory requirement is now done as half a gigabyte of resources that will spawn dozens of processes totaling at least 1GB of memory. Sure, computers are faster, but not by that much apparently.
Looking at all those electron (et al) apps. Cheap to write beats user experience I guess.
What exactly was faster to do 20 years ago than now?
Adding features will almost inevitably make software slower. Sometimes the difference is smaller, sometimes larger.
"extra few features" would fit more to likes of vim.
I used e.g. gedit (linux) and pspad (windows) during that time and both completely froze on larger files.
But generally I do not think the premise is correct. Loading a game from a datasette took easily 15 minutes (later there was acceleration only a few minutes)
Loading a game from a cardigde (what was usual at the time) was much faster than anything we use now, but this is not a fair comparison.
It's a fact that nowadays a lot of apps are very slow, on computers and phones alike -- and socially and culturally that's unacceptable for non-technical people.
It's not fair comparison since the games are completely different beasts today - huge open worlds, detailed textures, complex AIs.
Game studios could design games which are super fast to load and play but some other aspect would suffer instead. It's a trade off and it looks like users are OK with waiting a little bit if it means better gameplay.
My mom simply wanted instantly loading calendar and grocery list apps. I know that's achievable because I've done (parts of) such apps in the past and they were faster than others.
It's not such a stretch to imagine people being frustrated with lags everywhere (and those lags do objectively exist). And I've met a good amount of people frustrated with the current breed of software as well.
Modern apps don't bring almost anything new or improved to the table. They should be lightning fast but they are not.
Cartiges don't have a loading time, and are a technology that is available today, but that people abandoned because they are expensive and difficult to update.
:(
It's just the load time of cartiges that aren't a fair goal.
For example back then they did not index files at startup since there was no function for that (like "find references"). These days IDEs provide a lot of "intelligence" and static analysis for which you need memory, a lot of reads and processing.
So yeah, I guess VS got slower but it's because it's now doing much more (useful) things.
As mentioned in a reply bellow, syntax highlighting is a feature that was (and is) blazingly fast in every software except atom-based editors. Startup times are atrocious too.
Spotify.
And as mentioned in my comment, speed can be influenced by the size or memory requirements. And that becomes issue on its own when you want to use multiple of these applications. I constantly run into full ram and swapping with 16GB. Mostly caused by web applications, but the root cause is the same. Size on disk (or when updating) also matters on phones a lot.
You can really see the loss of efficiency in modern software by using the same program/application on a modern machine vs a 10 or 15 year old machine. I have a couple of older laptops (2001 era Dell Latitude CPx with a PIII 500MHz, 2011 Lenovo Ideapad netbook with the Atom N450 1.6GHz) that I will occasionally play around with. I've found that most of what the article author said applies; textual interfaces with minimal or no mouse usage runs perfectly well on either of those old beasts, even with code written in 2020 and optimized for modern hardware. The "suckless" suite of tools in particular (dwm, st, surf, etc.) make those otherwise unusable machines into something approaching modern workstation utility. You don't want to even try to run any modern graphically rich software on those devices as you'll be frustrated immediately, and it will be clear just how bloated and unnecessary a lot of modern design has become.
I feel as long as we keep advancing in raw computing power, the software can be allowed to grow and make use of the extra power, but we will eventually reach a standoff where the hardware stops advancing and at that point we will need to focus on reducing, not increasing, software bloat if we wish to maintain efficiency.
Often times what's being optimized for isn't even the speed of experience and maybe that's ok. Chrome spawns a million processes so if a tab crashes it doesn't end your browsing session, VS code being written in electron means writing plugins is a breeze and thus has built a thriving ecosystem in a record amount of time. If nothing else the world of software is a lot more flexible in 2020 than 1990 and maybe people prefer that to raw speed (given there's not a huge demand for native terminal based applications there's an argument to be made)
How has document creation changed in two decades that justifies two orders of magnitude more RAM and CPU performance, 10x power draw, etc.?
If your house was built with 100x the resources and consumed that much more power, and it took longer to turn on the lights or cook a meal would it be justified because the building process was easier and you could add new light fixtures more easily? That would be lunacy, but for some reason we think it’s OK in software to avoid the craftsmanship the profession demands while treat users like fools who should just accept that computers are faster so their apps should be slower. It’s garbage reasoning. The ergonomics of developers should always come second to providing the best for customers.
I can run xlookup functions on a 1000 row excel spreadsheet on my cell phone.
> Chrome spawns a million processes so if a tab crashes it doesn't end your browsing session
This one is funny, because
1) before Chrome pages didn't seem to crash (js could, but not the whole "page")
2) Chrome still crashes completely loads of times
(also it's not really related; Chrome is a fast application written relatively effectively)
But I get your point, and you are not wrong. I just wouldn't discount "cheap development" to be the primary reason.
Having to make Apps that will get published and not banned, all while trying to keep costs low forces developers into JavaScript solutions.
If it was low cost to develop a native iPhone app, this would not be an issue.
What do you mean when you say that the problem is half Apple's fault? Or, like every other comment your account hasd made in the last 24-48 hours, is it just an attempt to start an Apple flamewar?
I think it'd be more accurate to say value to the user beats the cost to write the software, which then beats user experience.
Something can offer a lot of value and use but still be a pain to use.
Running slack, rstudio, atom and a browser was almost maxing out an 8gb machine.
Why does an IM client need over a gig of ram?
A new programmer in 2020 probably treats RAM and CPU as near infinite resources. Hence you have super simple 2D games that are 900MB in size popping up in /r/Unity2D and webpages weighing in at 15 MB and, etc. They just don't know those are unreasonable sizes because they've never tried to make a 100KB game/website.
30 years ago 100 KB for simple 2D game would be considered unreasonable.
Make it 40 years :D
Only if you know where on the map the place is which you wouldn't since you found it in a book. In Google Maps, I click "Add Destination" and put in the address. Drag it to the right places and it's now part of my route. On a paper map, I need to spend 10 minutes finding the address, referring to the index on the back to find the right square.
Think of it this way: everything our phones/computers do for us reduces our ability to do the same task in the long and short term.
Exposing us less to the challenges of the past is not a bug, it's a feature.
If anything 90's software would run circles around today's software if it was using today's hardware. And I think that's the point of the article.
It has gotten worse since. On one machine, I have an NFS mount over WiFi. Network manager wants mount to complete before it runs because they didn’t think before they implemented it. I eventually got that machine to boot, but it takes an extra 5 seconds.
Also, when I start typing with the keyboard, I have no idea which web page text box has default focus. At least with Word (which I really, really hated), the document body always had keyboard focus.
Also, if I go back to edit a word in the middle of a previous sentence, the operating system sometimes decides I want the first character to be uppercase (and sometimes it doesn’t).
Just now, it took 5 tries to get the damn thing to type a freaking lowercase letter. I have autocorrect disabled, or it would be even worse.
Heck, you can’t even reliably guess which direction a mouse wheel will scroll any more.
This thing is blisteringly fast.
I do not miss Windows XP.
It was slow, awkward, and needed a few days' training to get up to speed with. Redrawing a map on the screen took a couple of seconds. Scrolling around to find stuff wasn't really possible. But give it a postcode and it knew where everything was. And give it a list of 10 postcodes and it would spit out the best route a few minutes later.
Google's UX for everything except search is utter shite. I don't know what they think they're doing. Anyone here from Google who can explain why their UX is so crap?
They are doing search. Specifialy, the monetizable variety of it.
The real question is why do people insist on using it? If people didn't, they would have to broaden their goals.
You can think of everything else they do as a hobby for a rich person. They don't really need the money and they don't really care about it. Sometimes it turns out well, and sometimes not. It doesn't matter either way.
I need to buy groceries, get a few t-shirts, ship a package, and put gas in my car. Minimize travel time.
Alternatively (and even easier):
I need to go to Safeway, Target, the UPS store, and Chevron. Pick a route and and order.
This would be trivial to enter into the computer using the interface in the article, and trivial for a modern computer to compute and display in under a second.
Why would you need to do that, though? It only makes sense if you’re going to print out directions, which no one does any more. You put your destination in the maps app in your phone and go. Then enter the next destination once you’re there. And so on. There’s very little utility in planning such a trip upfront in a world of ubiquitous GPS and internet.
This strikes at a slightly different problem, the latency of actually showing things on screen, but points out that not all is going well.
https://danluu.com/input-lag/
Excessively dismissive. It's not so patently false when you recall that applications on personal computers were designed to do much less in 1983 than they are now.
The model gestured at in the assertion is (arguably) one in which perceptual speed is a function of an application's (1) proximity to the outer bounds of a machine's capabilities, and (2) the efficiency of its implementation.
This is elucidating, and a useful contribution.
Also, if you some real fucking power, try this:
https://ls2pac.lapl.org/?section=search&term=grapes%20of%20w...
Yeah, NOT only can you check out an ebook of Grapes or Wrath FROM HOME, you can find out the exact number on the shelf in multiple libraries if you want the actual book.
I bet they didn't have THAT in 1998.
He's right that speed matters. It matters when you are driving in traffic and you need to know where to take that left turn. I don't use Google Maps or any map app when I'm driving because it's too damn dangerous. Much better to take a screenshot of the map beforehand because jpgs don't take 45 seconds to load. Sure, you can pull over and wait a minute for the map to load (and sometimes I do this), but with a paper map you can just fold it so that the area you are driving in appears and with a glance you can see where that turn is. Load speed ~0.5 seconds.
The issue, as far as I am concerned, is not with the UI of the apps, but with the OS. It strikes me as completely primitive that modern OS's (and I include browsers, because they are basically a one-abstraction-layer-higher OS) don't have a proper way of prioritizing the user's needs, instead leaving it to the applications. It's an abdication of responsibility IMHO.
I'm sure there are challenges and reasons why it is that way. Maybe there are experimental OS's which do this properly or ways to tweak existing ones. I don't know enough about this. I'd be happy to learn more from those of you who do...
To me that means it is no longer my/your computer.
> Maybe there are experimental OS's which do this properly
https://en.wikipedia.org/wiki/RTLinux
Funny: In JS I tried to find the maximum number of http requests a system could make. Async operations have unpredictable response time. Parsing the payload when it is returned was not an option since you end up with more parse jobs than the system can deal with at that moment which freezes the UI. (Earlier requests may arrive late, later requests might arrive soon.) So I ended up de-async-ing the tasks an doing them with setInterval (which requires checking the time or it will cluster up the parse tasks again) and tuning down the number of requests if there are many unfinished parse jobs. Now, if the user clicks something everything waits except dumping the responses into an array. Previously I couldn't lower the number of requests far enough to completely avoid UI freezes. They only got less frequent. With everything synced properly I can push the rate of the requests 20 times higher without freezes than async with 1 freeze per minute.
Unfortunately it's worse than ignoring. It's intentionally abandoning, after years of A/B tests optimizing for revenue have found a perceptual sweet spot. Sadly for people who care about fast UI that point is way up on the sluggishness scale...
(Ok fair enough, apparently it was 1986, so 3 years later..)
https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)
My Osborne 1 took a minute to load Wordstar. Searching a document would take more minutes if it was longer than about 30k because it had to swap to floppy disk. Connecting to a BBS was time for a bathroom break. So were compiles.
I think most of what is perceptually slower for the author is that it's a small percentage of the 40 years it took to get here. I loved my O1 but it did what little it could do very slowly. My phone in my hands right now is doing a trillion more things better and faster.
I can definitely get behind the Gmaps UX rant, but that's nothing to do with speed.
The digitized index was a couple of touchscreen terminals, which were plenty fast.
Excuse me while I go down memory lane...
I think when I started (1995) it was a computer room with some 486s and the library with 186s. Then we got the internet, a single ISDN line shared by all of them, which was about as fast as you'd expect.
At some point these got upgraded to pentiums with windows 98 or similar - in those happy days the IT people at the school had absolutely no idea what they were doing so we had a happy few months of installing and playing doom and quake over the network.
I once found the IT technician going around all the computers and holding down the delete key to clear out the username field grumbling about "bloody kids filling these up", he was very impressed when I showed him how to select all...
At some point the "business" teacher said whoever can get at least 120 wpm in the typing game gets 100% in his class component. That must have seemed to him like an impossible achievement to motivate us.
A week or so later, a dozen of us had 100% in his part of the course and got to sit around and play games for the rest of the 6 weeks.
Nobody does it worse than imgur.com . You upload something and there is no indication, no feedback, nothing
[0] https://danluu.com/input-lag/
The first paid programming job I ever did was writing some relocatable machine code in a USR$ because the patron's BBS couldn't calculate the XMODEM CRC in BASIC fast enough to support the upgrade to his new 1200 baud modem. I know I got paid $20 and I think it was about 20 bytes of code. I wish I got paid $1/byte for code I write today!
[0] - http://www.page6.org/archive/issue_11/page_24.htm
I mean, nowadays I am not very much into the "actually" arguments: I really don't deem it that important that older computers were better specialized for lower input lag. I just want that lower input lag back.
Complexity in modern machines and OS-es has grown too much. I feel a next Linux-like revolution might be coming that addresses this -- although this time around it would be much slower and gradual so it might not actually constitute a revolution per se. More like evolution.
I'm all for fixing the million annoyances in modern UX. The Web was built by something even worse than a committee -- it was built by a thousand committees. But let's not have rose-colored glasses, either. Computers in 1983 and 1998 were immensely frustrating, and some of what makes computers slow today is also what makes them better than the half-baked, hard-to-use, fifty-pound monstrosities of the past. We can and should do better in the future, but not if we mis-remember the past.
It used to be that software would get slower due to more and more baggage (or "technologies") it accumulates, but hardware would get faster at a higher rate. The past 10 years software keeps piling up more and more libraries but CPU performance is essentially stuck and even more, we have the shift to mobile, which means underpowered computers. This inevitably leads to bloated , slow systems , or "UX".
Contrast that with my current Win 10 install, which on a 3-year old computer goes from "off" to login screen in under 10 seconds.
Input latency being another absolutely astonishing difference.
But modern computers have so much more computational throughput that they’re many orders of magnitude more useful as tools.
I think the author is just saying that we lost the feel of immediacy for the common case, which I agree with, sometimes I press something and there’s either a sub second delay (text input) or a large pause (clicking an icon) before the machine seems to be doing anything.
Back in the day, you press a key and your computer is displaying it before the key has risen; you press enter and your hard disk churns immediately and a flashing light would blink merrily indicating work. That’s what perception is.
(Also, you could use a c64 with a floppy or Hard-disk which was obviously much faster than tape)
My take on perceptually slower is:
I don't remember computers being slow back then. They were just like they were.
Whereas today, especially since I'm living in Latin America on flaky and slow mobile internet connection and low to mid-range phones, the range of speed of just taking into account websites is massive. From super snappy to barely usable. Which makes me much more conscious about it.
Maybe it is just selective memory, and the difference in my age, but I feel back then, how something will perform was more predictable and consistant from a user perspective.
However, a BBS didn't do a bad job with interfaces. I remember pcboard or iniquity which had reasonably good interfaces, you could often type what you wanted rather than navigate the menu system.
What about phone calls from browsers, last time I looked at Teams it consumed around 250MB for the one process tab funnelling voice traffic.
Also, most TUI interfaces don't suffer the way that the post describes, aside from vi itself, I don't remember much in the years gone by that is as fast as vim to work with, though, it has accumulated some timber since.
Previous discussions:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
This is an example of nostalgia goggles in action. You know how that movie you swore was amazing in your childhood sucks when you rewatch it as an adult and realize it had atrocious acting and writing?
It’s simply not possible to make a blanket statement like this. Computers today are so very different and have so many more layers than those from 1983.
I recently refurbished an old Mac Plus. Of course I couldn’t leave it stock, booting from floppies was simply too ridiculous.. So it boots from Zip. Anyways, once I had this machine up and running I was quite surprised at how snappy the interface is - once everything was in place - and that’s the difference. The old interface is paper thin and has nothing going on, no asynchronous, little to no threads, it is just what it is.
A search field in a local application opening instantly is not the same as a search field searching orders of magnitude more data on a machine thousands of miles away.
Things were "faster" because so much _blocked_. Modal windows suspended applications. Now in the ~100ms it takes to open a window your computer is still doing other things in that application, in other applications, in the kernel, on other cores. We may have traded latency for _throughput_ in some cases, but that's not necessarily a bad thing, and often perceptually much faster still.
Lastly much of the speed back then came from things that are not practical for security reasons now. Shared memory makes a lot of stuff possible, and quickly. Temple OS (for all the faults of the author) demonstrates that today there are still really neat (and fast) things that can be done when you don't have to worry about security at all, but unfortunately we don't live in that world anymore, and a cost of our connected world is that security must be a design principle from the outset, and there are performance costs to that at every level of the stack, whether it's memory protection, ASLR, stack canaries, SSL/encryption, process sandboxing, containerisation, etc.