Prezi is an online presentation creation tool that runs in the browser and on mobile platforms. In the talk below, Peter Halacsy, co-founder and CTO of Prezi, discusses functional reactive programming, and explains why Prezi is committed to investing and growing FRP.
A mouse click is just a mouse click, but in Prezi it could be a zoom command, a selection command or any other command depending on the state of the application. Peter shared a post-mortem document written by Prezi engineers describing a bug relating to inconsistent state. He describes how embarrassing it was to discover one particular bug which could have been avoided using functional programming.
According to a document published by Adobe in 2006:
33% of code is in event listeners
50% of the bugs are coming from that code
90% of the interaction designers concerns are covered by this code
First, we had the idea of MVVC, similar to Knockout.js. Unfortunately, this doesn’t scale; you tightly connect the model and view which is automagic but not the solution.
Peter read a paper in 2012 “Deprecating the Observer Pattern,” which connects the view and the model (albiet in the wrong direction.) When he saw Scala.React, they thought “This is the solution for all of our problems! We can use declarative programming to write the rules of interaction!”
How nice would it be if we didn’t need engineers? Designers can define the interactions, because they’re the ones who care about how it should work, and then it should just work. That’s declarative programming. It won’t work in the next 20 years, but this is a good dream.
After Scala.React, something else happened. Peter was an ex-functional programmer. Peter now likes type checkers and type safety. One guy took four Python open source libraries, took a type checker and pointed out that only one of those four projects didn’t have any type errors; he found 17 bugs in 6,000 lines in a library with high-coverage unit tests. Why not use type checkers if they work?
Here’s a silly code sample to illustrate how type checking is important:
Everybody knows not to do this, but what are the consequences? One of Prezi’s very few outages was caused by a programmer forgetting to add the return to the else branch. It would be great if the compiler could find these mistakes.
Compilers make large scale creativity possible. We like craftsmanship. We care about high quality and practice pays back. We should avoid repetitive, manual work. We don’t need to spend all our time writing unit tests if we can catch more errors with the compiler. You need tools and systems to design complicated projects.
Cache invalidation is hard. In a growing company, you would like to build a microservice-oriented architecture, and it’s difficult to synchronize these distributed systems. Reactive programming can help solve this automatic synchronization issue for you.
“We all are writing future legacy code. If your code won’t be legacy, it’s useless.”
Introduction to Elm