I posted this as an example of a language designed for verifiable correctness, predictable performance and a reactive design, and yet is completely imperative and full of side-effects. It is simply a demonstration that the pure-FP style is required (or even directly related) neither to verifiable correctness nor to reactive programming.
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.
My own research [1] goes in this direction: there is a lot to be said for control flow and spooky actions at a distance (I could never get the expressiveness I needed out of FRP). There is no one true paradigm.
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).
> 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.
It's so refreshing to read something like that after we've been hit over the head with "pure-FP is the only right way to program" for some time.
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.
I agree somewhat but maybe you are being a bit harsh on the PFP crowd: it was only 10 years ago where FP research was considered quite niche! Now the tables are reversed in that object people are now rebels and FP people are now the establishment, crazy. I think we are all searching for what are right answers, just that we are looking under different lampposts.
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 :)
Hmm? No, the editor is all written in Glitch. Jonathan helped me write up the ideas and coined the term "managed time." We are also plotting world domination with new programming experience ideas (Athens, here I come!).
I don't know it felt like sibling user interfaces somehow, but it's been a long time since I saw subtext1 presentation (http://imgur.com/uTXVg1V), reading Edwards' name probably caused bias.
I remember being greatly confused Esterel it in college. Teachers didn't use 'Reactive' so I never thought about it that way, nor if it already had explored what the mainstream is rediscovering nowadays (Rx).
Rx is not very comparable to Esterel, which is more about event-oriented programming than the classical meaning of "reactive" (today reactive somehow is taken to mean data flow but...that wasn't the case in the 80s).
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.