Jonathan Blow
7 HN recommenders · recommended in 15 months, 2014–2025
1:55:24 · 530K views · Sep 19, 2014
Jonathan Blow's first talk on designing a new programming language for games, which became Jai. He explains the problems with C++ and why Go, Rust and D do not fit game development.
HN programmers recommend it, and the Jai series that followed, for the game-industry view on replacing C++ and for watching a language being invented.
18 comments from Hacker News
I strongly encourage anyone interested in programming languages to watch his series about Jai, the language he is creating for his next game. Starts here: this video It's not released yet, but watching the videos has massively changed the way I think about programming. The notion of "data-driven programming," which I would describe as "only move around the data you have to", has been a real revelation to me. I sort of came out of the Ruby world (and Java before that) where the attitude is more "Abstract all the things!" I have been trying to apply many of Blow's principles in my JavaScript programming and it has been awesome. I find myself staying closer to the "metal" (which in JavaScript world is pure Node and low-level browser APIs) and it has been incredibly rewarding. I've also really enjoyed his policy of pragmatism over idealism. I think the React world for example has taken a good idea (immutability can clarify data flows) and turned it into a religion (Everything Must Be Immutable!) Watching Blow work has given me the confidence to steer away from that. Much in the same way that learning Rails made me a better programmer (even though I don't use it anymore, and I've rejected a lot of its premises) I have found learning Jai has really leveled me up as a programmer and a computer science thinker.
It’s a bit of a rabbit hole, but Jonathan Blow’s “Ideas for a programming language about games” and all the subsequent videos have totally revolutionized how I code: this video The irony of it is I’m a JavaScript programmer and Blow hates JavaScript, he thinks it’s antithetical to his style of coding. But really, I think the ideas are very generic: he proposes what I think of as “data-driven programming” which in my head means “only move the bits you have to.” And that core idea maps to any substrate. Blow is offended by the idea of targeting something other than processor instructions, and Jai (his new language) develops along those lines. But I have no problem applying the same ideas to V8... you can really use any substrate... I could target Minecraft blocks and code in the same way. It just requires stepping back and asking what the minimum number of writes needed to get that substrate where it needs to be. And then rather than writing some monstrous declarative programming structure like Rails or Webpack, you just write the minimal function calls needed to make those bits flip and thing more. Blow writes a whole new language and compiler based on those concepts, but I find the ideas translate to any arbitrary API target.
I am a little disappointed he hasn’t released the source, but I am also sympathetic. He wants to be free to change major things about the language while he’s designing it, and that’s harder if other people are using it. That said, if you want to know what Jai is about, I recommend starting from his first video: this video The first couple dozen videos are all pretty dense, with him presenting the basics of the language pretty efficiently. (His more recent vids are more like development vlogs) Yes, videos are slow, but for me I don’t think I would’ve appreciated his design choices without all the context. I also found watching his process for inventing the language extremely instructive, just as a programmer. It has substantially formed my own process and thinking over the last few years.
Jonathan Blow (cult/indie game developer/studio owner) has a lot of ideas about evolving C++ (or rather, building a new language to replace it) specifically in a game industry context. This perspective is interesting because its kind of running at a different angle away from the "memory-safe, better guarantees" project that Rust is workin on. this video Just as the scripting languages took a big bite out of C/C++ usage starting in the 90s, I think we're seeing another couple use-case for C/C++ pull off: 1) stuff that is performance sensitive but security sensitive as well (Rust) 2) stuff that is soooo performance sensitive that Rust and C++ are actually too bloated, but which isn't really security sensitive so the guarantees that Rust/Modern C++ offer aren't worth it (Jai, Blow's language). Category 1 is clearly real, but Category 2 might be too small to sustain itself (though Blow makes an economic argument that it would be worth it). Are we just going to keep peeling back C/C++ users from the pack with more specifically-useful languages until there are none left except for those maintaining legacy code? Or are there use-cases where C++ will continue to make sense? I guess a lot of this depends on whether or not we can meaningfully "modernize" C++ through the standards process without simply bolting on a lot more features that add to the bloat. I wouldn't wager much that this trick can be pulled off.
His view of Rust is a little more nuanced then you're getting here. Back in 2014 when Jonathan Blow started talking about the reasons for making a new programming language he discussed several languages including Go, D and Rust and provided specific reasons why they didn't satisfy his view of what a language for game programming should be. During that talk he said at one point; "if we're all writing programs in Rust ten years from now then that's great because I think it'll be a lot better than C++." You should consider watching at least the first part of that talk. It made a splash at the time because there are several insights that people found provocative. [1] this video