Chapter 9. Nondeterminism by need

 

This chapter is the most abstract part of this book, and it is not required for initial understanding of the later chapters. You are welcome to skip ahead to chapter 10, as long as you promise to come back here at a later time.

In chapter 3, we introduced functional programming as one of the tools of the Reactive trade. The second part of this book has up to this point been concerned with splitting a problem into encapsulated modules that interact only via asynchronous message passing, an act that is fundamentally impure: sending a message to an external object implies that the state change of that other object cannot be modeled within the sender. It is necessarily a side effect. That is not incidental; it is the sole reason to compartmentalize.[1]

1Tracking the sending of a message as an effect can of course be done, but the gain is small. It would have to be done in close proximity to the place it originates, and the modules in our hierarchical decomposition are intended to be small.

It seems at first sight that the design we have chosen is fundamentally at odds with one of the core paradigms that we advertise. But this contradiction is not real, as you will see now, during a journey that could be titled “The Gradual Expulsion from Paradise.”

9.1. Logic programming and declarative data flow

9.2. Functional reactive programming

9.3. Sharing nothing simplifies concurrency

9.4. Shared-state concurrency

9.5. So, what should we do?

9.6. Summary