
Ideas about a new programming language for games.
About this video
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.
Why it appears in the archive
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.
AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.
From the Hacker News discussion
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: [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.
Read original comment ↗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: [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.
Read original comment ↗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: [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.
Read original comment ↗As anyone here watched the Jonathan Blow videos on his language ideas? [VIDEO] I don't care about the specifics of his language but I think he brings up a very valid point which my summary would be, we should design a language that is both performant AND fun to program. Fun = type less boilerplate, make refactoring easier. C++ is not that language and from what I've read Rust is not that language either. C++ is stuck with backward compatibility so it can arguably never achieve those goals. Rust didn't seem to have those goals it mind, it had other goals so it's not really a fun language either. Too verbose or so I've read.
Read original comment ↗Jonathon Blow has a great series [1] on YouTube where he's designing and implementing an alternative to C/C++ specifically aimed at meeting the needs of modern game programmers. It's an interesting watch. [1] [VIDEO]
Read original comment ↗This is a nice talk from Jonathan Blow (Braid's author) about the necessity of a new language for game programming as an alternative to C++, and why new languages like Go or Rust are not apt to the task: [VIDEO]
Read original comment ↗From a gaming industry perspective, Jonathan Blow gave a great presentation about his problems with C++: [VIDEO]
Read original comment ↗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. [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.
Read original comment ↗