WEBVTT

1
00:00:01.310 --> 00:00:05.730
>> hello and welcome to the Haskell Weekly

2
00:00:03.750 --> 00:00:07.529
podcast as you might have guessed this

3
00:00:05.730 --> 00:00:08.910
show is about Haskell a purely

4
00:00:07.529 --> 00:00:11.490
functional programming language

5
00:00:08.910 --> 00:00:14.160
I'm your host Dustin Segers a software

6
00:00:11.490 --> 00:00:16.560
engineer here at IT Pro TV
>> and I'm

7
00:00:14.160 --> 00:00:18.779
Jose Silvestri an intern at ITProTV

8
00:00:16.560 --> 00:00:21.330
>> today we'll be talking about functional

9
00:00:18.779 --> 00:00:23.730
reactive programming I guess we should

10
00:00:21.330 --> 00:00:25.439
go ahead and set expectations here gonna

11
00:00:23.730 --> 00:00:29.130
be just doing a general overview right

12
00:00:25.439 --> 00:00:32.430
>> yeah and as I understand that there's a

13
00:00:29.130 --> 00:00:35.489
lot of debate about what counts as FRP I

14
00:00:32.430 --> 00:00:38.219
was like coming from the camp of Conal

15
00:00:35.489 --> 00:00:42.239
just sort of wanting to go back to the

16
00:00:38.219 --> 00:00:45.320
pure definition of very concretely

17
00:00:42.239 --> 00:00:48.629
defined denotational semantics of what

18
00:00:45.320 --> 00:00:50.519
FRP is what a constitutes of so we're

19
00:00:48.629 --> 00:00:52.469
mostly going to focus on that because I

20
00:00:50.519 --> 00:00:54.840
just thought it would be an interesting

21
00:00:52.469 --> 00:00:56.820
starting point just for exploration of

22
00:00:54.840 --> 00:00:59.370
this topic given that historically it's

23
00:00:56.820 --> 00:01:02.969
sort of the starting point of as far as

24
00:00:59.370 --> 00:01:06.510
I understand it
>> okay Jose so what do we

25
00:01:02.969 --> 00:01:09.600
mean by FRP or functional reactive

26
00:01:06.510 --> 00:01:12.720
programming just doing a brief dive

27
00:01:09.600 --> 00:01:15.360
myself I saw stuff about behaviors and

28
00:01:12.720 --> 00:01:18.420
events could you explain more about that

29
00:01:15.360 --> 00:01:20.400
>> when we have a problem where our program

30
00:01:18.420 --> 00:01:22.860
is constantly interacting with its

31
00:01:20.400 --> 00:01:24.960
environment
>> mm-hmm
>> obviously to a

32
00:01:22.860 --> 00:01:28.980
certain extent our outside world is

33
00:01:24.960 --> 00:01:31.620
continuous and usually the values that

34
00:01:28.980 --> 00:01:36.690
we want to deal with evolve continuously

35
00:01:31.620 --> 00:01:40.470
over time so we want a way to be able to

36
00:01:36.690 --> 00:01:43.740
handle that in a way that semantically

37
00:01:40.470 --> 00:01:47.310
reflects the continuous nature of these

38
00:01:43.740 --> 00:01:50.040
values but since we are working in a

39
00:01:47.310 --> 00:01:52.410
computer that's discrete eventually we

40
00:01:50.040 --> 00:01:55.950
do need to discretize this problem but

41
00:01:52.410 --> 00:01:59.250
the advent of FRP is that you delay the

42
00:01:55.950 --> 00:02:00.600
discretization in favor of modularity

43
00:01:59.250 --> 00:02:05.490
and composability

44
00:02:00.600 --> 00:02:08.399
and having a more concrete and rigorous

45
00:02:05.490 --> 00:02:10.829
way of speaking about our problem it's

46
00:02:08.399 --> 00:02:13.680
sort of taking your problem wholemeal

47
00:02:10.829 --> 00:02:14.880
you are looking at the dynamics of your

48
00:02:13.680 --> 00:02:18.570
problem

49
00:02:14.880 --> 00:02:21.060
and then you discretize the advantage of

50
00:02:18.570 --> 00:02:23.160
this that first of all you're not making

