The Esterel Language Primer: A Language for Reactive Systems (1999) [pdf]
home.ku.edu.tr
home.ku.edu.tr
The debate on the relative merits of various programming styles will continue, of course, but Esterel is an example that may contradict some notions that are a result of some fashions.
Also, this categorization from Chapter 1 is interesting:
Computerized systems can be divided into three broad categories:
* Transformational systems compute output values from inputs values, and then stop. Most numerical computation programs, payroll programs, and compilers are transformational.
* Interactive systems constantly interact with their environment in such a way that the computers can be viewed as the masters of the interaction. A user calls for services, the system listens to him when it can, and it delivers the services when they are available. Operating systems, centralized or distributed databases, and the Internet are interactive.
* Reactive systems, also called reflex systems, continuously react to stimuli coming from their environment by sending back other stimuli. Contrarily to interactive systems, reactive systems are purely input-driven and they must react at a pace that is dictated by the environment. Process controllers or signal processors are typical reactive systems.
Esterel targets a low-level embedded domain where FSMs are sufficient and hard determinism is necessary. You might want to check out Francisco Sant’Anna's research [2], which is in a similar direction to Esterel but with Lua influences (same group in Brazil that does Lua, I think).
[1] http://research.microsoft.com/en-us/people/smcdirm/managedti...
http://www.ceu-lang.org/chico/ceu_rebls14_pre.pdf
Here is the connection to Esterel:
> In contrast, the imperative style of Esterel is confined to the domain of real-time embedded control systems. As a matter of fact, imperative reactivity is now often associated to the observer pattern, typical in object-oriented systems, because it heavily relies on side effects [20, 25]. However, short-lived callbacks (i.e., the observers) eliminate any vestige of structured programming, such as support for long-lasting loops and automatic variables [3], which are elementary capabilities of imperative languages. In this sense, callbacks actually disrupt imperative reactivity, becoming "our generation’s goto" [13, 15].
> We believe that the full range of reactive applications can benefit from the imperative style of Esterel, which we now refer to as Structured Reactive Programming (SRP). SRP extends the classical hierarchical control constructs of Structured Programming (SP) (i.e., concatenation, selection, and repetition [14]) to support continuous interaction with the environment.
The way I see it, I think there are two approaches to solving problems. The first tries to see what tools we have available, tries to figure out what we can build, and then hopes the result is useful. The second looks at what we actually need, and sees if we can use anything at our disposal to get us closer to our goal. In many respects, PFP is the result of the first approach. We know how to verify PFP, right? Well, at least within the confines of first-order logic. So let's hope that's useful enough. Not that this kind of research isn't important, but I see it as searching under the (academic) lamppost, rather than research directed at providing the industry with what it actually needs.
While Roberto's team in Brazil is more pragmatic, FP people like SPJ also care about producing useful artifacts. I would be worried if all PL research was oriented around FP, but it isn't :)
Best of luck with your world domination plans.