A few of the flight simulators I work with use a novel software framework developed inhouse by the manufacturer. I'm curious if any of you can
identify something similar.<p>The convential approach for commercial flight simulators is to use a large shared memory to hold the state of the simulation, and a game loop. Hardware interface signals are fed into that shared memory, and every iteration of the game loop executes software that reads and updates the shared memory.<p>The novel approach uses no shared memory. When a hardware input signal changes, it raises an "event" consisting of a name and value. The
software then raises any other events that depend on this one. They have created a programming language to get the most from this. In that language, say you have:<p>a = b + c<p>d = e + f<p>These two lines will NOT get executed in sequence. They declare relationships between events. When event "b" occurs, the event "a" will be raised and its value depends on b and also the last value of the c event.<p>It turns out this is really powerful and works well on a distributed system. Did they create something new here?
Many have pointed out a number of implementations of the model you mentioned. This is generally known as the actor model (<a href="http://en.wikipedia.org/wiki/Actor_model" rel="nofollow">http://en.wikipedia.org/wiki/Actor_model</a>) in which messages are passed between a number of distinct actors.<p>This is actually a fantastic model for distributed systems and was implemented in the Erlang programming language for that very purpose. It is the other major model of concurrent computing outside of having some kind of shared memory space (in a true actor model there is no shared mutable data).
You can think of it as dataflow programming where (event,value) tuples are the data.<p>You can still think of it as the same old shared memory approach, where before the game loop frame gets to "look" at it, some conditional event propagation and generation is performed. In other words if b and c are hardware events. Their values get written to the shared memory. Before the game loop gets to look at the memory, there is a stage where a (an event derived from b and c) is generated. Of course, now you don't have the limitation of a physical piece of shared memory. These events can be distributed across many machines.<p>> It turns out this is really powerful and works well on a distributed system. Did they create something new here?<p>I think the power comes from creating a DSL that fits very well in your domain (problem space). It lets you manage a lot events and express relationships between them. Also you seem to have defined an event algebra, where events can be composed. I am not sure how applicable this is to other domains. If your language is abstract and not related to particulars of flight simulators, it might be quite useful...<p>What is the language called? How proprietary is it?
What makes it work well on a distributed system?<p>The value of such an approach lives and dies on how well-defined the problem space is. If the domain covered by those events is relatively walled-off and has a very clear protocol for interacting with the rest of the system, that's good. But if it turns out to require lots of special cases, you end up wanting (and probably hacking your way to get at) a general-purpose language and can end up with something more complicated.<p>Event propagation in response to unpredictable signals from hardware is pretty much what GUI logic consists of. GUI event handling written the obvious way quickly generates into spaghetti under complexity. I've often wondered about a better way, since much of that complexity doesn't feel intrinsic.<p>I don't know much about games but it seems like a lot of them might be in the sweet spot for this approach, with a lot of complexity that can be expressed using such rules and encapsulated in a way that works nicely with the rest of the program. The devil is in the details, though.
I'd call it dataflow. It's also akin to what Excel does when solving a system. In a larger sense, you'd call it declarative (instead of imperative) programming - you're defining the system and an engine figures out how to make the system act like the definition - you're not giving step-by-step instructions.
It's called functional reactive programming. For example you can say:<p><pre><code> box.position = delay(1,mouse.position)
</code></pre>
And the box follows the mouse with a 1 second delay. It works by having a data type for time varying values.
That sounds like the software equivalent of a hardware description language, like VHDL or Verilog. I think that's also the model that LabView works on, but they have a graphical editor instead of a textual syntax.
In SICP, I think they use this approach to simulate digital circuits. <a href="http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4" rel="nofollow">http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html...</a>
The a = b + c examples looks like <a href="http://en.wikipedia.org/wiki/Constraint_programming" rel="nofollow">http://en.wikipedia.org/wiki/Constraint_programming</a> .
It sounds kinda like binding in JavaFX.<p><a href="http://java.sun.com/javafx/1/tutorials/core/dataBinding/" rel="nofollow">http://java.sun.com/javafx/1/tutorials/core/dataBinding/</a>
Another name that this goes by is Reactive programming. Some amount of work was done on a haskell reactive programming project called Yampa or Functional Reactive Programming.
Looks like a dataflow approach to me, or perhaps a message passing system (actor model).<p>The application I'm working on at the moment for my future startup makes heavy use of a similar approach to pipeline computations between components. So far it works very well.
First thing that came to mind was Smalltalk.
<a href="http://en.wikipedia.org/wiki/Smalltalk" rel="nofollow">http://en.wikipedia.org/wiki/Smalltalk</a>.
Developed in the 80s but have no idea where it went.
.