The Luddite sentiment common among programmers today really surprises me. The software we’re building today is vastly more powerful and capable than anything from the C64 era.
Luddite is someone who is opposed to new technology, which doesn't apply here as the sentiment isn't about being opposed to the new tech but about the new tech not being taken advantage of.
The software we build today is "vastly" more powerful in the sense that, strictly speaking, you can do more stuff, but it is way less powerful - and often broken - than what it could be, considering what you can see being possible on older hardware and what seems to be done in modern hardware.
Also it isn't really something that happens today, here is a nice (and funny) talk from Joe Armstrong on the topic from almost 8 years ago[0]. Though this sort of sentiment goes way back, e.g. Wirth's classic "Plea for lean software" article from 1995[1].
(Joe's talk is more about the broken part and IMO he misidentifies the issue being about trying to make things fast when the real issue -that he also mentions- is that pretty much nobody knows what is really going on with the system itself)
This is because people don’t want to pay the cost of software carefully developed to take maximum advantage of modern hardware. In specific niches like audio production where this is desired then prices run into hundreds of dollars for a single plugin to cover the development costs.
It's always this way. Just like most people are happy with Ikea furniture, so most people are happy with the equivalent of "Ikea software". It's good enough. For folks who _are_ willing to pay, you can buy everything from low latency audio gear/software to dedicated Internet bandwidth to high reliability SBCs.
And even then, quite a lot of that audio production software is very, very inefficient, primarily due to poor GUI development. There are a few popular choices of software that are very well-known for being CPU hogs, even relative to more complex software.
Particularly the business often doesn't want to take on the goal of improved performance when good-enough will suffice. Which can often make sense when you factor in increase development costs, reduced flexibility/maintainability, and reduced ability to recruit for people with the skillset to work on such things.
Then again, performance is often a feature in itself. In some cases it can open whole new areas of potential business. Often times it isn't even particularly hard to achieve, it just requires decent engineering practices.
Unfortunately good engineering practices can be hard to find/hire for, especially among a development community/culture that hasn't had to bother caring about performance for a long time.
On the C64 text was PETSCII [1]. On your Mac in Chrome it's Unicode. Running a basic multilingual plane text editor on the C64 is probably impossible due to RAM constraints. Even with a RAM expansion and imagining it had a framebuffer I'm doubtful that the C64 could edit Unicode text at interactive speeds.
In the 1980s only a small portion of the developed world's population used home computers. Today the majority of people use computing devices. Most of them use languages that cannot be represented with PETSCII or ASCII. It's amazing what motivated people can do with low power machines, but let's not forget how going back to the 1980s would discard valuable capabilities as well as bloat.
People from the 1980s are still alive and they’re not making anything more impressive than anyone else.
These people weren’t magicians only held back by a lack of computer power, they were (again, “are”) regular people trying to maximize their output given their resources.
Let’s say you go back and hand a powerful computer to them. What would Mac Paint look like? I’m sure it would have colors (assuming you also have them a monitor), probably a lot more of those goofy and useless textured fills nobody wants, layers, probably some filters, higher resolutions, and probably simple brush strokes. But do you really think they would manage to implement any of the seriously impressive features that modern Photoshop has? Content aware fill? AI upscaling? Of course not. It would probably take them a long time to get smart selection working in a halfway decent manner.
Honest question here: have you actually tried to find the answer to that question?
As I'm writing this comment, my 2019 Pixelbook Go is quiet. It's a fanless design, so it being quiet is normal, but it is also not running hot. I've got around 30 tabs open, a few terminals, Emacs, and some other stuff running.
So back to my question - have you looked into what is actually going on in your machine? Dust in the fans?
"my 2017 macbook is spinning fans, as ... like 3 tabs open on chrome"
Chrome might be your issue. Doing the same on on a 2015 MacbookPro and it's silent... Firefox.
I don't think it's "Luddite sentiment" to ask why one computer feels as productive with the same perceived performance as one that's literally a billion times faster.
I believe the sibling saying that it's programmer productivity is correct. That same programmer can and does now spend a week whipping together a program in Python that took a year under the older constraints. And users expect more out of them, with whizz-bang animations and app-store integration.
But if that same programmer _did_ spend the year instead of the week, what could they do? The quality and performance would probably be a lot better. Unless they depend on externalities that don't also scale up their quality game, like basically anything involving the web.
It’s Luddite in that it rejects modern tools and methods in the belief that there’s an older, more artisanal method of doing work.
If you believe this is the case then you can put your belief to the test. Build software the way you think it should be built and see if users are willing to pay for it.
> If you believe this is the case then you can put your belief to the test. Build software the way you think it should be built and see if users are willing to pay for it.
"users willing to pay for it" is a very bad and simplistic metric because there is way more to user willingness to pay for something than how that something was made (not to mention that it excludes everything the user doesn't pay for) - it may not even have to do with the software itself.
Also the software in question may not even be "free" to use the better approach: imagine, for example, a client for a chat service that allows embedding images, videos and audio in messages but the way the protocol works is for the server to provide those as iframe and/or html content. At that point the client will have to use a browser component in one way or another with all the baggage that entails even if the features themselves (images, videos, audio and text) could be implemented directly by the client.
There is only so much you can do when you have to interface with a world built on tech that doesn't care about efficiency.
I'd argue that most python programs couldn't do the same in a year under older constraints. It's objectively more difficult to write 6502 assembly than it is to write python.
Modern computers have opened programming up to more people by making it simpler but with the tradeoff of more runtime execution cost.
