Hacker News Reader

It's most obvious with video, but that's not the only change. Thirty years ago you couldn't:

    * Run games that approach photorealism at 4K resolution
    * Emulate a recording studio with virtual instruments/FX in your laptop
    * Watch video streamed at 4K
    * Stream video from home and add live video FX
    * Record and edit video at 4K using a pocket device
    * Download files from a global communication network at hundreds of Mb/s
    * Search that network and get results almost instantly
    * Take usable speech recognition and automatic translation more or less for granted

The OP is poorly argued. Presumably they're trying to ask why software isn't 1000X better.

In some ways it is. Phone apps particularly are much more usable and intuitive than desktop apps from 1992.

In other ways, especially on the web, there's a lot of cruft floating on top of a sea of bloat. But there's a conscious tradeoff between abstraction/development time and runtime performance. The web would not suddenly become more usable if everything was written in machine code.

Elsewhere there's a lot of drag because of backward compatibility. Office is still a thing because nothing better has replaced it. It's ugly and stupid but it fills a niche that needs to be filled and - for all their efforts - FOSS isn't a realistic alternative for mainstream, professional use. This also applies to a lot of other industry-standard apps like Photoshop.

The limiting factor isn't CPU, it's the user. Most of these apps spend vast aeons of time in an idle loop waiting for the human to do something.

You'd need to invent new kinds of assistive apps to get around this, and we're beginning to see those with AI. But they'll be disruptors, not replacements, and it's not obvious how that's going to work out.

In addition, the engineering skill required for writing basic desktop software is much lower than it used to be, while the skill required to write code for a game engine, audio/video processing, low-level network stacks, or any of the other problems on your list is just as high as it used to be, if not higher.

Back in the day, anyone writing even a simple desktop app needed to know about algorithmic complexity and low-level optimizations, or their code would be intolerably slow (if it even ran at all). Today, if all you’re developing is a simple productivity app, high-level abstractions have eliminated the need for such low-level knowledge, dramatically lowering the barrier of entry for developers, at the expense of software efficiency. In other words, if the problem you’re solving is inherently easy, it is easy to write (inefficient but fast enough) code to solve it. This used to not be the case: even easy problems required difficult code to solve.

However, all of the problems on your list are inherently difficult and complex, and thus still require difficult and complex code to solve. The barrier of entry for developers remains high, ensuring that those who work on said problems still have thorough knowledge of how to write performant code.

> That’s not how typical users work, and I don’t think it’s how they want to work.

This hits the nail on the head: most users are not programmers. While the unix philosophy works well for programmers it is not suitable for non-programming users. A small collection of single-use tools that can be orchestrated is a programming interface.

One might argue that the unix philosophy doesn’t work well for programmers either. Do I really have to parse one command’s output to do anything meaningful with it?

These small commands, piped together make it possible to build, boot and run systems that are in everyone’s pocket and run software that does work the way users want.

> “The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster..

If I had a choice to swap from the current paradigm of running the programs we have now at the speed we have now or running things 1000x faster but only being able to run programs that were programmed 30 years ago, I don't think I'd take that swap.

> but only being able to run programs that were programmed 30 years ago

Take the swap. I don't think you'll loose much. Most programs are doing pretty much the same thing as 30 years ago, but with hi-res graphics

30 years ago was Windows 3.1. People still listened to music on CDs commonly until the smartphone era.

Using a computer was kind of scary even 10 years ago. They were way buggier and had more exploits. Clicking the wrong link in the WinXP era was not advisable.

Programs do the same thing, but they do it more reliably.

At least in the GUI world. I don't know what's changed as far as the command line experience.

You know what? I think I might.

https://en.wikipedia.org/wiki/Amiga_productivity_software

https://en.wikipedia.org/wiki/Oberon_(programming_language)

That was my first thought too, but .. I honestly don't think I'd take that bet.

I still have an A1200, and I struggle to think of anything that'd be genuinely improved by having, eg 7GHz instead of 7MHz (to take the article's 1000x figure) processor. 1000x the serial speed would be useful once or twice a year. 1000x the disk access speeds would be a marginal quality of life improvement (I mean I wouldn't say no, but I wouldn't give my modern machine up for it). But making the whole system 1000x faster would realistically achieve what? A hilarious SysInfo screenshot and little else.

Half the argument is not what you would do with it. The hook is that literally everything you could do back then would be instant. I would very much like that.

