The world could run on older hardware if software optimization was a priority

I'm going to be pretty blunt. Carmack gets worshiped when he shouldn't be. He has several bad takes in terms of software. Further, he's frankly behind the times when it comes to the current state of the software ecosystem.

I get it, he's legendary for the work he did at id software. But this is the guy who only like 5 years ago was convinced that static analysis was actually a good thing for code.

He seems to have a perpetual view on the state of software. Interpreted stuff is slow, networks are slow, databases are slow. Everyone is working with Pentium 1s and 2MB of ram.

None of these are what he thinks they are. CPUs are wicked fast. Interpreted languages are now within a single digit multiple of natively compiled languages. Ram is cheap and plentiful. Databases and networks are insanely fast.

Good on him for sharing his takes, but really, he shouldn't be considered a "thought leader". I've noticed his takes have been outdated for over a decade.

I'm sure he's a nice guy, but I believe he's fallen into a trap that many older devs do. He's overestimating what the costs of things are because his mental model of computing is dated.

> Interpreted languages are now within a single digit multiple of natively compiled languages.

You have to be either clueless or delusional if you really believe that.

Let me specify that what I'm calling interpreted (and I'm sure carmack agrees) is languages with a VM and JIT.

The JVM and Javascript both fall into this category.

The proof is in the pudding. [1]

The JS version that ran in 8.54 seconds [2] did not use any sort of fancy escape hatches to get there. It's effectively the naive solution.

But if you look at the winning C version, you'll note that it went all out pulling every single SIMD trick in the book to win [3]. And with all that, the JS version is still only ~4x slower (single digit multiplier).

And if you look at the C++ version which is a near direct translation [4] which isn't using all the SIMD tricks in the books to win, it ran in 5.15. Bringing the multiple down to 1.7x.

Perhaps you weren't thinking of these JIT languages as being interpreted. That's fair. But if you did, you need to adjust your mental model of what's slow. JITs have come a VERY long way in the last 20 years.

I will say that languages like python remain slow. That wasn't what I was thinking of when I said "interpreted". It's definitely more than fair to call it an interpreted language.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[3] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[4] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

fwiw There are a few naive un-optimised single-thread #8 n-body programs transliterated line-by-line literal style into different programming languages from the same original. [1]

> a single digit multiple

By which you mean < 10× ?

So not those Java -Xint, PHP, Ruby, Python 3 programs?

> interpreted

Roberto Ierusalimschy said "the distinguishing feature of interpreted languages is not that they are not compiled, but that any eventual compiler is part of the language runtime and that, therefore, it is possible (and easy) to execute code generated on the fly." [2]

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] "Programming in Lua" 1st ed p57

> By which you mean < 10× ?

Yup

> So not those Java -Xint, PHP, Ruby, Python 3 programs?

Pretty much. The Java -Xint stuff turns off the JIT and purely uses the interpreter. That's not how anyone (that I'm aware of) uses java. I had to look up exactly what that flag did.

Ruby I think might be underperforming because `yjit` isn't enabled by default. I suspect the same of Python (it just got a jit with python 3.13. Looks like it's still marked as experimental)