These are chat archives for jdubray/sam

Nov 2018
Paolo Furini
Nov 07 2018 09:03
You’re right indeed.. in a perfect world one should be free to choose the right tools that best fit the problem domain, not the way round
Re FP one of the worst thing that can happen is force it in domains where it causes more harm than good, and I fear that’s precisely your case 😓
Paolo Furini
Nov 07 2018 09:11
But for GC it depends on the implementation. For example with erlang or Elixir (my favorite FP language) there’s no cost at all, thanks to the way the underlying VM is built. But for “second thought” FP languages like the ones that run on the JVM, well.. yes that could be a real issue
Fred Daoud
Nov 07 2018 13:35

This article discusses the idea of behavioral programming, the main lure being that you can alter the behavior of a program without modifying the code inside components.

It seems to be an event-driven approach, which I have tried in a fairly large application and found that it leads to difficult-to-follow code as events are triggered, altered, and handled in disparate parts. This is supposed to be an advantage, but in practice becomes unwieldy and hard to reason about (in my opinion.)

I think that the goals achieved in the article, namely emitting events and being able to block and alter events to assemble the behavior of an application, are more easily reached with SAM; the equivalents being presenting proposals, accepting/refusing, and next-action.

What do you think?