> I think the point he makes is that we might be losing the ability to produce efficient code because we’re not teaching these techniques. And that is perhaps why we buy $3000 Facebook browsing machines that don’t feel any faster than computers 20 years ago. Often they are slower.

I think you are just paraphrasing his point, so don't take this as a shot in your direction, but anybody who remembers computers 20 years ago being faster either has some serious rose tinted glasses, or was not using computers 20 years ago. They were incredibly buggy and slow. Basic users crashed their Windows boxes often enough that "blue screen of death" was a common phrase (which is to say, we're advanced users here -- we can even get Linux to crash -- but normal computers are pretty good nowadays if you just use them like a normal person).

If they felt faster, that's because we were using a text editors rather than office suites, because we didn't want to wait minutes for an office suite to start up (and then crash). You can still use a text editor and vim at least is still pretty snappy.

Like surely we can all remember the first solid state drives we installed, right? The feeling of not waiting for programs to load was remarkable. Now we're just used to having programs start instantly.

Things are actually quite good, we're just used to it.

I mean, the internet is kind of a mixed bag. Javascript is annoying and everywhere. But on the other hand, remember when Java applets were a thing?

I find https://danluu.com/input-lag/ to be quite convincing and a direct contradiction to your point. He has some analyses of various other elements of computing, too. We certainly haven't gotten faster across the board and I'm still amazed at how slowly many of the programs I use today actually load.

I remember reading that piece, and found it to be interesting and accurate, but somewhat irrelevant. Most people just don't care about latency that much. If we go back to an ancestor high up in this thread, "low latency input and display" is not a goal of computing. "Enabling people to do things they find useful and/or have value" is the goal. And it just turns out that, for most tasks -- even most gaming tasks (or other things where you might say "low latency is important") -- low latency just is nowhere near as important as just being able to do these things at all.

Sure, we might sometimes notice the latency and find it vaguely annoying, but we put up with it because modern computing (with all the attendant "complexity" or whatever that makes low-latency hard) enables us to do things that computers of 20 or 30 or 40 years ago were just completely incapable of doing.

And for the people who really do care about low latency, they can usually build something custom that gets them where they want to be -- as Dan Luu points out in his piece.

I tried to follow his advice for a while but didn't ever notice a perceivable difference between, say, st and alacrity. I think the justification for why we care about latency, there, is a bit fuzzy -- the examples he provides are about stylus inputs, the feedback loop there is more direct and there's more physical experience. I can't tell you what you feel of course. Currently I use kitty. Perhaps I'm blessed by unusual latency insensitivity....

There came the trend of leaving your computer on instead of powering it off just because starting up was so slow.

So much has improved that Blow’s arguments about how much better computers used to be has an air of Old Man Yelling at Clouds to me.

Booting into Workbench off a floppy is fun and all but my current machine boots up so fast now it’s ridiculous.

> but anybody who remembers computers 20 years ago being faster either has some serious rose tinted glasses, or was not using computers 20 years ago.

Or they're using something like the grade book in Canvas, a very popular LMS, and finding that it is in fact slower than GeoCalc on a C-64.

> I think you are just paraphrasing his point, so don't take this as a shot in your direction, but anybody who remembers computers 20 years ago being faster either has some serious rose tinted glasses, or was not using computers 20 years ago... You can still use a text editor and vim at least is still pretty snappy.

This is a single analysis from a single person, but if you look at empiric data for latency in terminal text input, there is a pretty significant negative trend over time: https://danluu.com/input-lag/

That article is talking about a very narrow aspect of latency, things like "if I press a letter on my keyboard, how quickly does it show up on my screen?" And most computer users care much more about throughput than latency, within reason, anyway.

