April 18, 2016

Some thoughts on JAI

This post will require some context, as I doubt many people are aware of what JAI is, or why they should even care.

The TL;DR on JAI is that it's a programming language being developed by Jonathan Blow with an eye towards using it for video game development. JAI is interesting for several reasons. Jon Blow, as a successful game developer, is one of them; he’s basically his own best use case. The other is that Jon presents and discusses his language in depth via streams (and recordings on YouTube), which is where it caught my attention.

My post here was triggered by watching his "Data-Oriented Demo”. I assumed he was going to talk about Entity Component Systems, which I played with in my minimalist experiments. But instead it reminded me of Cobol (an occupational hazard, in my case) and JIT compilation...

By all means watch Jon's presentation first, as I will butcher the details in favour of some brevity. You really want to hear the nitty gritty from the creator of the language anyway. Instead I’ll just focus on my two random connections.

In the data-oriented demo Jon is showing us the syntax and semantics of the “using” keyword. Here is a brief example, based on his presentation:

     Entity :: struct {
          position: Vector3;

     Human :: struct {
          using entity : Entity;
          name: string;

If you’re familiar with programming —and what are you doing reading my blog if you’re not ?— you’ll see that this defines two datatypes, Entity and Human, where Human has a nested instance of Entity. Ignoring the “using” keyword for now you could write:


and expect the X coordinate of a Human’s position to be printed.

The “using” keyword does two things (in my understanding of it). One is that it lifts the members in the namespace of the given type into the current namespace. So any member in Entity can be addressed as if they belonged to Human, meaning you could shorten the above statement to:


This gives you the effect of a class-like behaviour without actually having used classes. It also makes the general code more robust to changes. I.e. you could move the “position” from Entity to Human without problem, or even introduce an extra type in between to keep hold of it.

Now, of course, this makes us think of Cobol. —Though it may just be me.— Because the effect is one of allowing for "structure-shy qualifiers”. That is, as long as there is an ‘x’ member found somewhere in a ‘position’ member found somewhere in an instance of Human the code will cope with changes. Well in Cobol you can already do this (minus the types) as follows:


Cobol does not care about the exact path from ‘HUMAN’ to ‘X’, as long as there is only one entry in the structure which matches the selector. Without any more ‘using’ keywords we could as easily have written:


How is that for robustness to changes ?

So, to some extent, the introduction of the ‘using’ keyword feels like an explicit way of making qualifiers structure-shy. Why not just make all qualifiers behave that way implicitly as in Cobol ?

But there is another side to the “using” keyword, and that is to add flexibility in how data is managed and stored in memory. Let’s make one small modification to the Human type:

     Human :: struct {
          using entity : ^Entity;
          name: string;

Rather than nesting an Entity inside it, this time a Human has a pointer to an Entity instance elsewhere. The general code, and the above print statements, will still work as expected. The crucial point is that the Entity can be part of an array. That is, all Entities can be grouped together in memory and that capability, if you have read anything about game engine design, is essential for ensuring performance. What JAI allows through its ‘using’ keyword is changing the memory layout relatively easily without having to update most of the code. (Again, check Jon’s presentation for more advanced examples.) 

Being able to experiment with different memory management models in a way which is (mostly) transparent to your code is an amazing feature, and something I have not seen before. We have been moving away from manual memory management because it is error prone and cuts through all of your code. Yet in JAI there’s actually some good motivation to get back to handling things yourself.

But then I made my second connection, and a pretty wild one at that: if changing memory management models for different types becomes so painless, could we not get the runtime to do it dynamically and based on actual runtime statistics ? Think of JIT compilation: depending on critical paths in the code found at runtime it will optimise those paths dynamically and transparently, giving you better performance. Now imagine getting JIT behaviour not just for your code, but for your data as well...

Could JAI be setting us on a path to such a magical world ?

June 28, 2015


What do you do when you have a scriptable Super Nintendo emulator ? You create a program which teaches itself to play Super Maria. *duh*

You may know SethBling from his Minecraft creations, or as a Super Mario speed runner, but my favourite thing so far has to be MarI/O. It's a neural network implemented in Lua running inside the SNES emulator. Given enough generations, and the right scoring function, it figures out how to beat Mario levels:

And he shared the source code, though sadly without a clear license.

June 18, 2015

Wherefore art thou, Julia ?

If you ever wanted to play around with the Julia language, take a look at Juno. It's basically the LightTable equivalent for Julia developers, with an embedded run-time and support for live coding.

Very nice.

February 21, 2015

Caves 'n Critters

So I have started playing what is probably one of the geekiest games around: Dungeons and Dragons. A friend of mine wanted to give it a go, and was offering to DM the experience. We quickly found enough party members to actually give it a go, and we haven't looked back since.

We're currently just playing with the default characters, acquanting ourselves with the game mechanics, and getting into the whole roleplaying spirit. But, being geeks, we also quickly started looking at apps which could help us out with all of the bookkeeping which comes with this game.

What we found was that there was no one app for all our different platforms, and certainly not one which would share its data across our devices. Which meant that we couldn't really help each other out very easily.

Now, as loyal readers of this blog you may have already guessed at what's coming. Yes, I decided to write something myself. And yes, I put it on sourceforge. It's called Caves 'n Critters, and it currently looks something like this:

The main features are that it works across all of our devices, which include laptops (Mac and Windows) and tablets (iPad and Android). In addition, any player who is connected gets all updates made by other players. This is most effectively seen in the combat initiative tracking screen:

The current life totals reflect the changes made by players as their characters take damage or heal. When rolling initiative each player just enters their roll, and the initiative list gets sorted automatically across all screens. The DM can indicate the current active player, and that too is shared across screens.

In its current state it's definitely usable, but the experience on tablets could be much better. It seems much harder than it needs to be to make nice apps by means of HTML, CSS and Javascript. The browser gets in the way too much, and some things just feel sluggish...

We'll be tweaking this one further as we keep playing. If anyone else feels like giving it a try, just download the code, read the readme, and let me know how it all went.

October 19, 2014


If the previous post piqued your interest, then there is now more to be found over at incidentalcomplexity.com. What was initially called Aurora has been renamed to Eve. Looking forward to playing with this one!

September 10, 2014

Projectional Editing

I have written on this blog before about my attempts at building a structural editor which turns the parsing equation upside down. Today I learned there is a name for what I have been trying to create: Projectional Editing. The top hit when googling that term comes from Martin Fowler; which is nice as I based some of my work on his articles on language workbenches.

I stumbled on this terminology through a presentation on InfoQ titled "The Art of Building Tools–A Language Engineering Perspective". It's showing examples of this technique in different contexts. Some pretty low-level programmer stuff, but also in the realm of requirements specification. Very cool.

A related presentation, also on InfoQ, is "Enhancing Notational Flexibility and Usability of Projectional Editors". This is showing off JetBrain's MPS, which is a language engineering workbench used as the backbone by the first presentation. I have stumbled on MPS before some years ago, but I think I may have to take a second look at it.

More interesting still is Aurora, a project being worked on by Chris Granger (of Light Table fame), which I'm desperate to take a closer look at. I'm not sure if Aurora is doing projectional editing, though it sure sounds like it. That and some other pretty crazy stuff (programming in a database !?).

I don't know about you guys and galls, but I'm looking forward to see where all this is going.

August 11, 2014

Hardened Quines are hard

I have mentioned Quines here before as pieces of code which bend the mind. Well, the following Quine bends it a bit further: this one is "radiation hardened".

To refresh everyone's memory, a Quine is a piece of code which, when evaluated, yields its own source code. Well, the linked Quine is one which still functions if you delete any one character!

Who does it better ?