Hacker News Reader

Comment by The_Colonel | Hacker News Reader

I miss some concrete examples.

What exactly was faster to do 20 years ago than now?

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.

So apples to oranges.

Adding features will almost inevitably make software slower. Sometimes the difference is smaller, sometimes larger.

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.

IDEs don't have "extra few features", they have massive amount of functionality added.

"extra few features" would fit more to likes of vim.

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.

Which editor did you use? I mean I definitely remember scrolling issues 15 years ago on a large file with syntax highlighting.

I used e.g. gedit (linux) and pspad (windows) during that time and both completely froze on larger files.

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.

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)

Loading a game from a floopy was much faster than loading a modern game as soon as floppies became popular enough to carry games.

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.

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.

> Why isn't it a fair comparison?

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.

Visual studio startup and debugging. Source: https://youtu.be/GC-0tCy4P1U

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.

Golden video. Thanks for this.

Reply on news.ycombinator.com