But 20 years ago, starting applications was slow, because spinning-rust hard drives were slow, CPUs were slow, and we didn't have as much RAM. Yes, applications executed fewer instructions to start up, and used less RAM back then, but today I type on a 13" laptop with 64GB of RAM, so much that my OS doesn't know what to do with most of it, to the point where the OS filesystem buffer cache is "only" using up 12GB, and 44GB is just sitting completely unused for anything. Yes, maybe it's absurd that running a desktop environment with a browser (granted, with over a thousand tabs open), some terminal emulator instances, and the one annoying Electron app I can't get rid of, consumes 8GB of RAM, which alone is three orders of magnitude more RAM than I had 20 years ago.

But the bottom line is that I, as a user, just don't need to care about resource utilization. I don't need to close my word processor when I want to play a game or watch a video. Oh, speaking of that -- in 2000, my CPU didn't have the ability to decode DVD-quality MPEG2 video in real time! If I tried, CPU usage would be pegged at 100%, and the video would still stutter and be unwatchable. (I'm not saying that there weren't CPUs in 2000 that could do this, just that mine could not, and I couldn't afford one that could.) Today I can stream 4k video from some storage location tens or hundreds of miles away, and decode it (on GPU or CPU) and play it back on a machine that sits on my lap (the aforementioned 2000-era CPU of course lived in a big tower case).

"Computers were faster 20 years ago" -- yeah, right.

See https://news.ycombinator.com/item?id=32616485

I disagree, Microsoft Word on a Mac in the 90s was lightning fast and rock solid.

Few apps start up instantly in 2022. Many require a good network connection and/or a half a gigabyte of RAM, for no good reason.

> I think the point he makes is that we might be losing the ability to produce efficient code because we’re not teaching these techniques.

Is this true though? It honestly seems to me that it's more like we teach a lot more people to do those techniques than will ever need to use them, and that this results in a lot of frustration and / or time spent prematurely optimizing.

I think we'd have to define "efficient code." Like, not doing something big-O stupid? That's covered in computer science classes and as a science it is pretty human-understandable and timeless. Micro-optimizations? Perhaps between optimizing compilers and massive reorder buffers/massive caches/clever branch predictors, there's not as much need for that sort of thing.

College programs teach both things. Then you go into the working world and it's just not what most people spend much of their time doing, not because of some oversight or deterioration in society or something, but simply because there are more important things to do. And this frustrates a lot of people (especially young people) who loved that part of school and maybe even got into the whole thing because they loved this part of it. Then sometimes those frustrated people (or in order to avoid becoming frustrated), people spend a lot of time on it, even though it's really not the most important thing to work on. And that's fine and all, there are definitely worse things to spend time on, but it also makes sense that a lot of other people spend all their time on the higher priority things.

I don’t know if there’s ever been a comprehensive survey on the subject. But it does seem like a rare skill some times. And it’s not like we’re lacking examples of bloated, slow, and error prone software these days.

Is it getting worse? I don’t know. My impression has been that it’s a marvel it works so well when it sometimes seems like the whole enterprise is too complicated to work at all.

But maybe we have simply been conditioned to not want better. Errors are fine, leaking memory happens, security vulnerabilities are inevitable. What can you do?

Is it worse than it was 20 years ago? I don’t know. I’m not much younger than Blow and grew up programming on an Amiga. I do enjoy fond memories of programming a machine that I had a manual for and knew well. It is very different today… but also much easier and more inclusive of folks with different skill levels.

I don't know if we should necessarily use slow/buggy software as examples. IMO it's very conceivable that it's written by devs who know better, but they're not optimizing for those metrics. I've certainly been in situations where I've thought "well, I can reduce latency here by 100ms, but is that worth delaying the project by 2 days?"

Well, I wouldn't go that far. Blow is a smart guy, and games are hard to make. Two mainstream successes are more than I have. :P

> If we only teach folks how to script Unity and Unreal how are we supposed to get the next generation of engine developers to build the foundations of the technology?

Why can't we have both? Lowering the bar to allow less-experienced engineers to create things doesn't mean that we've prevented engineers with more experience from continuing to exist and thrive. We've just created a richer stratification of skill levels than previously existed.

