Haskell Weekly

>> hello and welcome to the Haskell Weekly podcast as you might have guessed this show is about Haskell a purely functional programming language I'm your host Dustin Segers a software engineer here at IT Pro TV

>> and I'm Jose Silvestri an intern at ITProTV

>> today we'll be talking about functional reactive programming I guess we should go ahead and set expectations here gonna be just doing a general overview right

>> yeah and as I understand that there's a lot of debate about what counts as FRP I was like coming from the camp of Conal just sort of wanting to go back to the pure definition of very concretely defined denotational semantics of what FRP is what a constitutes of so we're mostly going to focus on that because I just thought it would be an interesting starting point just for exploration of this topic given that historically it's sort of the starting point of as far as I understand it

>> okay Jose so what do we mean by FRP or functional reactive programming just doing a brief dive myself I saw stuff about behaviors and events could you explain more about that

>> when we have a problem where our program is constantly interacting with its environment

>> mm-hmm

>> obviously to a certain extent our outside world is continuous and usually the values that we want to deal with evolve continuously over time so we want a way to be able to handle that in a way that semantically reflects the continuous nature of these values but since we are working in a computer that's discrete eventually we do need to discretize this problem but the advent of FRP is that you delay the discretization in favor of modularity and composability and having a more concrete and rigorous way of speaking about our problem it's sort of taking your problem wholemeal you are looking at the dynamics of your problem and then you discretize the advantage of this that first of all you're not making assumptions about the behavior right away

>> okay

>> for example an example it's given quite a bit it's the difference between bitmaps and vector graphics

>> mm-hmm

>> with bitmaps you're already committing yourself to a certain resolution a certain behavior with vector graphics your logic itself is continuous it's very composable and then you discretize because it must eventually go through the discrete interface that is your screen

>> gotcha okay so I guess that brings me to my next question which is you know what can functional reactive programming what types of problems can it solve like why do we even care about it right and it seems to me like you mentioned graphics and I saw some stuff during my brief look up that you know it's great for animations and graphics and you like click events in game programming and stuff like that

>> yeah it definitely is and it was sort of I believe the conception of FRP came from Conal Elliott listening to a talk and it was to talk on functional animation and someone after the talk suggests that they noticed that the values were sort of a function from the natural numbers to your domain of the domain of the problem they suggest that why not have these things be a function from the real numbers to this and that's sort of to avoid all the nasty interpolation that has to go on if you're working in a discrete domain

>> gotcha

>> and just like with our vector graphics example it's doing what that does for the space domain to the time domain and that helps with things like animation so let's say I want to slow in or slow out I can do that because I'm not making any premature assumptions about what's going to happen over time

>> okay

>> it sort of we're not throwing away any information preemptively and an FRP that has interesting consequence of always having access to your past and that leads to for example being able to write functions that accumulate the events that have happened before

>> okay so maybe handling state

>> yeah exactly for example let's say I have an event that invokes a function that counts that that's a count every time someone comes into the room something like that okay I can then use an accumulator function to see how many people entered the room over all

>> right

>> and so on same thing with clicks for example let's say I'm just clicking around just that would be a very simple program that you know you click around for a bit and then afterwards you accumulate how many clicks happen that is interesting consequence is that I would encourage the listeners to go it will probably leave a link to it but it's something called FRP Zoo and it has an example of how various FRP libraries handle that problem of counting clicks

>> gotcha

>> because it turns out to be somewhat non predictable in certain libraries of it sound interesting

>> yeah so it sounds like you're examples either a fire marshal or a click game programmer would have a great time with FRP sure but so I guess so what what makes FRP interesting to you like why why FRP versus you know other paradigms

>> well it's it's very the two fundamental properties of it that make it very interesting for me for example with continuous time we have the advantage of composability for reasons we'll get into when we get more into the semantics part of it but as it turns out the central abstraction of FRP

>> mm-hm

>> which are behaviors they are semantically the same thing as functions so it's interesting to have a way of thinking of our problem in terms of continuous values in a way that's that allows us to leverage what's already in our language and having functions as first-class citizens arguably really to do this that is a prerequisite of it that you have functions that's a first-class citizen it's sort of working with the very nature of functional programming and this I feel like things like state machines and so on our we're sort of working against our nature it was when working in Haskell essentially and another reason is that when you have when you represent time as a continuous thing in your program you have infinitesimally small both theoretically infinitesimally small points so problems like that these two things happen at the same time are a bit easier to answer because they just both point to that same infinitesimal point

>> okay >>and so if that allows us to reconcile signals that have different sample rates for example if I have something that happens every other day and something that's happening every second I don't need to do any sort of complicated you know thinking to figure out when these two things happen at the same time

>> I see okay so simplifies things a little bit in that regard then

>> yeah exactly

>> actually a lot a bit yeah

>> and and to go back to composability the reason we would why composability would be a bit more difficult if we were to discretize prematurely is that error builds up

>> ah yes

>> so a product composing approximations is sounds like a headache to me personally so I would rather work with an abstraction that behaves like functions because a little secret they are and that's what makes is really interesting to me it's just it just feels like an extension of what we're already working with

>> oh nice all right well since we we covered what FRP can solve we covered what makes it interesting to you is there anything else you would like to add or should we move on to examples of FRP in the wild

>> oh yeah we can move on to some examples up I would like to maybe go over the semantics of FFP a little bit be

>> sure yeah

>> so I'd mentioned behaviors and behaviors are the central abstraction and FRP behaviors for percent values that evolve continuously over time they're sort of the way we represent the dynamics of what we're dealing with and then we have a secondary abstraction which are events they represent discrete events that

>> yeah it might have like a mouse click or whatever else have you

