
The Esterel Language Primer: A Language for Reactive Systems (1999) [pdf] - pron
http://home.ku.edu.tr/~stasiran/ecoe560/Papers/EsterelPrimerBerry.pdf
======
pron
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._

~~~
seanmcdirmid
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).

[1] [http://research.microsoft.com/en-
us/people/smcdirm/managedti...](http://research.microsoft.com/en-
us/people/smcdirm/managedtime.aspx)

[2] [http://ceu-lang.org/](http://ceu-lang.org/)

~~~
vanderZwan
I was about to post Ceu, had a lot of fun messing around with it. It's quite
surprising how easily the paradigm "clicked", actually.

~~~
seanmcdirmid
I found their REBLS workshop paper:

[http://www.ceu-lang.org/chico/ceu_rebls14_pre.pdf](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.

~~~
pron
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.

~~~
seanmcdirmid
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 :)

------
agumonkey
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).

~~~
seanmcdirmid
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).

