Functional Reactive Programming with Frappuccino

LoneStarRuby Conf 2013

Steve Klabnik

@steveklabnik

#functional-programming

#reactive-programming

#rubygems

#shoes-rb

#live-coding

Functional Reactive Programming with Frappuccino

by Steve Klabnik

In this video, titled "Functional Reactive Programming with Frappuccino," Steve Klabnik discusses the concepts surrounding the programming paradigm of Functional Reactive Programming (FRP) within the context of Ruby, particularly through his Ruby gem called Frappuccino. The talk, delivered at the LoneStarRuby Conf 2013, highlights the importance of creativity and risk-taking in programming, contrasting the notion of 'Irresponsible Ruby' with standard practices in software development.

Key Points:
- Introduction to Frappuccino: Klabnik explains that his talk centers around the Ruby gem Frappuccino, which is inspired by functional and reactive programming principles.
- Irresponsible Ruby Concept: The idea of 'Irresponsible Ruby' embodies coding that is creative and exploratory, lacking the constraints typically seen in production code, such as unit tests.
- Cultural Reflection in Programming: Klabnik emphasizes the human aspects of programming, discouraging the celebrity culture that sometimes surrounds well-known programmers. He stresses the importance of acknowledging struggles in coding rather than presenting a façade of perfection.
- The Influence of Why the Lucky Stiff: He reflects on the legacy of Why the Lucky Stiff, a pivotal figure in the Ruby community, and stresses the creative freedom he embraced in coding, encouraging developers to take risks.
- Functional Reactive Programming (FRP): Klabnik describes FRP as a paradigm that elegantly combines functional programming with reactive programming, enabling real-time data manipulation through first-class functions, akin to how Excel manages data. He illustrates this with an example of how changing one variable automatically updates another, showcasing its potential within Ruby.
- Demonstration of Frappuccino: During his talk, Klabnik live codes examples using Frappuccino, demonstrating how it can streamline the development of interactive applications in Ruby, thus making programming more enjoyable.
- Concluding Thoughts: Klabnik encourages attendees to embrace a playful and experimental approach to coding, urging them to take risks and enjoy the process. He concludes with a call to action for developers to create whimsical and innovative Ruby applications, celebrating the joy of coding.

Overall, this talk serves as an insightful exploration of balancing creative coding with responsible practices and how concepts from functional programming can enhance the Ruby ecosystem.

00:00:15.360 Hi everybody, I'm Steve. Apparently a little feedbacky—sorry.

00:00:21.199 This is a talk called Functional Reactive Programming with Frappuccino. For those of you who were in the room a minute ago, I wrote a Ruby gem called Frappuccino.

00:00:26.560 To get a little meta, I'm going to talk about what I'm going to talk about. Essentially, the gem is actually at the end; so this talk is largely not about Frappuccino, but it also is at the same time.

00:00:37.920 First of all, as was just mentioned, I teach classes with Jumpstart Lab. We do the best Ruby and Rails training in the world, so if you'd like your team to level up, please give us a call. It's the only reason I can be here; it's the only reason I can do all the open source work that I do.

00:00:43.360 Jumpstart is super awesome. Jeff's a great guy. This conference is really special to me. I missed it last year, but it's sacred because this is actually the first Ruby conference I ever spoke at, way back in the day when I was first starting.

00:01:01.680 Adam Sokolowski and Wynn Netherland found out I was going to be speaking at RubyConf in the fall, and they said, "Hey Steve, we want to come speak at our conference, so do that first." So I came and spoke about Shoes a very long time ago. This conference will always be very special to me, so thank you for having me here. It's great to be back on the stage again. This is important, so thanks!

00:01:19.600 Now let's discuss the actual meta of what I'm going to talk about. This talk is nominally about a Ruby gem called Frappuccino. However, there's a bunch of stuff that I realized while building this Ruby gem, and this talk is actually more about the implications of what this Ruby gem means to me and what it should mean to you, even if you haven't heard of this gem or probably installed it at all.

00:01:56.320 Frappuccino was born out of this thing where I like to joke that Aaron Patterson wrote a gist, and I turned it into this life philosophy called "Irresponsible Ruby". Today, we will talk about responsible and irresponsible coding in the context of Ruby programming and discuss what all of this means.

00:02:08.239 One of the biggest points I want to make is that this talk is a little interesting, a little weird, and a little off-putting. The uncomfortable thing about me being here on stage while you listen is that when we give presentations at conferences, you tend to see the end result of months of work. For example, imagine how much effort Sandy put into the keynote this morning. You see the wonderful, perfect code that came out of the frustration, debugging, and hard work that went into it.

