Setting aside incentives – because I think that's very fair to push back on, we should strive for better craft...

I find Blow in particular a bit naive when it comes to the complexity of modern non-game software. Games are very complex, but Blow puts them on a pedestal separate from other software, as if a web backend can't be as complex. He calls software slow while simultaneously ignoring most of the functionality.

He's essentially never had to deal with distributed systems, or anything that allows multiple users to use the same system, with all the performance and anti-abuse issues that come with that.

His opinions about game development are insightful, and his thoughts on craft can be quite inspiring, but I think he could benefit from a stint on a (good) big tech server team to see some of the things he's currently missing.

Heh heh heh. In actuality, Jon Blow has plenty of experience with distributed and multi-user systems. I worked closely with him while we were developing TinyMUCK 2.x, and the MUF programming language, a stack-based, simplified Forth.

In fact, Jon played a crucial role in the invention of the first MUF worm. We had just finished an extension to MUF that permitted triggering programs wherever a text string was expected. This gave a great flexibility and functionality to run MUF programs passively, by third parties, all kinds of new ways.

Unfortunately this also gave rise to a "worm" type of MUF that replicated itself whenever it was triggered passively. We went a little crazy when this was discovered, but it was all part and parcel of a multi-user game system, where there were permissions to consider, and multiple read/write/execute access to objects that should be owned by their respective player characters.

Jon Blow also inspired a lot of my exploits as I tested other systems of MUD programmability. In that time, TinyMUSH was also experimenting with a language that was more akin to scripting, and boy was it vulnerable. TinyMOO was also coming out, with a rather revolutionary programming paradigm. So in the mid-1990s, just in the insular TinyMU* world, there were at least 3 branches of programmable MUDs being actively developed.

Hopefully Jon could recall my greatest contribution to the corpus of early MUF programs. On Atlantis MUCK, I programmed a simulation of Conway's Game of Life. Of course, there was no animation possible and there was no multithreaded execution possible, either. So my program was given a starting board of Life, and then computed each frame in sequence, output it into the text stream of the game, and terminated after N iterations. Meanwhile, the entire game server locked up, because it could only run one MUF program at a time. Everyone else's commands and input would be held until my MUF program finished running.

This was a real issue, of course, and Jon and I worked to mitigate the problems caused. I think, ultimately, we just limited the number of iterations or the number of instructions that could be executed by any one MUF program at a time.

But Jon and I collaborated on a tutorial for player-programmers, and he helped us find and extinguish many bugs. And these were very complex systems, with 64 or even 256 simultaneous players.

Perhaps Jon has forgotten some of those lessons, but perhaps not.