Why does this matters?
Turing proved that there are at least infinite ways to program, be it Turing Machines, Lambda calculus, to more recent ones like Javascript and Pokemon Yellow.
To many considering that programming could stop being text based on the future reflects and uncomfortable thoughts. While others bet on the so called "no-code" tools, that while certainly useful and very popular with Venture funds, to this day have failed to attract more technical developers.
Nodon Oriented Programming fundamentals
On Game Builder Garage player define their games in terms of little boxes that connect to other boxes called Nodons. There are 4 kinds:
- Red nodons (Inputs)
- Green nodons (Middle)
- Blue nodons (Output)
- Orange nodons (Objects)
And we use them to define our "programs" or "games" in GBG.
At this point it should be clear than a GBG program is a graph (or more precisely a property graph or a labelled directed multigraph) that the GBG interpreter is capable of turning into an interactive experience.
With this framework it's easer to get what the kinds of nodons are all about. The input nodons only have outgoing edges, the output nodons only have incoming edges and the middle nodons support both.
There is then the case of the object nodons, they don't seem to fit the mold, however it's quite easy to work it out. Object nodons are nodes that have general incoming edges but only support "children of" outputs. This is what the game uses to relate how things move in terms of other objects. The game even uses special connector points to indicate this:
That's not the end of the story sadly, nodons also have intristic properties, these are basically data that we can use to specify the behavior of each nodon. For example: We can use the properties of the text object nodon to indicate what text to display.
Let's delve a little bit deeper into the quirks of these graphs.
The game does not separate them but we also have nodons that have neither inputs nor outputs, they are just "there" to hold some data, like the World nodon, that is used to describe meta properties of the game enviroment like gravity and look and feel. And the "Comment" Nodon, which is used to put comments on the nodon space (In turn, GBG Nodons might well be the first programming where comments are intrinsic feature of the language)
Outputs Nodons are almost exclusively used to describe effects, things the interpreted nows how to do like play music or make a controller rumble.
The outputs node are not outputs in the sense of "program output" but simply mean that they are nodes that do not have any outgoing edges.
So far this is no different than other "boxes and arrows" visual programming languages like Unreal's Blueprints.
What programs are easier to declare with a graph like this?
In principle this is yet another way to describe interactive UIs in declarative programming. Easier is a relative term. However, we can image a few ways on when I programming like this makes sense.
The special sause of the nodon oriented programming language is that the relative position of nodons to one another has semantics. And this is novel, in regular programming you can't import a module closer to another in any meaniful way.
Take for example, an ETL
A → B → C → D1
→ D2
→ D3
Imagine I could use the visual length of the arrow to describe the priority of a fork like with D1, D2, D3. I could use that information to specify on a simple way to the systems to prioritze for example D1 work over D3. We could use edge size to indicate proportional dependency. We could use that model to indicate an orchestrator, say kubernetes that it is fine to put D3 on another computing node, but that we need C and D1 very close together. Latency is something we don't think often working with services architectures.
Imagine we could use the size of the node to indicate it's trouput.