00:02:46.640 Whenever you see your favorite programmers speak on stage, it can create a celebrity culture where they appear perfect, even though we are very much not. Before Aaron Patterson was a friend of mine, I thought he was untouchable because he was amazing. Now, we're all just people, and I really don't want us to continue this celebrity culture as programmers.

00:03:02.400 I was pair-programming remotely with someone when Avdi did the "pair with me" hashtag thing. If you haven't seen that, remote pair programming is a thing! I was working with someone on a rescue issue where we wrote a test that kept failing. They apologized and thought it might be boring for me, but I told them, "My code doesn't work most of the time!" It's crucial that we respect each other's struggles in programming.

00:03:42.720 This talk will be a little off, a little weird, a little unpolished. I will be live-coding in two different versions of Ruby. You might notice that this presentation software is a bit odd. This is actually Rabbit, which is used in a lot of Japanese Ruby presentations. You can see the slide numbers at the bottom and then the tortoise moves according to how long the talk is, which indicates where we will end up.

00:04:31.360 All of this is a little unfinished on purpose because I want to present that casual side of coding instead of the typical perfectionism. It's Friday and the end of the day, so why should we be serious about it? Now, let's talk about what I mean by "Irresponsible Ruby." To be brief, it is code that you would not deploy at your day job because it is too interesting or creative.

00:05:19.039 I've devised four or maybe five criteria that define what I mean by this. Irresponsible Ruby is primarily composed of neat hacks, weird metaprogramming, unusual techniques, and absolutely no unit tests whatsoever. I specify unit tests here purposely. While we will discuss acceptance tests and integration tests, when I say unit tests, I refer to test-driven development (TDD), which guides code design.

00:06:14.479 When in an irresponsible mode, integration or acceptance tests can be useful to ensure you didn't break functionality. But TDD guides development along a certain path, and I don't want that. So that's the crux of what I mean by Irresponsible Ruby. The person who most embodies Irresponsible Ruby is this man—raise your hand if you're on your first Rails job. I hate raising hands during talks, but I'm doing it here!

00:06:56.879 So here’s an experiment: for those who've been around for a while, do you know who this guy is? That's awesome! It's amazing, yet kind of sad too, because this is a man named Why the Lucky Stiff, a very influential member of the Ruby community who decided to commit 'info suicide.' Many within the Ruby community might not know what happened to him, but the Ruby world has grown and so many newcomers could be unaware.

00:08:02.960 I’ve been joking that I’ll need to stop talking about Why soon because I’m encountering more and more new people who won’t know what I’m discussing. For those of you who raised your hands, Why is often defined as an artist whose medium was software, developing fascinating, complex, and irresponsible Ruby code before leaving the community. One reason I’m up on this stage today is that I felt Why's projects were too important to let die.

00:09:35.680 When I say I took over a lot of his projects—Hackety and Shoes were mentioned earlier—we’ll discuss Shoes later—when you inherit a project from an absent creator who was irresponsible, maintaining it can be extraordinarily difficult. This talk has parallels with Brian's earlier talk about code quality. Mine can be seen as an 'anti-code quality' talk in a way.

00:10:48.960 It’s challenging to maintain creative projects for the future. Some time after Why disappeared, someone published a blog post called "A Letter from Why." They realized that Why had been gone for a while and shared their experience of having previously emailed him and received a remarkable response. I’ll share with you the most important part of what Why said.

00:12:38.640 This person emailed Why, saying, "I love your work! How can I become an amazing programmer like you?" What did Why say? "I do not write tests for my code; I do not write very many comments; I change styles very frequently; and most of all, I shun the predominant styles of coding, as that goes against the very essence of experimentation. In short, all I do is muck around." He expressed admiration for programmers who take risks and aren't afraid to write dangerous or 'crappy' code.

00:14:00.640 If you worry too much about being clean and tidy, you can't push boundaries to find greater possibilities. This encapsulates Why's personality quite well. At the bottom of that blog post, there’s a Disqus thread, and I, as someone who maintains Why's code these days, wrote this: "please write some tests!".

00:15:34.080 To illustrate the effort I had to invest in Hackety and Shoes, I recently purchased a new MacBook coinciding with the release of Snow Leopard. For those who recall the Mac OS history, Snow Leopard was the first release where Apple deprecated the carbon framework they used for transitioning from Mac OS 9 to 10. Unfortunately, Why wrote his software using the carbon framework, and he left before porting them to Cocoa.