51
00:02:21.060 --> 00:02:26.730
assumptions about the behavior right

52
00:02:23.160 --> 00:02:29.640
away
>> okay
>> for example an example it's

53
00:02:26.730 --> 00:02:32.520
given quite a bit it's the difference

54
00:02:29.640 --> 00:02:34.500
between bitmaps and vector graphics

55
00:02:32.520 --> 00:02:35.850
>> mm-hmm
>> with bitmaps you're already

56
00:02:34.500 --> 00:02:38.730
committing yourself to a certain

57
00:02:35.850 --> 00:02:42.270
resolution a certain behavior with

58
00:02:38.730 --> 00:02:43.470
vector graphics your logic itself is

59
00:02:42.270 --> 00:02:46.200
continuous

60
00:02:43.470 --> 00:02:48.600
it's very composable and then you

61
00:02:46.200 --> 00:02:50.820
discretize because it must eventually go

62
00:02:48.600 --> 00:02:52.800
through the discrete interface that is

63
00:02:50.820 --> 00:02:56.700
your screen
>> gotcha

64
00:02:52.800 --> 00:03:00.180
okay so I guess that brings me to my

65
00:02:56.700 --> 00:03:02.370
next question which is you know what can

66
00:03:00.180 --> 00:03:04.350
functional reactive programming what

67
00:03:02.370 --> 00:03:06.960
types of problems can it solve like why

68
00:03:04.350 --> 00:03:08.880
do we even care about it right and it

69
00:03:06.960 --> 00:03:11.510
seems to me like you mentioned graphics

70
00:03:08.880 --> 00:03:14.190
and I saw some stuff during my brief

71
00:03:11.510 --> 00:03:17.130
look up that you know it's great for

72
00:03:14.190 --> 00:03:20.190
animations and graphics and you like

73
00:03:17.130 --> 00:03:22.050
click events in game programming and

74
00:03:20.190 --> 00:03:25.620
stuff like that
>> yeah it definitely is

75
00:03:22.050 --> 00:03:28.080
and it was sort of I believe the

76
00:03:25.620 --> 00:03:32.400
conception of FRP came from

77
00:03:28.080 --> 00:03:34.880
Conal Elliott listening to a talk and it

78
00:03:32.400 --> 00:03:37.140
was to talk on functional animation and

79
00:03:34.880 --> 00:03:39.660
someone after the talk suggests that

80
00:03:37.140 --> 00:03:42.120
they noticed that the values were sort

81
00:03:39.660 --> 00:03:46.500
of a function from the natural numbers

82
00:03:42.120 --> 00:03:48.780
to your domain of the domain of the

83
00:03:46.500 --> 00:03:51.330
problem they suggest that why not have

84
00:03:48.780 --> 00:03:54.570
these things be a function from the real

85
00:03:51.330 --> 00:03:58.380
numbers to this and that's sort of to

86
00:03:54.570 --> 00:04:01.290
avoid all the nasty interpolation that

87
00:03:58.380 --> 00:04:03.810
has to go on if you're working in a

88
00:04:01.290 --> 00:04:06.330
discrete domain
>> gotcha

89
00:04:03.810 --> 00:04:09.060
>> and just like with our vector graphics

90
00:04:06.330 --> 00:04:12.000
example it's doing what that does for

91
00:04:09.060 --> 00:04:15.780
the space domain to the time domain and

92
00:04:12.000 --> 00:04:18.540
that helps with things like animation so

93
00:04:15.780 --> 00:04:21.410
let's say I want to slow in or slow out

94
00:04:18.540 --> 00:04:24.600
I can do that because I'm not making any

95
00:04:21.410 --> 00:04:26.550
premature assumptions about what's going

96
00:04:24.600 --> 00:04:29.580
to happen over time
>> okay

97
00:04:26.550 --> 00:04:33.419
>> it sort of we're not throwing away any

98
00:04:29.580 --> 00:04:35.610
information preemptively and an FRP that

99
00:04:33.419 --> 00:04:37.470
has interesting consequence of always

100
00:04:35.610 --> 00:04:41.190
having access to your past and that

101
00:04:37.470 --> 00:04:43.289
leads to for example being able to write

102
00:04:41.190 --> 00:04:46.460
functions that accumulate the events

