Functional Reactive Programming

Stephen Blackheath

• Publisher: Manning
• Year: 2016
• Print ISBN: 9781633430105
• eBook ISBN: 9781638353416
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

Summary Functional Reactive Programming teaches the concepts and applications of FRP. It offers a careful walk-through of core FRP operations and introduces the concepts and techniques you'll need to use FRP in any language.Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. About the Technology Today's software is shifting to more asynchronous, event-based solutions. For decades, the Observer pattern has been the go-to event infrastructure, but it is known to be bug-prone. Functional reactive programming (FRP) replaces Observer, radically improving the quality of event-based code. About the Book Functional Reactive Programming teaches you how FRP works and how to use it. You'll begin by gaining an understanding of what FRP is and why it's so powerful. Then, you'll work through greenfield and legacy code as you learn to apply FRP to practical use cases. You'll find examples in this book from many application domains using both Java and JavaScript. When you're finished, you'll be able to use the FRP approach in the systems you build and spend less time fixing problems. What's Inside

• Think differently about data and events
• FRP techniques for Java and JavaScript
• Eliminate Observer one listener at a time
• Explore Sodium, RxJS, and Kefir.js FRP systems

About the Reader Readers need intermediate Java or JavaScript skills. No experience with functional programming or FRP required. About the Authors Stephen Blackheath and Anthony Jones are experienced software developers and the creators of the Sodium FRP library for multiple languages. Foreword by Heinrich Apfelmus. Illustrated by Duncan Hill. Table of Contents

• Stop listening!
• Core FRP
• Some everyday widget stuff
• Writing a real application
• New concepts
• FRP on the web
• Switch
• Operational primitives
• Continuous time
• Battle of the paradigms
• Programming in the real world
• Helpers and patterns
• Refactoring
• Adding FRP to existing projects
• Future directions

Chapter 1. Stop listening!

This chapter covers

• What FRP is
• What events are, and how they cause trouble
• What FRP is for: the problem we’re trying to solve
• The benefits of FRP
• How an FRP system works
• A different way of thinking that underlies FRP

Welcome to our book! We love functional reactive programming (FRP). Many people like the idea too, yet they aren’t entirely clear what FRP is and what it will do for them. The short answer: it comes in the form of a simple library in a standard programming language, and it replaces listeners (also known as callbacks) in the widely used observer pattern, making your code cleaner, clearer, more robust, and more maintainable—in a word, simpler.

It’s more than this: FRP is a very different way of doing things. It will improve your code and transform your thinking for the better. Yet it’s surprisingly compatible with the usual ways of writing code, so it’s easy to factor into existing projects in stages. This book is about the concepts of FRP as they apply to a range of FRP systems and programming languages.

FRP is based on ideas from functional programming, but this book doesn’t assume any prior knowledge of functional programming. Chapter 1 will lay down some underlying concepts, and in chapter 2 we’ll get into the coding. So stop listening, and start reacting!

1.1. Project, meet complexity wall

It seemed to be going so well. The features weren’t all there yet, but development was swift. The boss was happy, the customers were impressed, the investors were optimistic. The future was bright.

It came out of nowhere ... Software quality crumbled. The speed of development went from treacle to molasses. Before long, there were unhappy customers and late nights. What happened?

Sooner or later, many big projects hit the complexity wall. The complexities in the program that seemed acceptable compound exponentially: At first you hardly notice, and then—BAM! It hits broadside. The project will then typically go one of four ways:

• It’s shelved.
• It’s rewritten from scratch, and a million dollars later, it hits the same wall again.
• The company staffs up. As the team expands, its productivity shambles off into the realm of the eternal quagmire. (Often the company has been acquired around this time.)
• It undergoes major refactoring, leading eventually to maintainable code.

Refactoring is the only way forward. It’s your primary tool to save a project that has hit the wall, but it’s best used earlier, as part of a development methodology, to prevent disaster before it happens.

But this book isn’t about refactoring. It’s about functional reactive programming (FRP), a programming style that works well with refactoring because it can prevent or repair out-of-control complexity. FRP isn’t a methodology, and—apologies if you bought this book under false pretenses—it won’t solve all of your problems. FRP is a specific programming technique to improve your code in an area that just happens to be a common source of complexity (and therefore bugs): event propagation.

Simple things taking too long

I joined a team that was developing a Java-based configuration tool for an embedded system. The software was difficult to modify to the point where a request for adding a check box to one of the screens was estimated as a two-week job.

This was caused by having to plumb the Boolean value through layers of interfaces and abstraction. To solve this, we put together what we’d later discover was a basic FRP system. Adding a check box was reduced to a one-line change.

We learned that every piece of logic, every listener, and every edge case you need to write code for is a potential source of bugs.

1.2. What is functional reactive programming?

FRP can be viewed from different angles:

• It’s a replacement for the widely used observer pattern, also known as listeners or callbacks.
• It’s a composable, modular way to code event-driven logic.
• It’s a different way of thinking: the program is expressed as a reaction to its inputs, or as a flow of data.
• It brings order to the management of program state.
• It’s something fundamental: we think that anyone who tries to solve the problems in the observer pattern will eventually invent FRP.
• It’s normally implemented as a lightweight software library in a standard programming language.
• It can be seen as a complete embedded language for stateful logic.

If you’re familiar with the idea of a domain-specific language (DSL), then you can understand FRP as a minimal complete DSL for stateful logic. Aside from the I/O parts, an arbitrarily complex video game (for example) can be written completely in FRP. That’s how powerful and expressive it is. Yet it isn’t all-or-nothing—FRP can be easily introduced into an existing project to any extent you like.

1.2.1. A stricter definition

Conal Elliott is one of the inventors of FRP, and this book is about FRP by his definition. We’ll call this true FRP as a shorthand. What is and isn’t FRP? Here’s part of Elliott’s reply to a Stack Overflow post, “Specification for a Functional Reactive Programming language” (http://mng.bz/c42s):

I’m glad you’re starting by asking about a specification rather than implementation first. There are a lot of ideas floating around about what FRP is. For me it’s always been two things: (a) denotative and (b) temporally continuous. Many folks drop both of these properties and identify FRP with various implementation notions, all of which are beside the point in my perspective.

By “denotative,” I mean founded on a precise, simple, implementation-independent, compositional semantics that exactly specifies the meaning of each type and building block. The compositional nature of the semantics then determines the meaning of all type-correct combinations of the building blocks.

A true FRP system has to be specified using denotational semantics.

Definition

Denotational semantics is a mathematical expression of the formal meaning of a programming language. For an FRP system, it provides both a formal specification of the system and a proof that the important property of compositionality ...

Table of contents

• Copyright
• Brief Table of Contents
• Table of Contents
• Foreword
• Preface
• Acknowledgments
• About this Book
• About the Cover
• Chapter 1. Stop listening!
• Chapter 2. Core FRP
• Chapter 3. Some everyday widget stuff
• Chapter 4. Writing a real application
• Chapter 5. New concepts
• Chapter 6. FRP on the web
• Chapter 7. Switch
• Chapter 8. Operational primitives
• Chapter 9. Continuous time
• Chapter 10. Battle of the paradigms
• Chapter 11. Programming in the real world
• Chapter 12. Helpers and patterns
• Chapter 13. Refactoring
• Chapter 14. Adding FRP to existing projects
• Chapter 15. Future directions
• Appendix A. Sodium API
• Appendix B. The six plagues of event handling
• Appendix C. Comparison of FRP systems
• Appendix D. A section for managers
• Appendix E. Denotational semantics of Sodium
• Index
• List of Figures
• List of Tables
• List of Listings