00:16:56.880 Consequently, I encountered a six-month struggle before I could even compile the Shoes project on my machine. That was the Mac side of things; the Windows side was even more ridiculous. Why had originally coded Shoes for Windows XP, but Windows Vista was released in the interim.

00:17:48.880 As many of you know, Windows Vista was notoriously problematic. I experienced frustration, attempting to port the application to various Windows versions, leading to numerous issues when teaching programming concepts to students who faced program crashes. Thus, we needed to transition away from Ruby 1.9.1.

00:18:48.000 So, for those who have been following Shoes' development, I've been quiet for a while, but now we are completely rewriting it in JRuby. It is almost functional and kind of ongoing already, and I'm about to show you some functionalities with it.

00:19:08.240 To provide a brief overview of the Shoes functionality, to create an application, we would initiate it with 'shoes.app do end.' This basic code would yield a window with that application. You can add elements such as buttons easily, enabling straightforward initialization and functionality design.

00:20:36.160 The point is to utilize Ruby's blocks effectively, making programming simple and enjoyable. For example, you can create buttons where interactions trigger blocks, showcasing how user interactivity can be incorporated into your designs.

00:22:14.640 Now I’ll move on to Functional Reactive Programming (FRP). Does anyone here know what FRP is? Awesome! So FRP is a compelling programming paradigm that emerged from Conal Elliott's graduate work. It combines aspects of functional programming and reactive programming. Essentially, functional programming emphasizes functions as first-class concepts, while reactive programming focuses on data flows as first-class concepts.

00:23:55.680 The unique idea behind FRP is to utilize first-class functions to manage data flows, much like how you might think of linking columns in an Excel spreadsheet. When you change inputs in Excel, outputs are updated automatically. In the case of FRP, if variable A is set to five and variable B is defined as 'A + 6,' any changes to A will automatically update B.

00:24:50.360 This introduces a new way of thinking about programming, and presents opportunities for dynamic data manipulation in real-time. By integrating these concepts into Ruby, we facilitate new forms of interaction and responsiveness to user inputs, enhancing user experience.

00:26:56.480 After becoming familiar with FRP through my JavaScript exploration, I was intrigued by its potential in Ruby. My journey began at a conference where Philip showcased bacon.js, a library dedicated to functional reactive programming for UI elements.

00:28:51.519 Inspired by his talk, I quickly dove into crafting a Ruby gem that mirrored bacon.js's functionality, ultimately leading to the development of Frappuccino. This originated from a desire to bring FRP to our Ruby ecosystem, allowing for more expressive UI designs.

00:30:27.600 The complexity of Frappuccino’s design arises from its foundation in multiple prestigious programming languages and paradigms, intertwining the influences from Haskell and Elm into a single Ruby implementation.

00:32:23.840 In order to understand Frappuccino fully, we explore its main constructs, which reflect functional programming's principles while integrating FRP’s reactive characteristics. Aside from the simplicity it promotes in UI interaction, it leverages the power of functional programming principles for event management and state handling.

00:34:02.560 By employing an approach that ties events directly to user interaction, Frappuccino streamlines the process of building interactive applications in Ruby, allowing you to express your application’s logic more naturally and efficiently.

00:35:28.320 To demonstrate this, I will implement a basic application using Frappuccino showcasing the interactive incrementing and decrementing of a counter with user buttons, illustrating the seamless integration of functional programming in a Ruby context.

00:36:56.160 Through this practical example, we will witness Frappuccino's efficacy in building responsive applications while maintaining readable and manageable code, focused explicitly on what we wish to accomplish with each interaction.

00:38:44.480 Thus, Frappuccino’s introduction into the Ruby ecosystem opens up a new realm of possibilities for both developers and aspiring programmers, illustrating the journey from experimenting with the idea of irresponsible coding to fostering creative explorative programming.

00:40:02.240 In conclusion, I'd like to encourage all of you to embrace the idea of being irresponsible! Engage with creativity, take risks in your coding practices, and develop innovative solutions within Ruby. The emphasis should be on having fun while coding.

00:41:17.680 Thank you again for being here, and I look forward to seeing more whimsical and ingenious Ruby creations from each of you. Let’s not lose the joy of coding! Thank you, everyone!

LoneStarRuby Conf 2013