103
00:04:43.289 --> 00:04:50.130
that have happened before
>> okay so maybe

104
00:04:46.460 --> 00:04:53.759
handling state
>> yeah exactly

105
00:04:50.130 --> 00:04:58.020
for example let's say I have an event

106
00:04:53.759 --> 00:05:00.389
that invokes a function that counts that

107
00:04:58.020 --> 00:05:02.610
that's a count every time someone comes

108
00:05:00.389 --> 00:05:04.889
into the room something like that okay I

109
00:05:02.610 --> 00:05:06.780
can then use an accumulator function to

110
00:05:04.889 --> 00:05:09.180
see how many people entered the room

111
00:05:06.780 --> 00:05:10.919
over all
>> right
>> and so on

112
00:05:09.180 --> 00:05:12.240
same thing with clicks for

113
00:05:10.919 --> 00:05:14.250
example let's say I'm just clicking

114
00:05:12.240 --> 00:05:16.229
around just that would be a very simple

115
00:05:14.250 --> 00:05:17.970
program that you know you click around

116
00:05:16.229 --> 00:05:20.490
for a bit and then afterwards you

117
00:05:17.970 --> 00:05:25.110
accumulate how many clicks happen

118
00:05:20.490 --> 00:05:29.250
that is interesting consequence is that

119
00:05:25.110 --> 00:05:31.380
I would encourage the listeners to go it

120
00:05:29.250 --> 00:05:33.630
will probably leave a link to it but

121
00:05:31.380 --> 00:05:37.380
it's something called FRP Zoo and it has

122
00:05:33.630 --> 00:05:40.440
an example of how various FRP libraries

123
00:05:37.380 --> 00:05:42.979
handle that problem of counting clicks

124
00:05:40.440 --> 00:05:46.759
>> gotcha
>> because it turns out to be

125
00:05:42.979 --> 00:05:51.110
somewhat non predictable in certain

126
00:05:46.759 --> 00:05:54.900
libraries of it sound interesting

127
00:05:51.110 --> 00:05:57.659
>> yeah so it sounds like you're examples

128
00:05:54.900 --> 00:05:59.310
either a fire marshal or a click game

129
00:05:57.659 --> 00:06:05.639
programmer would have a great time with

130
00:05:59.310 --> 00:06:08.940
FRP sure but so I guess so what what

131
00:06:05.639 --> 00:06:12.680
makes FRP interesting to you like why

132
00:06:08.940 --> 00:06:18.780
why FRP versus you know other paradigms

133
00:06:12.680 --> 00:06:21.690
>> well it's it's very

134
00:06:18.780 --> 00:06:23.310
the two fundamental properties of it

135
00:06:21.690 --> 00:06:27.060
that make it very interesting for me for

136
00:06:23.310 --> 00:06:28.860
example with continuous time we have the

137
00:06:27.060 --> 00:06:30.930
advantage of composability for reasons

138
00:06:28.860 --> 00:06:33.380
we'll get into when we get more into the

139
00:06:30.930 --> 00:06:40.200
semantics part of it but as it turns out

140
00:06:33.380 --> 00:06:44.840
the central abstraction of FRP
>> mm-hm

141
00:06:40.200 --> 00:06:47.130
>> which are behaviors they are

142
00:06:44.840 --> 00:06:51.750
semantically the same thing as functions

143
00:06:47.130 --> 00:06:55.400
so it's interesting to have a way

144
00:06:51.750 --> 00:06:59.130
of thinking of our problem in terms of

145
00:06:55.400 --> 00:07:01.200
continuous values in a way that's that

146
00:06:59.130 --> 00:07:03.150
allows us to leverage what's already in

147
00:07:01.200 --> 00:07:07.620
our language and having functions as

148
00:07:03.150 --> 00:07:10.320
first-class citizens arguably really to

149
00:07:07.620 --> 00:07:11.910
do this that is a prerequisite of it

150
00:07:10.320 --> 00:07:14.340
that you have functions that's a

151
00:07:11.910 --> 00:07:16.470
first-class citizen it's sort

152
00:07:14.340 --> 00:07:20.010
of working with the very nature of

153
00:07:16.470 --> 00:07:22.770
functional programming and this I feel

154
00:07:20.010 --> 00:07:25.650
like things like state machines and so

