Lambda the Ultimate

As I am oft to mention, Rodney Brooks' behavior oriented programming also supports blending via prioritized reflex-like behaviors, this was successfully used in Kodu.

It is difficult to cite the 3D engine stuff because their feature sets aren't well published. We really tried in the déjà vu paper but didn't get very far.

What little I've read has been really valuable - the subsumption architecture helped to orient my thinking a lot. I'm sure the robotics folks are just shaking their heads when graphics folks like me talk about the "state of the art."

Yes, Kodu (and YinYang) are more examples of systems that I would say "get it" with respect to prioritization/layering being needed for simple composition/concurrency. My sense is that this whole family of techniques scale to large programs much more easily than the nominaly more "pure" and composable FRP.

I agree that it is basically impossible to comprehend (much less cite) the state of the art in the space of commercial game tools. The main thing I'd argue for is setting the bar appropriately. I should actually give InterState much more credit for focusing on the GUI/IDE and live editing experience.

What would be a good starting point to learn more about Brooks's work? Also is there something beyond the fact that Kodu is a rules-based system that lends itself to composition? It almost sounds like there's some sort of mechanism for explicit prioritization/layering?

The paper that I was thinking of in particular was "A Robust Layered Control System for a Mobile Robot" (link). There are of course many more recent papers on Brooks' publications page, but a lot of it builds on the same fundamental approach of the subsumption architecture.

On Kodu, see The Design of Kodu: A Tiny Visual Programming Language for Children on the Xbox 360. Section 3.6 talks about the prioritization scheme (rules higher in the list take priority over others), and points out the inspiration this takes from Brooks.

The point, I'd claim, is that there are lots of different kinds of composition we might define, and the model for composition will in turn influence the kinds of components we can express. The point of the subsumption architecture is that while pure "wiring" (at which FRP excels) might technically be a fully general compositional model, it tends to break down in cases where layering excels.

Edit: as another example, the more procedural-imperative "script" model in something like Scratch naturally excels at expressing sequential composition ("do A then B").

Edit Again: Poking around Brooks' page, I'm also really enjoying the Behavior Language User's Guide.

Kodu programs are expressed as rules, each rule has a priority based on its position in a rule sheet. When two rules require the same actuator (say movement), the lowest priority rule yields and it's later clauses aren't evaluated (the clauses before the actuator remain executing). So a low priority "patrol" behavior yields when a higher priority "pursue" behavior becomes active.

This is quite powerful and allows one to easily build robot actors with fairly sophisticated emergent behaviors. Composability comes from this resource-based implicit coordination, which appears to be appropriate for robotics and robot-like domains (say video games).

Sounds a lot like how cellular processes (transduction, etc) take place in the body. Tuple spaces could be related as well if you modeled the behaviors as data, but they didn't take off as far as I can tell.

It seems like there's a number of people starting to look into emergent behavior (or self-assembling) systems in industry. This netflix post, as an example, talks about using a self-assembling pipeline to do their playback system.

We're sort of at the beginning of trying to understand how composition will work in our case (rules-based temporal logic language on top of a database), but increasingly I'm convinced it'll look something like this stuff. Sean, I know you went down this road with yinyang - any insights?

Brooks' work is very biological inspired. You can read about my similar design in the "coding at the speed of touch paper," but it's quite OO. I can't seem to come up with a design of the paradigm that works beyond robotics/games; it might not be general, which is why I'm currently working with Glitch/managed time to auto coordinate. Behaviors can then be implemented on top of glitch, which uses priorities anyways in breaking conflicts. Tuple spaces are first come first served, I think, which isn't good enough in this case (low priority behaviors must yield to higher priority ones).

broken for me as well.

There might be an embargo until the conference (October), but you could also contact the authors to see if you can get access.