Given that Oberon existed, any green-field development I would have to do in that environment, would be completely feasible and comparable to any advanced environment today. The only thing I would maybe miss is a modern IDE, but on the other hand I was a late-comer to that and used (and still use) Emacs for a long time.

Better yet:

https://plan9.io/wiki/plan9/plan_9_wiki/

http://9front.org/releases/

Most applications we use really aren't doing very much more useful than their equivalents did thirty years ago, but they are several orders of magnitude slower anyway.

I don’t agree with this at all. It used to be that, for example, if you wanted to spell-check your word processing document, you had to select “Check Spelling” from a menu, and it would analyze the document and give you the results. Now it happens as I’m typing. There are numerous things like this that we rely on but have forgotten didn’t happen even a short time ago. File search is another. The metadata and contents of files is constantly being indexed so that when you search for something, you get results within seconds if not faster. I remember waiting for Windows search to find a file on a “large” hard drive. It was excruciating sometimes.

None of which can explain why launching an Explorer window takes a perceptible amount of time, or this: https://youtu.be/GC-0tCy4P1U?t=1767 , or any of thousands of similar atrocities of wasting everyone's computing resources and time to accomplish nothing of note.

Because people spouted crap about premature optimization any time someone wanted to do anything like lazy load an uncommonly used feature?

In general, I'd agree. But one of the most productive word processing programs I ever used was WordPerfect 5.1 for DOS. (Not only because while using it you couldn't do anything else that distracted you.)

Okay, you couldn't do page layout for the company newsletter in it very well, but based on the .docx files I've gotten over the years, people can't do that now either.

> The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster.

I think the simple answer is that processing is only a small part of running anything, data fetching is what you're typically waiting for. Sure cache and RAM speeds have increased, but HDDs are still about as horribly slow as they always were. Only the jump to SSDs made a considerable difference in "general" speed recently.

But on the other hand I suppose we can in fact run the original Doom (released almost exactly 30 years ago) at about a quadrillion FPS these days so maybe I'm wrong.

The question could be steel-manned when restated as: why does today's average app, in order to complete an ordinary task - like displaying a series of characters on the screen - need to run 1000x more CPU instructions than yesterday's? Replace "1000" with whatever that multiplier, result of the proliferation of intermediary abstraction layers, actually is. I wouldn't be surprised if it is even more than one thousand, at least extrapolating from this article, which was also posted on this site today: https://danluu.com/input-lag/

Well aside from the usual Wirth's law answer, the key is high abstraction on all levels, which brings bloat with it.

Eventually that bloat will get optimized, as that chart interestingly shows iphone responsiveness being somewhat corelated with increasing years. Same with Windows, where there was a sizable abstraction jump with Vista, which then got slowly optimized over 7, 8 and 10.

There's even abstraction in memory management now, with 64 bit virtual address mapping. I've recently stumbled upon these ARM benchmarks https://github.com/ThomasKaiser/sbc-bench/blob/master/Result... and was surprised that the Pi 4 runs 10-50% slower in 64 bit mode compared to 32 bit. I'd expect there was also a notable speed decrease when going from 8 to 16 and 32 bit systems, since there's twice as much address data to fetch and process.

like displaying a series of characters on the screen - need to run 1000x more CPU instructions than yesterday's?

Because the users want those characters displayed in the font, size and colour of their choosing at a very high dpi, anti-aliased, in a semi-translucent terminal. They might also want the text parsed in real time so that it can be coloured, formatted and checked for spelling and grammar.

Other than the high dpi you could do that in 1995 microsoft word.

And because the programmers want to write it in an interpreted virtual machine ran language with dynamic typing.

True, that as well.

Don't forget they want full Unicode support with all the complicated layout and composition rules.

> That’s not how typical users work, and I don’t think it’s how they want to work.

That's true. But if people were routinely offered convenient ways to automate, build pipes, or whatever the technique, then perhaps normal people would learn and use it.

I think "piping" was meant as a general metaphor for interoperability. We often hear regular folks say "why doesn't X just work with Y"

EDIT: sorry I misposted this reply

Amiga had "AREXX ports" which meant you could script desktop software together in ways not possible even today, on any OS.

It's not enough that there must exist technically, a possibility. The app vendors much themselves go to the trouble of adding such "scriptability" into their apps.

Instead everything is very slick, but very siloed and nowadays tied to a cloud offering, which is great, but it's more often than not locked to that vendor.