155
00:07:22.770 --> 00:07:28.640
on our we're sort of working against our

156
00:07:25.650 --> 00:07:32.900
nature it was when working in Haskell

157
00:07:28.640 --> 00:07:37.950
essentially and another reason is that

158
00:07:32.900 --> 00:07:42.360
when you have when you represent time as

159
00:07:37.950 --> 00:07:45.330
a continuous thing in your program you

160
00:07:42.360 --> 00:07:47.360
have infinitesimally small both

161
00:07:45.330 --> 00:07:51.419
theoretically infinitesimally small

162
00:07:47.360 --> 00:07:54.660
points so problems like that these two

163
00:07:51.419 --> 00:07:56.610
things happen at the same time are a bit

164
00:07:54.660 --> 00:07:58.430
easier to answer because they

165
00:07:56.610 --> 00:08:02.490
just both point to that same

166
00:07:58.430 --> 00:08:05.520
infinitesimal point
>> okay
>>and so if that

167
00:08:02.490 --> 00:08:07.620
allows us to reconcile signals that have

168
00:08:05.520 --> 00:08:10.680
different sample rates for example if I

169
00:08:07.620 --> 00:08:12.540
have something that happens every other

170
00:08:10.680 --> 00:08:14.990
day and something that's happening every

171
00:08:12.540 --> 00:08:18.570
second I don't need to do any sort of

172
00:08:14.990 --> 00:08:22.140
complicated you know thinking to figure

173
00:08:18.570 --> 00:08:25.169
out when these two things happen at the

174
00:08:22.140 --> 00:08:26.970
same time
>> I see okay so simplifies

175
00:08:25.169 --> 00:08:29.130
things a little bit in that regard then

176
00:08:26.970 --> 00:08:32.310
>> yeah exactly
>> actually a lot a bit yeah

177
00:08:29.130 --> 00:08:35.930
>> and and to go back

178
00:08:32.310 --> 00:08:38.279
to composability the reason we would why

179
00:08:35.930 --> 00:08:40.050
composability would be a bit more

180
00:08:38.279 --> 00:08:44.250
difficult if we were to discretize

181
00:08:40.050 --> 00:08:48.480
prematurely is that error builds up
>> ah yes

182
00:08:44.250 --> 00:08:51.020
>> so a product composing approximations is

183
00:08:48.480 --> 00:08:54.570
sounds like a headache to me personally

184
00:08:51.020 --> 00:08:57.540
so I would rather work with an

185
00:08:54.570 --> 00:09:05.310
abstraction that behaves like functions

186
00:08:57.540 --> 00:09:06.600
because a little secret they are and that's what

187
00:09:05.310 --> 00:09:10.050
makes is really interesting to me it's

188
00:09:06.600 --> 00:09:13.890
just it just feels like an extension of

189
00:09:10.050 --> 00:09:17.279
what we're already working with
>> oh nice

190
00:09:13.890 --> 00:09:21.360
all right well since we we covered what

191
00:09:17.279 --> 00:09:23.670
FRP can solve we covered what makes it

192
00:09:21.360 --> 00:09:26.339
interesting to you is there anything

193
00:09:23.670 --> 00:09:30.240
else you would like to add or should we

194
00:09:26.339 --> 00:09:33.390
move on to examples of FRP in the wild

195
00:09:30.240 --> 00:09:37.140
>> oh yeah we can move on to some examples

196
00:09:33.390 --> 00:09:39.000
up I would like to maybe go over the

197
00:09:37.140 --> 00:09:43.710
semantics of FFP a little bit be
>> sure

198
00:09:39.000 --> 00:09:46.380
yeah
>> so I'd mentioned behaviors and

199
00:09:43.710 --> 00:09:50.370
behaviors are the central abstraction

200
00:09:46.380 --> 00:09:52.380
and FRP behaviors for percent values

201
00:09:50.370 --> 00:09:56.460
that evolve continuously over time

202
00:09:52.380 --> 00:09:58.140
they're sort of the way we represent the

203
00:09:56.460 --> 00:10:02.880
dynamics of what we're dealing with

204
00:09:58.140 --> 00:10:05.580
and then we have a secondary abstraction

205
00:10:02.880 --> 00:10:07.740
which are events they represent discrete

