I'm starting a thread so that other folks jump into this parallel discussion universe, rather than spilling out into the main timeline.

It's worth searching for the word "Nose" on that page, because he has a bunch of papers published in the proceedings of the I can't believe this is a thing International Symposium on Olfaction and Electronic Nose.

Interested in hearing your thoughts about it, @Ivan Reese

experimenting with Notable for note taking while reading

I got the strong sense that this programming model does not scale well, and thus you need to lean on checkers and validators and other such sufficiently smart compilers to avoid writing code that deadlocks or has unintended consequences.

It seems like a major design goal is to allow program behaviour to be specified incrementally, with something like a dialogue taking place between the programmer and their program. Musing on this characteristic of their design was absolutely my favourite part of reading the article. I can easily imagine how their approach would work really well for early prototyping and exploring a behaviour space. I could see this being used in game dev to great effect, for scripting "AI" routines or PCG systems. This is probably going to be what I take away from BP, more than all the stuff in the middle about implementation hoops they had to jump through, or various attempts they made to get over some of the apparent shortcomings in the design.

They gave some examples and alluded to uses in industrial process control, including an example of individually controlling the motors in a quadcopter and a mention of controlling valves, pumps, etc. I cringed at these examples — Behavioral Programming seems well suited for discrete, digital "on/off" control in non-realtime use cases. Flying a quadcopter, or doing industrial process control, are cases where you typically want tight bounds on execution time, control over determinism, and semantics that allow for things like PID. The example of "Motors shouldn't have a speed below zero — if an event is going to reduce the speed below zero, block it" seems like far too blunt an instrument for these use cases.

Sure, you could probably have a subsystem that performs PID, and then orchestrate it and other subsystems using BP, but that wasn't the tack taken by the article.

I'm going to read the paper on BP for animation, since animation is an area of specialization for me and I'm really quite curious to see how the hell they square these circles.

Also, their Java implementation is called BPJ, which stands for "Peanut Butter Jelly" as far as I'm aware. At least, that's how I read it every time I saw the acronym.