Fair, I was being a bit harsh with his credentials. He’s also freely streaming and posting how bad modern software is.

And again I don’t think he said, in the talk mentioned in tfa, that we can’t have both. His primary concern seems to be that the scales have tipped too far one way.

I think there is some merit to that. Go to any game dev forum and ask about programming and 9 times out of 10 you will be guided towards using a game engine. The common wisdom is: don’t learn to program, just make the game.

And that is 100% fine advice and Blow admits that in the talk.

But knowledge transfer is the key here and if we’re not making enough space in the education of future programmers for that lower level part of the stack then maybe one day we (as in society) could forget how.

I still think that’s highly unlikely to be happening today but it’s an interesting thing to think about.

I find myself often frustrated by how much gobs of memory, fast drives, and cores we throw into modern machines and yet my browser can still stutter while scrolling a page.

I'm not really so worried about this knowledge transfer thing. I think programming knowledge is being transferred just fine. It's hard to see it, though, because there are several orders of magnitude more programmers now than there were 20 years ago. You don't need a constant X% of programmers to know how to build a game engine. You just need a couple hundred of them, or so, and as long as that knowledge is passed to a couple hundred of the next generation of programmers, that's fine. And if only a couple hundred -- or even a thousand -- programmers know how to build a game engine, it's easy to see how it might feel hard to find those people among the millions of programmers out there. But they're there, and they're mostly probably doing useful work and are propagating their knowledge appropriately.

I also think that many many many more people know how to write efficient programs than Blow or other doomsayers might fear. It's just that most of us have better things to do than micro-optimize or write our own engines or toolkits or whatever for everything, and the state of modern computing means that we don't have to bother -- even while many of us decry the inefficiency of things like Electron, or in attempting to write a high-scale distributed system in Python or Ruby. And I agree with you that it's dumb that we can throw an 8-core 4GHz CPU and 32GB of RAM at a web browser, and it can still stutter while scrolling down a page. We clearly haven't always found the best balance here. But that doesn't mean we've lost the ability to do so.

I think plenty of people have all this tribal programming knowledge, and they're doing just fine passing it along to the next generation of programmers. It's just that most people don't need to actually make use of that knowledge in their day-to-day work. Yes, I do believe that lack of use causes some atrophy, but I don't think that's the big problem that some would make it out to be.

> He has released two games in his career so far and an as-yet-to-be-released compiler that he’s been toying with for years: and he calls modern software developers unproductive!

In fairness he's been juggling multiple projects at the same time over the "for years" period that you mention: the new programming language, one major engine and game in said language, new releases for Witness and Braid, a secret game project, plus managing a game studio on top.

Also the two games he released "so far" are pretty popular and pretty well received by the critics _and_ they're programmed from scratch.

I think you're being a little uncharitable to someone that probably spends 75% of their waking life doing work (or ranting).

I don't think it's uncharitable at all. The point of writing software is to get it into the hands of users so they can use it.

I have a lot of respect for him for doing such high quality game work, mostly or entirely on his own. But let's not pretend he's some highly-productive programmer who churns out groundbreaking software at some amazing pace. I reserve such praise for people like Fabrice Bellard, who not only builds amazing things, but has built a lot of amazing things.

Tinkering around with a new language is cool and impressive, but it doesn't make you a "productive" programmer. Managing a game studio is useful work, but it's not "productive programming". I agree that his two games are great, and it's impressive how they were built, but... so what? He spent three years on Braid and seven years on The Witness. Is it "productive" to spend ten years writing two games? Not saying he was wrong to spend his time as he did; that's entirely his choice, and I know I personally have appreciated the output of those ten years. But I think many programmers have done much more productive things than building two games in ten years. I'm honestly not trying to shit on Jonathan Blow, but I think the hero worship I see over him is just a bit much.

Fwiw I would say he has been highly productive compared to most engineers. Two complete games of that quality nothing to sneeze at. But he does seem to take certain ideas much further than I would