206
00:10:05.580 --> 00:10:10.170
events that
>> yeah it might have like a

207
00:10:07.740 --> 00:10:13.560
mouse click or whatever else have you

208
00:10:10.170 --> 00:10:15.420
>> yeah exactly and so the second

209
00:10:13.560 --> 00:10:20.880
abstraction the secondary abstraction

210
00:10:15.420 --> 00:10:23.339
and FRP at least in this instance of FRP

211
00:10:20.880 --> 00:10:26.070
the more classic one because in a lot of

212
00:10:23.339 --> 00:10:29.010
more modern sort of implementations of

213
00:10:26.070 --> 00:10:30.800
it events are not necessarily secondary

214
00:10:29.010 --> 00:10:33.900
and at times they becomes a primary

215
00:10:30.800 --> 00:10:36.740
subject of discussion but we're not

216
00:10:33.900 --> 00:10:40.050
dealing with that here mostly because

217
00:10:36.740 --> 00:10:43.920
FRP is a very large zoo and

218
00:10:40.050 --> 00:10:46.439
>> okay yeah
>> and there's a lot of

219
00:10:43.920 --> 00:10:49.259
discussion around that that I myself I'm

220
00:10:46.439 --> 00:10:52.589
still wrapping my head around and this

221
00:10:49.259 --> 00:10:55.410
is also an encouragement for listeners

222
00:10:52.589 --> 00:10:58.290
for discussion you know if you're and

223
00:10:55.410 --> 00:11:00.989
read it please tell me all the things I

224
00:10:58.290 --> 00:11:03.600
messed up but because I'm learning just

225
00:11:00.989 --> 00:11:05.160
as much as anyone else
>> yeah well I mean

226
00:11:03.600 --> 00:11:07.529
I think we're all constantly learning

227
00:11:05.160 --> 00:11:10.379
but yeah yeah
>> I just would really love

228
00:11:07.529 --> 00:11:17.040
to hear about this it's always some very

229
00:11:10.379 --> 00:11:19.619
spicy discussion go ahead so our

230
00:11:17.040 --> 00:11:22.170
secondary abstraction events we can

231
00:11:19.619 --> 00:11:26.519
really just think of them as an infinite

232
00:11:22.170 --> 00:11:28.379
list of pairs of time values and it's

233
00:11:26.519 --> 00:11:31.019
sort of like our discreet sampling of

234
00:11:28.379 --> 00:11:35.929
our time and it becomes an infinite list

235
00:11:31.019 --> 00:11:39.660
of pairs of time and our event value and

236
00:11:35.929 --> 00:11:41.610
you know so that could be what position

237
00:11:39.660 --> 00:11:44.629
was the mouse and at this point in time

238
00:11:41.610 --> 00:11:48.389
and then becomes an event and then a

239
00:11:44.629 --> 00:11:53.490
then over time that becomes a list of

240
00:11:48.389 --> 00:11:56.309
pairs of a mouse position
>> so that seems

241
00:11:53.490 --> 00:11:59.999
like a pretty powerful thing actually

242
00:11:56.309 --> 00:12:03.089
like yeah think about like um but that

243
00:11:59.999 --> 00:12:06.089
seems incredibly handy
>> yeah for sure and

244
00:12:03.089 --> 00:12:08.970
the fact that these things for example

245
00:12:06.089 --> 00:12:10.350
events they it it derives functor and

246
00:12:08.970 --> 00:12:12.749
applicate if we obviously have things

247
00:12:10.350 --> 00:12:18.829
like fmap that have very interesting

248
00:12:12.749 --> 00:12:22.309
meanings to our to FRP for example if

249
00:12:18.829 --> 00:12:26.759
there's a an extension of fmap apply

250
00:12:22.309 --> 00:12:29.879
for that takes in a behavior that

251
00:12:26.759 --> 00:12:35.399
contains some sort of functionality in

252
00:12:29.879 --> 00:12:37.799
it and an event a and when this event

253
00:12:35.399 --> 00:12:42.899
happens at that time it will modify the

254
00:12:37.799 --> 00:12:45.509
event into another one that it's sort of

255
00:12:42.899 --> 00:12:49.079
like mapping that dynamics of this

