title: What's the status of current Functional Reactive Programming implementations?
body: <p>I'm trying to visualize some simple automatic physical systems (such things as pendulum, robot arms,etc.) in Haskell.
  Often those systems can be described by equations like</p>
  
  <p><code>df/dt = c*f(t) + u(t)</code></p>
  
  <p>where <code>u(t)</code> represents some kind of 'intelligent control'. Those systems look to fit very nicely in the Functional Reactive Programming paradigm.</p>
  
  <p>So I grabbed the book "The Haskell School of Expression" by Paul Hudak,
  and found that the domain specific language "FAL" (for Functional Animation Language) presented there actually works quite pleasently for my simple toy systems (although some functions, notably <code>integrate</code>, seemed to be  a bit too lazy for an efficient use, but easily fixable).</p>
  
  <p>My question is, what's the more mature, up-to-date, well-maintained, performance-tuned alternative for more advanced, or even practical applications today?</p>
  
  <p><a href="http://www.haskell.org/haskellwiki/Functional_Reactive_Programming">This wiki page</a> lists several options for Haskell, but I'm not clear about the following respects:</p>
  
  <ol>
  <li><p>The status of "reactive", the project from Conal Eliott who is (as I understand it) one of the inventers of this programming paradigm, looks a bit stale. I love his code, but maybe I should try other more up-to-date alternatives? What's the primary difference between them, in terms of syntax/performance/runtime-stability?</p></li>
  <li><p>To quote from a <a href="http://www.cs.rit.edu/~eca7215/frp-independent-study/Survey.pdf">survey</a> in 2011, Section 6, "<em>... FRP implementations are still not efficient enough or predictable enough in performance to be used effectively in domains which require latency guarantees ...</em>". Alghough the survey suggests some interesting possible optimizations, given the fact that FRP is there for more than 15 years, I get the impression that this performance problem might be something <em>very</em> or even inherently difficult to solve at least within a few years. Is this true?</p></li>
  <li><p>The same author of the survey talks about "time leaks" in his <a href="http://blog.edwardamsden.com/2011/03/demonstrating-time-leak-in-arrowized.html">blog</a>. Is the problem unique to FRP, or something we are generally having when programming in a pure, non-strict language? Have you ever found it just too difficult to stabilize an FRP-based system over time, if not performant enough?</p></li>
  <li><p>Is this still a research level project? Are the people like plant engineers, robotics engineers, financial engineers, etc. actually using them (in whaterver language that suits their needs)?</p></li>
  </ol>
  
  <p>Although I personally prefer a Haskell implementation, I'm open to other suggestions. For example, it would be particularly fun to have an Erlang implementation --- it would then be very easy to have an intelligent, adaptive, self-learning server process!</p>