>> yeah exactly and so the second abstraction the secondary abstraction and FRP at least in this instance of FRP the more classic one because in a lot of more modern sort of implementations of it events are not necessarily secondary and at times they becomes a primary subject of discussion but we're not dealing with that here mostly because FRP is a very large zoo and

>> okay yeah

>> and there's a lot of discussion around that that I myself I'm still wrapping my head around and this is also an encouragement for listeners for discussion you know if you're and read it please tell me all the things I messed up but because I'm learning just as much as anyone else

>> yeah well I mean I think we're all constantly learning but yeah yeah

>> I just would really love to hear about this it's always some very spicy discussion go ahead so our secondary abstraction events we can really just think of them as an infinite list of pairs of time values and it's sort of like our discreet sampling of our time and it becomes an infinite list of pairs of time and our event value and you know so that could be what position was the mouse and at this point in time and then becomes an event and then a then over time that becomes a list of pairs of a mouse position

>> so that seems like a pretty powerful thing actually like yeah think about like um but that seems incredibly handy

>> yeah for sure and the fact that these things for example events they it it derives functor and applicate if we obviously have things like fmap that have very interesting meanings to our to FRP for example if there's a an extension of fmap apply for that takes in a behavior that contains some sort of functionality in it and an event a and when this event happens at that time it will modify the event into another one that it's sort of like mapping that dynamics of this behavior on to an event in changing the how this event behaves

>> okay

>> it serve like an application of dynamics and that seems really powerful to me that's just one of the reasons this fascinates me so much the fact that we can talk about composing dynamics and applying dynamics to events also the ability to think of your problem as flows of things is very interesting to me because sort of that analogy of flowing seems to work very well like for example when I'm filtering a behavior that just seems to me like literally filtering a flow of things

>> get you yeah yeah yeah yeah

>> it's just semantically very very interesting

>> mm-hmm

>> the semantics being so clearly defined and having just a very expressive way of talking about these things is helpful to me personally it just clicks with me quite a bit Oh

>> expressiveness that's very helpful

>> yeah exactly and also a lot of the talks I've seen reference why that you know that paper why functional programming matters because it seems to be that a lot of the stuff in that paper why functional programming matters really translates into why FRP matters and that's going back to really to me this being sort of an extension of what we expect from a pure functional language

>> ok cool Jose seems like we've been covering the specifications of FRP so what what about the implementation of FRP or have you seen any in the wild recently that kind of catch your attention

>> yeah one of the main complaints that I've seen thrown out by the person who sort of came because I came up with the concept of FRP at least in this version of it he doesn't feel like there's any accurate implementations of FRP in the world though there are some that get very close and I'm sure I think I believe he's mentioned that sodium I believe has some very accurate one but the one that's

>> like sodium is in like a S O D I U M cool

>> so the implementation that's caught my eye the most has been there spent two reactive banana Yampa but Yampa I would rather not get into because that's arrow eyes FRP

>> that's the that was used in a Quake clone I think

>> yeah right it is very exciting yeah yeah I wish I could talk about it but that would take a while and I I have not explored it enough to be able to talk about it yes over-reactive banana is fairly close to the specification we just described and it's also very well documented and has a few tutorials and a really cool wiki page with some funny fake testimonials that I would encourage everyone listening to look at yeah reactive banana implements you know the behavior abstraction the event abstraction and it has most of the things you would you would see in the specification which we will link a talk in some slides by Conal specified the specification of like like the actual API specification

>> gotcha

>> that would take a bit of talking because it's symbolic so it's kind of awkward to

>> 15 minutes

>> yeah so yeah reactive banana is a really good one a it has a really funny tutorial which is implementing the world's worst synthesizer there's been quite a bit of success with FRP and music and sound programming

>> that's that's really cool

>> pretty interesting

>> if you haven't guessed already I'm completely a game nerd too so

>> yeah so this just very good stuff for most people actually

>> awesome well any other FRP implementations out in the wild that you can think of

>> a net wired looked interesting to me but I believe that once deprecated but it's another arrow iced one but I believe I mentioned this earlier there is the there is a repository called FRP zoo which allows you to explore oh the at least the most popular FRP libraries out there and it has a way of testing out how they behave by that click example I'm accumulating clicks and so on

>> gotcha okay and we'll probably link that in in with this podcast I'm along with several other links

>> yeah and there is a strange loop talk by the creator of elm I guess back in back when Elm started it was a first order FRP implementation and he goes over the various categories of FRP and that's a very good way to get started churning out and to the zoo of FRP

>> yeah nice

>> all right I would also like to mention that I by no means I'm an expert in this and this very much an exploratory discussion there's just something that was very interesting to me and I thought hey it'd be a cool topic to just get people talking about it because it I I think this topic warrants a lot more exploration there certainly is but I like to make more people wear it in case they were not

>> sure yeah like like me I was not aware about FRP until just recently yeah yeah and I have learned a lot just from talking to with you today

>> it's just a really fascinating thing and yeah any any knowledge that anyone might have out there I am very open to it is

>> constantly learning you're not learning what are you doing it could

>> have a little bit less dumb every day

>> my wife might claim them that's a huge challenge but yeah

>> i believe in you dustin

>> all right well thanks for being on the show with me today Jose

>> well thank you this was really fun

>> and I'd like to thank our audience for listening to the Haskell Weekly podcast if you liked what you heard find out more at our website haslellweekly.news also please rate and review us on iTunes it helps a lot haskell weekly is brought to you by IT Pro TV the tech skills development platform for IT professionals and they also happen to be our employer so yeah send your sys admins and network admins to www.itpro.tv for all of their learning needs thanks again for listening we'll see you again next week see ya