256
00:12:45.509 --> 00:12:53.430
behavior on to an event in changing the

257
00:12:49.079 --> 00:12:56.640
how this event behaves
>> okay
>> it serve

258
00:12:53.430 --> 00:12:59.520
like an application of dynamics and that

259
00:12:56.640 --> 00:13:01.470
seems really powerful to me that's just

260
00:12:59.520 --> 00:13:03.300
one of the reasons this fascinates me so

261
00:13:01.470 --> 00:13:06.899
much the fact that we can talk about

262
00:13:03.300 --> 00:13:10.399
composing dynamics and applying dynamics

263
00:13:06.899 --> 00:13:15.000
to events also the ability to

264
00:13:10.399 --> 00:13:17.850
think of your problem as flows of things

265
00:13:15.000 --> 00:13:20.279
is very interesting to me because sort

266
00:13:17.850 --> 00:13:22.800
of that analogy of flowing seems to work

267
00:13:20.279 --> 00:13:27.570
very well like for example when I'm

268
00:13:22.800 --> 00:13:30.240
filtering a behavior that just seems to

269
00:13:27.570 --> 00:13:33.779
me like literally filtering a flow of

270
00:13:30.240 --> 00:13:35.940
things
>> get you yeah yeah yeah yeah
>> it's

271
00:13:33.779 --> 00:13:37.230
just semantically very very interesting

272
00:13:35.940 --> 00:13:40.050
>> mm-hmm

273
00:13:37.230 --> 00:13:44.550
>> the semantics being so clearly defined

274
00:13:40.050 --> 00:13:47.160
and having just a very expressive way of

275
00:13:44.550 --> 00:13:49.890
talking about these things is helpful to

276
00:13:47.160 --> 00:13:53.250
me personally it just clicks with me

277
00:13:49.890 --> 00:13:56.370
quite a bit Oh
>> expressiveness

278
00:13:53.250 --> 00:13:58.920
that's very helpful
>> yeah exactly

279
00:13:56.370 --> 00:14:03.360
and also a lot of the talks I've seen

280
00:13:58.920 --> 00:14:05.459
reference why that you know that paper why

281
00:14:03.360 --> 00:14:07.200
functional programming matters because

282
00:14:05.459 --> 00:14:09.330
it seems to be that a lot of the stuff

283
00:14:07.200 --> 00:14:11.160
in that paper why functional

284
00:14:09.330 --> 00:14:14.880
programming matters really translates

285
00:14:11.160 --> 00:14:17.790
into why FRP matters and that's going back

286
00:14:14.880 --> 00:14:22.080
to really to me this being sort of an

287
00:14:17.790 --> 00:14:25.890
extension of what we expect from a pure

288
00:14:22.080 --> 00:14:28.380
functional language
>> ok cool Jose seems

289
00:14:25.890 --> 00:14:33.720
like we've been covering the

290
00:14:28.380 --> 00:14:36.750
specifications of FRP so what what about

291
00:14:33.720 --> 00:14:39.270
the implementation of FRP or have you

292
00:14:36.750 --> 00:14:42.420
seen any in the wild recently that kind

293
00:14:39.270 --> 00:14:45.810
of catch your attention
>> yeah one of the

294
00:14:42.420 --> 00:14:50.850
main complaints that I've seen thrown

295
00:14:45.810 --> 00:14:52.680
out by the person who sort of came

296
00:14:50.850 --> 00:14:56.190
because I came up with the concept of

297
00:14:52.680 --> 00:14:58.500
FRP at least in this version of it he

298
00:14:56.190 --> 00:15:01.500
doesn't feel like there's any accurate

299
00:14:58.500 --> 00:15:03.510
implementations of FRP in the world

300
00:15:01.500 --> 00:15:06.450
though there are some that get very

301
00:15:03.510 --> 00:15:07.200
close and I'm sure I think I believe

302
00:15:06.450 --> 00:15:09.300
he's mentioned

303
00:15:07.200 --> 00:15:12.420
that sodium I believe has some very

304
00:15:09.300 --> 00:15:15.570
accurate one but the one that's
>> like

305
00:15:12.420 --> 00:15:20.490
sodium is in like a S O D I U M

306
00:15:15.570 --> 00:15:23.010
cool
>> so the implementation that's caught

