Ideas about a new programming language for games.

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.

As anyone here watched the Jonathan Blow videos on his language ideas? [this 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.

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]

This is very much in spirit to Casey Muratori's (Handmade Hero) 'Compression Oriented Programming' [link] For all the people complaining about both (the lack of) generics and high performance systems level programming, this and his allies in the video game industry such as Mike Acton (Data Oriented Design in C++) [link] and Jonathan Blow (Ideas about a new programming language for games) [this video] argue that performance and the focusing on the problem you are trying to solve are intimately related. Needless levels of abstraction (particularly ones that go against the hardware) and generically trying to solve for cases you will never actually use is a waste of real performance and developer time.

Lol, I'm flattered that you think it's worthy of saving. If you upvote it will show up in your profile in upvoted comments. Also, if you click on the date in the header of the comment, a favorite button should appear. When you favorite a comment it will show up in your profile in favorite comments. > Also just kind of asking for curiosity, do you think a language like go or rust will become popular for developing game engines? I realize game programmers are anti-GC but what if GC technology advances that the performance drop is negligible I wonder. I think it will but on some level, the needs of a game engine are different from the needs of say a DNS server. Jonathan Blow, the developer behind Braid ( [link] ) and Witness ( [link] ) has been working on a language called Jai [link] even though he's aware of Rust and Go. He talks about some of his reasons in this video [this video] One of the things he mentions is that the game industry doesn't care about security that much (which I didn't realize until then but it makes sense) compared with a DNS server or something so his ideal language might have different design considerations than Rust.

EDIT: I have removed what I said about what I think how usable the language is, because it's off-topic. I'm not sure it's the least over-engineered language. What you say is like saying that C is simple because there is only memory and functions! Or, to take from for example [link] Python: What if everything was a dict? Java: What if everything was an object? JavaScript: What if everything was a dict *and* an object? C: What if everything was a pointer? APL: What if everything was an array? Tcl: What if everything was a string? Prolog: What if everything was a term? LISP: What if everything was a pair? Scheme: What if everything was a function? Haskell: What if everything was a monad? Assembly: What if everything was a register? But in any case, there are typically lots and lots of details (Haskell is no exception), and they matter. And also, it takes a lot of experience to get anything of quality done! I like what Jonathan Blow calls this pattern: "Big Agenda language". It might make a programmer's life harder if the language is so opinionated. (Start here: [this video] ) He specifically named Haskell, Java, and a few others, as being guilty of that, and being less usable for sticking to ideological purity.

The way he feels about C++, highlighted in his first video[0], "this ship has taken us pretty far, but now it's done sailing", is pretty much the opposite of how I feel C++ is going to play out in the next few years. C++17 will no doubt be a make-or-break specification with regard to being surpassed by other languages, but with its critical mass of incumbency, and the rate at which tools and compilers are moving now (thanks Clang), I just don't see anything topping it in the near future. C++11/14 does feel like a different language to '03, and I've personally got no doubt that C++17 will feel better again. Promisingly, almost all of the work going in to the language atm is about making major strides in improving developer experience and reducing complexity. The work Jonathon has put in to his language in such a short time is super-impressive, and the ideas and their implementation seems solid, but I think he's really underestimating the time frames required to get something like this up from the pioneering stage to production ... remember that C++ was compiling to C in 1983 . There are other interesting languages taking this approach even today. Vala and Nimrod both spring to mind. At the end of this third video he talks about modern pioneering spririt versus those from the heyday of the space race... well here we are 50 years later, and it turns out that space travel is still hard. I don't think programming is any different. [0] [this video]