I don't really agree that in Haskell when it comes to simulation a program "just is". That is the idealized story.
At least when writing your own simulation engine, in practice you have to deal with operational details such as future unknown values that can block computations; to much laziness can cause hickups in the framerate since unobserved computations build up over time (a bit like sum does) which is why most Yampa simulations I've seen mark all the outputs deep strict (so even the end user needs to know about the operational details); binding to the head of signals and signal recursion causes space and time leaks, and that's why Yampa doesn't provide first signals, which in turn gives problems with inefficiency regarding too much redundant evaluation, etc...
Wolfgang Jeltsch is working on a PhD thesis for Grapefruit in which I hope all problems with FRP will be nicely documented, since currently there doesn't seem to be clear literature that tells the whole story with pros/cons of each framework.
And of course Conal Elliot's blog outlines some of the problems and beauties of his latest FRP system (Reactive)
So it's not all sunshine and roses, but that's also what makes it interesting :)
When I was using C and Python, I used to think of most applications in an
simulation way. I think it's right to say that programs are simulations.
But now I have to change my mind in Haskell, I have to think in a data-flow
way, that is: data in, processing using function composition, data out.
no state and so no before and after. And no flow, since
time is just an ilusion of users. In Haskell, a program
just "is".
Sorry, could not resist the Jedi talk...
Hope you like the language. Best,
Maurício