xvi
Introduction
Right now, we as programmers are at an impasse—a transition period between the well-understood
world of imperative programming, and a world that is increasingly at odds with this model. In the ’80s,
everything was simple: one machine, one thread, no network.
CPUs are now scaling horizontally, adding more and more cores, instead of scaling the CPU speeds.
Network and disk performance are now increasingly requiring asynchronous I/O in order to build high-
performance solutions.
Our tools to write asynchronous code, however, haven’t kept up with the rest of the world—threads,
locks, and events are the assembly language of asynchronous programming. They are straightforward to
understand, but as the complexity of the application becomes larger, it becomes extremely difficult to
determine if a given block of code will run correctly with respect to the rest of the application.
We need a way to retain the asynchronous nature of modern applications, while also retaining the
deterministic nature of traditional imperative programming.
A compelling solution to these problems is functional reactive programming. This term sounds
academic and overwhelming, however, if you’ve ever written a formula in Excel, good news—you’ve
already done functional reactive programming.
Let’s go through that title piece by piece, starting with the word “functional.” Many people have a
definition of functional programming, often from their college computer science course that covered
Scheme or Common Lisp, usually something along the lines of, “it means never using variables.”
Instead, think of FP as a mindset: “How is the output of my program related to my input, and how
can I describe that relation in code?” In this book, we’ll examine Language Integrated Queries (LINQ), a
powerful technology that allows us to describe a result list based on an input list and a set of
transformations on that input.
The disadvantage to LINQ is that this technology only works on lists, not data that is incoming or
changing. However, there is a type of list that is hiding in plain sight, only disguised—events. Consider
the KeyUp event: for every key that the user presses, an object representing the key will be generated—
“H”–“e”–“l”–“l”–“o”.
What if we thought of an event as a list? What if we could apply everything we know about lists to
events, like how to filter them or create new lists based on existing lists?
Reactive Extensions allow you to treat asynchronous sources of information, such as events, and
reason about them in the same way that you currently can reason about lists. This means, that once you
become proficient with using LINQ to write single-threaded programs, you can apply your knowledge
and write similar programs that are completely asynchronous.
A warning: this book is not easy to understand on first grasp. Rx will stretch your brain in ways it’s
not used to stretching, and you, like the authors, will almost certainly hit a learning curve.
The results, however, are most definitely worth it, as programs that would be incredibly difficult to write
correctly otherwise, are trivially easy to write and reason with Reactive Extensions.
www.allitebooks.com