307
00:15:20.490 --> 00:15:27.180
my eye the most has been there spent two

308
00:15:23.010 --> 00:15:29.970
reactive banana Yampa but Yampa I would

309
00:15:27.180 --> 00:15:30.480
rather not get into because that's arrow

310
00:15:29.970 --> 00:15:34.320
eyes

311
00:15:30.480 --> 00:15:36.600
FRP
>> that's the that was used in a Quake

312
00:15:34.320 --> 00:15:39.090
clone I think
>> yeah right it is very

313
00:15:36.600 --> 00:15:42.480
exciting yeah yeah

314
00:15:39.090 --> 00:15:44.340
I wish I could talk about it but that

315
00:15:42.480 --> 00:15:46.950
would take a while and I

316
00:15:44.340 --> 00:15:48.810
I have not explored it enough to be able

317
00:15:46.950 --> 00:15:51.950
to talk about it yes over-reactive

318
00:15:48.810 --> 00:15:54.330
banana is fairly close to the

319
00:15:51.950 --> 00:15:58.140
specification we just described and it's

320
00:15:54.330 --> 00:16:00.810
also very well documented and has a few

321
00:15:58.140 --> 00:16:04.140
tutorials and a really cool wiki page

322
00:16:00.810 --> 00:16:06.030
with some funny fake testimonials that I

323
00:16:04.140 --> 00:16:12.060
would encourage everyone listening to

324
00:16:06.030 --> 00:16:14.850
look at yeah reactive banana implements

325
00:16:12.060 --> 00:16:19.410
you know the behavior abstraction the

326
00:16:14.850 --> 00:16:21.330
event abstraction and it has most of the

327
00:16:19.410 --> 00:16:26.160
things you would you would see in the

328
00:16:21.330 --> 00:16:29.310
specification which we will link a talk

329
00:16:26.160 --> 00:16:31.470
in some slides by Conal specified the

330
00:16:29.310 --> 00:16:35.010
specification of like like the actual

331
00:16:31.470 --> 00:16:38.910
API specification
>> gotcha
>> that would take a

332
00:16:35.010 --> 00:16:46.520
bit of talking because it's symbolic so

333
00:16:38.910 --> 00:16:50.310
it's kind of awkward to
>> 15 minutes
>> yeah

334
00:16:46.520 --> 00:16:50.970
so yeah reactive banana is a really good

335
00:16:50.310 --> 00:16:54.540
one

336
00:16:50.970 --> 00:16:56.360
a it has a really funny tutorial which

337
00:16:54.540 --> 00:16:59.700
is implementing the world's worst

338
00:16:56.360 --> 00:17:03.570
synthesizer there's been quite a bit of

339
00:16:59.700 --> 00:17:05.640
success with FRP and music and sound

340
00:17:03.570 --> 00:17:08.280
programming
>> that's that's really cool

341
00:17:05.640 --> 00:17:09.930
>> pretty interesting
>> if you haven't

342
00:17:08.280 --> 00:17:13.110
guessed already I'm completely a game

343
00:17:09.930 --> 00:17:16.150
nerd too so
>> yeah so this just very good

344
00:17:13.110 --> 00:17:22.329
stuff for most people actually

345
00:17:16.150 --> 00:17:24.140
>> awesome well any other FRP

346
00:17:22.329 --> 00:17:26.690
implementations out in the wild that you

347
00:17:24.140 --> 00:17:28.250
can think of
>> a net wired looked

348
00:17:26.690 --> 00:17:30.500
interesting to me but I believe that

349
00:17:28.250 --> 00:17:33.770
once deprecated but it's another arrow

350
00:17:30.500 --> 00:17:36.770
iced one but I believe I mentioned this

351
00:17:33.770 --> 00:17:39.710
earlier there is the there is a

352
00:17:36.770 --> 00:17:40.550
repository called FRP zoo which allows

353
00:17:39.710 --> 00:17:45.170
you to explore

354
00:17:40.550 --> 00:17:47.750
oh the at least the most popular FRP

355
00:17:45.170 --> 00:17:49.670
libraries out there and it has a way of

356
00:17:47.750 --> 00:17:51.830
testing out how they behave by that

357
00:17:49.670 --> 00:17:52.940
click example I'm accumulating clicks

