> JS is quite a bit faster than, say, idiomatic Objective-C.

(a) That depends hugely on what you consider "idiomatic" Objective-C and (b) yeah, that's kind of my point.

If you write Objective-C in the style that is currently popular and propagated, treating it as a unified programming language like JS, Java or Smalltalk, you're going to be slow. In my book[1], I show how easy it is to be slower not just than JS or Java, but even slower than a byte-coded Smalltalk interpreter or Ruby. And the sad part is that it's not even particularly expressive!

On the other hand, I also show how you can use the original Objective-C style, let's call it "Software-ICs", to create an XML parser faster than libxml and with a much nicer interface, or a Postscript interpreter that uses Objective-C objects as Postscript objects and is still faster than Adobe's interpreter (written in C) for most basic language stuff like arithmetic and loops (it doesn't do the graphics itself, so comparing those numbers would be pointless). In fact, said Postscript interpreter, written in Objective-C, is faster at arithmetic than the "bad" Objective-C style, while doing automatic arithmetic promotion, so being safer.

The "Software-IC" style for Objective-C involves fast components written in C connected at the architectural level by dynamic messaging. It is highly idiomatic, convenient, fun and fast as hell. Interestingly, variations of that basic style are being rediscovered these days by the people doing "imperative shell, functional core". See for example Gary Bernhard's talk[2] and then tell me that the final picture doesn't look almost exactly like the pictures Cox drew of Software-ICs (and remember that Cox also said that (a) messaging didn't have to be synchronous and (b) the implementation language for the Software ICs didn't matter much). The Unix tools are also very similar, with fast components written in C connected at the architectural level with pipes.

This is also the reason why I think my Objective-Smalltalk language[3] actually has a good chance of enabling very fast programs despite the very high level of abstraction it is aiming for. Being able to pick an appropriate interconnection style and fast components is the key to fast software.

Back to the original point, we are leaving orders of magnitude of performance on the table, quite frequently for no particular reason. And as I wrote elsewhere, I actually think this current point we have reached is good for software and for software people, because we can get that performance quite easily by writing decent code, and writing decent code is starting to matter more again. Just like I think the end of Moore's law might finally break the stranglehold Intel has had on hardware architecture, so innovative architectures (remember the Transputer[4]?) have a chance and aren't clobbered by Intel's next fab-step. Speaking of innovative hardware architecture, has there been any new news on the Mill?

Interesting times.

Anyway, I didn't bring up JavaScript, this problem is everywhere. I just thought that bringing it up as a counterpoint was...humorous.

[1] Did I mention my book? g https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-...

[2] https://www.destroyallsoftware.com/talks/boundaries

[3] http://objective.st/

[4] https://en.wikipedia.org/wiki/Transputer