I've recently been working on a comprehensive automated flight program. In my first iteration, I did it the way I think it is intended to be done, based on the way vizzy works. I made 'instructions' that would read in values from the craft, then perform actions based on those values, using expressions to perform lengthier calculations. But that doesn't scale very well. Particularly for very complex precomputation.
Behold the solution: Object oriented programming in Vizzy.
Is it an abomination that should be returned to the fiery pits of Vulco? Yes, yes it is. But allow me to explain anyways.
The basic premise is to store 'objects' as lists. Now, lists have quite limited operators by default - so some 'creative' workarounds are needed for doing things like joining two lists together as an expression (I'll get to why that's important later). To make it brief though, it involves converting the lists into comma-separated strings, and using the 'create list from' expression (which has to be plucked out of the initialize list instruction).
Now that storage is solved - what about methods? Well, unfortunately, instructions can't return values. This leaves us with two options. Either we use a set of global variables as 'registers' to be set and read from by object-related functions (which is liable to break if there are multiple threads), or we leverage expressions. I went for the latter.
Allow me to explain how this works with a specific example from my flight program, which is the 'orbit' object. I have a 'Orbit_getSize' expression, which returns a constant, that I can change whenever I need to add a new variable to my object, and I have getters in the form of 'Orbit_getSMA' or 'Orbit_getEccentricity'. Unfortunately, setters don't work so cleanly. It would be visually bulky/inefficient to have instructions as setters, so instead, I simply allow a violation of the OO principles, and let objects index into the underlying lists to set values. But this happens quite rarely for most objects. Usually, it's a 'set once read many times' situation. In order for those getters to work however, they need access to the object. This is actually quite easy; just have the first parameter to each object-related expression be the object itself.
Anyways, I'm done rambling. Is there any benefit to doing all of this? Maybe. I think if you're someone who likes a challenge, it can be fun to optimize/re-design systems like this. If any of you have some suggestions, I'd love to hear them. (Beside the obvious suggestion of "don't")
EDIT: After some experimentation, I've come to the conclusion that using instructions with global registers isn't so bad - particularly for constructors. For instance, I made a 'Generate Hohmann Transfer Orbit' function, which generates a new orbit (the transfer orbit), if given two co-axial orbits. I tried this before as an expression, but the expression got painfully long, and needed several 'helper' expressions. In the end, using instructions + global register-variables cleaned up the code quite a bit.