358
00:17:51.830 --> 00:17:56.780
and so on
>> gotcha

359
00:17:52.940 --> 00:17:59.540
okay and we'll probably link that in in

360
00:17:56.780 --> 00:18:04.520
with this podcast I'm along with several

361
00:17:59.540 --> 00:18:07.490
other links
>> yeah and there is a strange

362
00:18:04.520 --> 00:18:10.310
loop talk by the creator of elm I guess

363
00:18:07.490 --> 00:18:16.700
back in back when Elm started it was a

364
00:18:10.310 --> 00:18:20.270
first order FRP implementation and he

365
00:18:16.700 --> 00:18:22.430
goes over the various categories of FRP

366
00:18:20.270 --> 00:18:25.520
and that's a very good way to get

367
00:18:22.430 --> 00:18:29.450
started churning out and to the zoo of

368
00:18:25.520 --> 00:18:32.120
FRP
>> yeah nice
>> all right

369
00:18:29.450 --> 00:18:33.830
I would also like to mention that I by

370
00:18:32.120 --> 00:18:35.780
no means I'm an expert in this and this

371
00:18:33.830 --> 00:18:38.180
very much an exploratory discussion

372
00:18:35.780 --> 00:18:41.360
there's just something that was very

373
00:18:38.180 --> 00:18:43.970
interesting to me and I thought hey it'd

374
00:18:41.360 --> 00:18:46.780
be a cool topic to just get people

375
00:18:43.970 --> 00:18:49.220
talking about it because it I I think

376
00:18:46.780 --> 00:18:51.640
this topic warrants a lot more

377
00:18:49.220 --> 00:18:55.370
exploration there certainly is but I

378
00:18:51.640 --> 00:18:57.860
like to make more people wear it in case

379
00:18:55.370 --> 00:19:01.070
they were not
>> sure yeah like like me I

380
00:18:57.860 --> 00:19:02.990
was not aware about FRP until just

381
00:19:01.070 --> 00:19:04.370
recently yeah yeah and I have learned a

382
00:19:02.990 --> 00:19:07.060
lot just from talking to with you today

383
00:19:04.370 --> 00:19:11.900
>> it's just a really fascinating thing and

384
00:19:07.060 --> 00:19:16.340
yeah any any knowledge that anyone might

385
00:19:11.900 --> 00:19:17.720
have out there I am very open to it is

386
00:19:16.340 --> 00:19:20.210
>> constantly learning you're not learning

387
00:19:17.720 --> 00:19:23.590
what are you doing it could
>> have a

388
00:19:20.210 --> 00:19:26.240
little bit less dumb every day

389
00:19:23.590 --> 00:19:34.220
>> my wife might claim them that's a huge

390
00:19:26.240 --> 00:19:35.690
challenge but yeah
>> i believe in you dustin
>> all right well thanks

391
00:19:34.220 --> 00:19:39.140
for being on the show with me today Jose

392
00:19:35.690 --> 00:19:40.880
>> well thank you this was really fun
>> and

393
00:19:39.140 --> 00:19:43.160
I'd like to thank our audience for

394
00:19:40.880 --> 00:19:45.950
listening to the Haskell Weekly podcast

395
00:19:43.160 --> 00:19:48.830
if you liked what you heard find out

396
00:19:45.950 --> 00:19:52.040
more at our website haslellweekly.news

397
00:19:48.830 --> 00:19:54.860
also please rate and review us on

398
00:19:52.040 --> 00:19:57.140
iTunes it helps a lot haskell weekly is

399
00:19:54.860 --> 00:19:58.910
brought to you by IT Pro TV the tech

400
00:19:57.140 --> 00:20:01.820
skills development platform for IT

401
00:19:58.910 --> 00:20:03.650
professionals and they also happen to be

402
00:20:01.820 --> 00:20:05.840
our employer so yeah

403
00:20:03.650 --> 00:20:10.520
send your sys admins and network admins

404
00:20:05.840 --> 00:20:13.040
to www.itpro.tv for all of their

405
00:20:10.520 --> 00:20:14.570
learning needs thanks again for

406
00:20:13.040 --> 00:20:17.320
listening we'll see you again next week

407
00:20:14.570 --> 00:20:17.320
see ya