The following is a dead comment by seanmcdirmid... reposting since it seems perfectly legitimate and I have no idea why this would be voted down. (Glitch?)
Debugging is one of the problems with FRP/signals, or functional code in general. No one has come up with a good dataflow debugger yet, and it might not even be viable. The best you can do is interpose "probes" on your code like you would take measurements with an oscilloscope. Disclosure: I did my dissertation on signals (object-oriented ones to be precise), and am a bit disillusioned with it.
On the other hand, the argument from the declarative community is that you don't need to debug your code.
A better alternative to FRP/signals might be immediate mode user interfaces. Since they are conceptually called on every frame, you get the benefits of FRP while still being able to debug in the old way. On the other hand, they are quite inefficient, though I think we could play some tricks with technology to make them better (memoize, refresh blocks of computations only as needed via dependency tracing).
Debugging is one of the problems with FRP/signals, or functional code in general. No one has come up with a good dataflow debugger yet, and it might not even be viable. The best you can do is interpose "probes" on your code like you would take measurements with an oscilloscope. Disclosure: I did my dissertation on signals (object-oriented ones to be precise), and am a bit disillusioned with it.
On the other hand, the argument from the declarative community is that you don't need to debug your code.
A better alternative to FRP/signals might be immediate mode user interfaces. Since they are conceptually called on every frame, you get the benefits of FRP while still being able to debug in the old way. On the other hand, they are quite inefficient, though I think we could play some tricks with technology to make them better (memoize, refresh blocks of computations only as needed via dependency tracing).