https://futureofcoding.org/ logo
Join Slack
Powered by
Nice intro to behavioral programming: <http://www....
# thinking-together
s
k
Minor tangent: is this first figure really just filler, or does it have any content I should be trying to parse?
Ugh, the "blocked events" terminology is going to be confusing/misleading to a large fraction of readers..
@shalabh I'd never heard of this concept before but it seems to have legs. Any other good articles to read?
From the above link:
...current methods for dealing with programming the dynamics of reactivity, however powerful and convenient, suffer from the same woes: We sit in front of a screen and write (or draw) programs that prescribe the behavior for each of the relevant parts of the system over time. Then we must check/test/verify that the combined behavior of all the parts satisfies a separately specified set of requirements or constraints.
...
There is no need for separate specifications for the operational tasks and the requirements thereof. Anything that falls inside the total sum of what has been played-in will be a legal behavior of the system.
I'm still wrapping my head around this vision, but I think it's ignoring the essential complexity of programming. On a fundamental level programmers deal with non-linear building blocks; interactions between constraints can be hard to imagine ahead of time. How would you gain confidence that you've "played-in" a project sufficiently to work out possible constraints? Admittedly we have trouble doing this with existing systems. But surely we need to pay more attention to constraints, not less. Representing actions physically makes it more difficult to survey all actions entered so far, the scenarios they apply in, etc. Check/test/verify is the fundamental, irreducible core of programming. Trying to eliminate it is a fool's errand. So I'm probably misunderstanding something here.
Another phrasing: LSC (which is the original Behavioral Programming system) introduces the notion of "play-in" to describe scenarios and how the system should react to them. So there'll be a natural tendency for the number of scenarios and handlers to grow. It's unclear to me how the opposite dynamic of generalizing scenarios happens. How does the system encourage noticing that two scenarios are special cases of a single one and may be coalesced? How does the programmer/user replace two played-in scenarios with a single new one? Without supporting this countervailing operation, the whole system will descend into monotonically complexifying spaghetti.
s
I'm new to behavioral programming myself - seems like a paradigm that's been around on the sidelines. Here's a video: https://vimeo.com/298554103. I do get the feeling that "there's something here". Directly expressing something like 'whenever X happens and then Y happens then Z should happen' seems very useful. This seems like emergent behavior that we desire, but have to decompose and encode lower level code in different locations (e.g. X, Y and Z may be at happening at different objects). We then encode the higher level behavior in some integration test. I haven't seen a BP language, but would be interesting to see. I can only find BP frameworks in Java etc. A native BP language/system might be able to identify/coalesce similar behaviors? I don't see how BP lets you ignore constraints? OTOH it seems you'll be trying to identify useful constraints so you can encode them as behaviors.
k
Yeah, in OP the shall/may/must not lists of events at sync points seem like a pretty nice way to represent constraints. I wonder how that reconciles with the "Liberating" paper I was reacting to above.
Open in Slack
PreviousNext
Powered by