WEBVTT

1
00:00:00.040 --> 00:00:02.680
<v Speaker 1>Welcome everyone to another deep dive. You know, our goal

2
00:00:02.720 --> 00:00:04.599
<v Speaker 1>here is always the same, to help you get a

3
00:00:04.639 --> 00:00:10.560
<v Speaker 1>really thorough, multi perspective understanding of complex topics without feeling

4
00:00:10.599 --> 00:00:13.000
<v Speaker 1>totally overwhelmed by information overload.

5
00:00:12.839 --> 00:00:17.679
<v Speaker 2>Right, because there there's just so much noise out there, exactly.

6
00:00:18.079 --> 00:00:20.960
<v Speaker 1>And today's mission is unpacking a really fascinating book. It's

7
00:00:20.960 --> 00:00:25.679
<v Speaker 1>called Functional Programming in JavaScript by Lewis Atensio. A great read, Yeah,

8
00:00:25.719 --> 00:00:28.640
<v Speaker 1>it really is. And the goal today is to demystify

9
00:00:29.160 --> 00:00:33.359
<v Speaker 1>functional programming, or FP as we'll call it, and figure

10
00:00:33.359 --> 00:00:36.159
<v Speaker 1>out how it acts as a well a shortcut to

11
00:00:36.200 --> 00:00:38.479
<v Speaker 1>writing cleaner, less buggy.

12
00:00:38.119 --> 00:00:41.840
<v Speaker 2>Code, specifically in JavaScript, which, as anyone who writes it knows,

13
00:00:41.840 --> 00:00:43.159
<v Speaker 2>can be a bit of a wild West.

14
00:00:43.320 --> 00:00:45.799
<v Speaker 1>Oh absolutely. I mean, as web apps get more complex,

15
00:00:46.159 --> 00:00:49.479
<v Speaker 1>JavaScript's dynamic, mutable nature can just turn your code into

16
00:00:49.479 --> 00:00:50.640
<v Speaker 1>a totally tangled mess.

17
00:00:50.759 --> 00:00:52.280
<v Speaker 2>Yeah, complete house of cards.

18
00:00:52.399 --> 00:00:54.920
<v Speaker 1>Right. So we're going to explore how shifting to a

19
00:00:54.920 --> 00:00:58.000
<v Speaker 1>functional mindset can actually protect you from JavaScript itself.

20
00:00:58.119 --> 00:01:01.359
<v Speaker 2>It's a fundamental paradigm shift, really, moving from an imperative

21
00:01:01.399 --> 00:01:03.600
<v Speaker 2>way of thinking to a declarative one.

22
00:01:03.880 --> 00:01:06.120
<v Speaker 1>And there's this brilliant quote from Michael feathers and the

23
00:01:06.159 --> 00:01:11.040
<v Speaker 1>text that really nails this. He says, Ooh, object oriented

24
00:01:11.079 --> 00:01:16.879
<v Speaker 1>programming makes code understandable by encapsulating moving parts, and FP.

25
00:01:16.920 --> 00:01:19.879
<v Speaker 2>Makes code understandable by minimizing moving parts.

26
00:01:20.079 --> 00:01:23.959
<v Speaker 1>Yes, minimizing the moving parts, which is just I mean,

27
00:01:24.040 --> 00:01:25.799
<v Speaker 1>it's such a perfect way to frame it.

28
00:01:26.359 --> 00:01:29.680
<v Speaker 2>What's fascinating here is that it completely changes how you

29
00:01:29.719 --> 00:01:34.120
<v Speaker 2>approach problem solving. In imperative programming, you're detailing exactly how

30
00:01:34.120 --> 00:01:35.000
<v Speaker 2>a computer.

31
00:01:34.640 --> 00:01:38.400
<v Speaker 1>Should do a task, like manually managing a loop counter

32
00:01:38.760 --> 00:01:40.359
<v Speaker 1>just to square an array of numbers.

33
00:01:40.120 --> 00:01:44.159
<v Speaker 2>It's highly mechanical. But with declarative programming, you just describe

34
00:01:44.159 --> 00:01:46.879
<v Speaker 2>what the logic is without worrying about the control flow.

35
00:01:46.959 --> 00:01:49.519
<v Speaker 2>It's a lot like writing a SEQL query.

36
00:01:49.680 --> 00:01:51.319
<v Speaker 1>You just asked for the data. You don't tell the

37
00:01:51.359 --> 00:01:53.840
<v Speaker 1>database how to spin the hard drive to go find it.

38
00:01:53.920 --> 00:01:57.640
<v Speaker 2>Precisely, you separate the program's description from its evaluation.

39
00:01:58.000 --> 00:02:02.680
<v Speaker 1>I always like to think of imperative programming like micromanaging

40
00:02:02.680 --> 00:02:06.079
<v Speaker 1>a new employee to build a presentation. You're hovering over them, saying,

41
00:02:06.319 --> 00:02:09.280
<v Speaker 1>click this menu, type this word, make it bold, exactly right.

42
00:02:09.400 --> 00:02:12.439
<v Speaker 1>But declarative is like giving the task to a highly

43
00:02:12.439 --> 00:02:15.199
<v Speaker 1>competent assistant. You just give them the final goal and

44
00:02:15.240 --> 00:02:16.639
<v Speaker 1>trust their process.

45
00:02:16.639 --> 00:02:20.159
<v Speaker 2>And that trust lets developers focus on the actual business logic,

46
00:02:20.639 --> 00:02:21.360
<v Speaker 2>not the plumbing.

47
00:02:21.680 --> 00:02:24.080
<v Speaker 1>Yeah, the plumbing is where the bugs live. So to

48
00:02:24.159 --> 00:02:27.599
<v Speaker 1>build this trust, the book talks about two core pillars,

49
00:02:28.080 --> 00:02:30.960
<v Speaker 1>pure functions and immutability.

50
00:02:30.280 --> 00:02:32.360
<v Speaker 2>The foundational building blocks of FP.

51
00:02:32.759 --> 00:02:36.120
<v Speaker 1>Let's talk about pure functions first. These are functions that

52
00:02:36.199 --> 00:02:38.840
<v Speaker 1>depend only on the inputs you give them, and they

53
00:02:38.879 --> 00:02:41.360
<v Speaker 1>inflict zero changes beyond their scope.

54
00:02:41.560 --> 00:02:43.479
<v Speaker 2>Right, they operate in total isolation.

55
00:02:43.879 --> 00:02:46.719
<v Speaker 1>The book gives some great examples of impure functions to

56
00:02:46.759 --> 00:02:49.960
<v Speaker 1>contrast this, like date dot now.

57
00:02:50.120 --> 00:02:53.759
<v Speaker 2>Oh yeah, date dot now is completely unpredictable.

58
00:02:53.080 --> 00:02:55.520
<v Speaker 1>Because it relies on time. You call it twice, you

59
00:02:55.560 --> 00:02:59.800
<v Speaker 1>get two different answers. Or like modifying a global counter variable.

60
00:02:59.479 --> 00:03:02.520
<v Speaker 2>Which is affect. You're reaching outside the function and messing

61
00:03:02.560 --> 00:03:03.639
<v Speaker 2>with the global state.

62
00:03:03.479 --> 00:03:07.120
<v Speaker 1>Which leads us to referential transparency. Meaning if a function

63
00:03:07.280 --> 00:03:10.080
<v Speaker 1>always yields the exact same result for the same input,

64
00:03:10.479 --> 00:03:13.560
<v Speaker 1>it can literally be mathematically substituted.

65
00:03:12.919 --> 00:03:15.080
<v Speaker 2>Which makes the code incredibly predictable.

66
00:03:15.319 --> 00:03:19.599
<v Speaker 1>Predictability is exactly what we want. But the second pillar, immutability,

67
00:03:20.439 --> 00:03:22.960
<v Speaker 1>that's where things get tricky in JavaScript, very.

68
00:03:22.800 --> 00:03:24.840
<v Speaker 2>Tricky JavaScript loves mutation.

69
00:03:25.159 --> 00:03:29.120
<v Speaker 1>Yeah, the book points out this native flaw array dot sort.

70
00:03:29.840 --> 00:03:32.759
<v Speaker 1>It doesn't give you a nice new, sordid array, No.

71
00:03:32.800 --> 00:03:34.560
<v Speaker 2>It sorts it in place, right.

72
00:03:34.439 --> 00:03:38.199
<v Speaker 1>It modifies the original reference, creating this massive, dangerous side

73
00:03:38.199 --> 00:03:39.159
<v Speaker 1>effect which.

74
00:03:39.000 --> 00:03:41.960
<v Speaker 2>Can break entirely unrelated parts of your app that we're

75
00:03:42.000 --> 00:03:43.719
<v Speaker 2>relying on that original array.

76
00:03:43.840 --> 00:03:47.400
<v Speaker 1>Okay, let's unpack this. Yeah, because if we can't mutate objects,

77
00:03:47.680 --> 00:03:50.800
<v Speaker 1>and we can't change global variables or even print to

78
00:03:50.840 --> 00:03:52.919
<v Speaker 1>a screen without causing a quote unquote side.

79
00:03:52.759 --> 00:03:54.280
<v Speaker 2>Effect, I know where you're going with this.

80
00:03:54.520 --> 00:03:57.439
<v Speaker 1>I mean, what practical value does a pure program actually have?

81
00:03:57.960 --> 00:04:00.639
<v Speaker 1>Isn't an entire app just one giant side effect?

82
00:04:00.719 --> 00:04:03.719
<v Speaker 2>It is without side effects. Your program is basically just

83
00:04:04.560 --> 00:04:07.840
<v Speaker 2>a space heater for your room. It just burns CPU cycles.

84
00:04:07.479 --> 00:04:09.800
<v Speaker 1>Exactly, So how do we actually build anything useful?

85
00:04:09.919 --> 00:04:13.360
<v Speaker 2>Practical FP doesn't forbid side effects, it just manages them.

86
00:04:13.560 --> 00:04:16.360
<v Speaker 2>The goal is to tightly isolate the pure logic from

87
00:04:16.399 --> 00:04:17.639
<v Speaker 2>the impure interactions.

88
00:04:17.879 --> 00:04:22.279
<v Speaker 1>Oh okay, so like dom manipulation or database calls. Right.

89
00:04:22.720 --> 00:04:26.399
<v Speaker 2>The book uses this monolithic show student function as an example.

90
00:04:26.920 --> 00:04:30.319
<v Speaker 2>It queries the database, formats the data, and renders the

91
00:04:30.439 --> 00:04:33.439
<v Speaker 2>HTML all in one giant block.

92
00:04:33.240 --> 00:04:34.480
<v Speaker 1>The total nightmare to test.

93
00:04:34.480 --> 00:04:38.399
<v Speaker 2>I bet absolutely so the functional approach decomposes that into smaller,

94
00:04:38.720 --> 00:04:42.279
<v Speaker 2>single purpose pieces. You put all the impure database and

95
00:04:42.439 --> 00:04:44.720
<v Speaker 2>UI stuff at the very edges of your app.

96
00:04:44.560 --> 00:04:48.279
<v Speaker 1>Leaving the core logic perfectly pure, intestable exactly. Okay, that

97
00:04:48.279 --> 00:04:52.399
<v Speaker 1>makes sense. But enforcing that immutability in a language like JavaScript,

98
00:04:52.519 --> 00:04:55.720
<v Speaker 1>which naturally just lacks it, right, how do we tame

99
00:04:56.160 --> 00:04:57.560
<v Speaker 1>this wild nature?

100
00:04:57.720 --> 00:05:00.800
<v Speaker 2>Well, the book introduces a few strategies, like the value

101
00:05:00.800 --> 00:05:01.959
<v Speaker 2>object pattern.

102
00:05:01.680 --> 00:05:02.839
<v Speaker 1>Write the zip code example.

103
00:05:03.000 --> 00:05:08.360
<v Speaker 2>Yeah, By returning an object literal interface with pseudo private

104
00:05:08.480 --> 00:05:12.759
<v Speaker 2>variables inside a closure, you basically create a primitive like object.

105
00:05:12.839 --> 00:05:15.319
<v Speaker 1>It has no mutating methods. You can read it, but

106
00:05:15.399 --> 00:05:16.600
<v Speaker 1>you can't change it exactly.

107
00:05:16.680 --> 00:05:17.959
<v Speaker 2>It's a really solid defense.

108
00:05:18.000 --> 00:05:20.399
<v Speaker 1>But then there's object dot freeze, which is a native tool.

109
00:05:20.519 --> 00:05:22.759
<v Speaker 2>It is, but it has a major limitation. It's only

110
00:05:22.759 --> 00:05:23.759
<v Speaker 2>a shallow freeze.

111
00:05:24.079 --> 00:05:26.879
<v Speaker 1>Right, So, if I freeze a person object, the top

112
00:05:26.959 --> 00:05:28.600
<v Speaker 1>level stuff like their name is safe.

113
00:05:28.680 --> 00:05:33.079
<v Speaker 2>But if they have a nested property like address dot country.

114
00:05:32.759 --> 00:05:35.160
<v Speaker 1>That nest to property can still be completely mutated.

115
00:05:35.240 --> 00:05:39.399
<v Speaker 2>Yeah, it leaves you vulnerable unless you write recursive deep

116
00:05:39.480 --> 00:05:42.560
<v Speaker 2>freeze functions. To lock down every single level.

117
00:05:42.639 --> 00:05:46.040
<v Speaker 1>Which brings up a big concern. Isn't deep freezing every

118
00:05:46.199 --> 00:05:49.920
<v Speaker 1>single object or you know, costly making deep copies of

119
00:05:50.040 --> 00:05:53.639
<v Speaker 1>massive data structures just a total nightmare for performance?

120
00:05:53.800 --> 00:05:54.759
<v Speaker 2>It sounds like it would be.

121
00:05:54.879 --> 00:05:57.480
<v Speaker 1>Yeah, why go through all this trouble? I mean copying

122
00:05:57.720 --> 00:06:00.839
<v Speaker 1>huge JSON trees every time a single value changes.

123
00:06:01.120 --> 00:06:04.680
<v Speaker 2>Well, this connects to the bigger picture. You're avoiding cascading

124
00:06:04.720 --> 00:06:07.879
<v Speaker 2>bugs caused by a shared mutable state. The peace of

125
00:06:07.959 --> 00:06:10.519
<v Speaker 2>mind and testability you gain is huge.

126
00:06:10.920 --> 00:06:12.240
<v Speaker 1>Well, what about the performance hit.

127
00:06:12.560 --> 00:06:15.279
<v Speaker 2>That's where lenses come in. The book introduces them via

128
00:06:15.399 --> 00:06:19.040
<v Speaker 2>the ramda dot js library. They act as functional references

129
00:06:19.040 --> 00:06:22.079
<v Speaker 2>that let you read and immutably update nested properties.

130
00:06:22.120 --> 00:06:24.600
<v Speaker 1>Oh, using copy on write semantics exactly.

131
00:06:24.639 --> 00:06:27.279
<v Speaker 2>It gives you structural sharing for free. You aren't doing

132
00:06:27.319 --> 00:06:30.839
<v Speaker 2>heavy deep copies. You're just sharing the unchanged memory branches.

133
00:06:30.879 --> 00:06:33.319
<v Speaker 1>Oh wow, So you get the safety without the massive

134
00:06:33.360 --> 00:06:35.600
<v Speaker 1>memory overhead. That's really clever it is.

135
00:06:35.759 --> 00:06:37.560
<v Speaker 2>The syntax is unobtrusive too.

136
00:06:38.240 --> 00:06:42.920
<v Speaker 1>So JavaScript has some flaws, but its design actually naturally

137
00:06:43.040 --> 00:06:44.839
<v Speaker 1>enables functional programming too.

138
00:06:44.959 --> 00:06:48.600
<v Speaker 2>Right, Oh, definitely. In fact, functions in JavaScript are first.

139
00:06:48.360 --> 00:06:51.680
<v Speaker 1>Class citizens, meaning they can be assigned to variables passed.

140
00:06:51.399 --> 00:06:54.759
<v Speaker 2>Around, right, and that supports higher order functions, functions that

141
00:06:54.839 --> 00:06:58.680
<v Speaker 2>can accept other functions as arguments or return them like a.

142
00:06:58.759 --> 00:07:02.519
<v Speaker 1>Ray dot sort going on to that it's dangerous, but

143
00:07:02.600 --> 00:07:03.800
<v Speaker 1>it is a higher order function.

144
00:07:04.079 --> 00:07:07.040
<v Speaker 2>Yeah, And the book points out how JS natively converts

145
00:07:07.160 --> 00:07:10.240
<v Speaker 2>numbers to strings for sorting based on Unicode, right.

146
00:07:10.120 --> 00:07:12.920
<v Speaker 1>Which is why ten gets sorted before two, which is

147
00:07:13.000 --> 00:07:14.399
<v Speaker 1>just hilarious and awful.

148
00:07:14.480 --> 00:07:17.480
<v Speaker 2>It's the classic JS bug. But because sort is a

149
00:07:17.519 --> 00:07:20.639
<v Speaker 2>higher order function, you can pass a custom comparator function

150
00:07:20.759 --> 00:07:22.360
<v Speaker 2>into it to fix that behavior.

151
00:07:22.560 --> 00:07:24.839
<v Speaker 1>It's treating behavior as data.

152
00:07:24.439 --> 00:07:28.439
<v Speaker 2>Exactly, and that leads directly into closures and scopes. A

153
00:07:28.480 --> 00:07:31.240
<v Speaker 2>closure is basically a data structure that binds a function

154
00:07:31.319 --> 00:07:32.480
<v Speaker 2>to its lexical.

155
00:07:32.160 --> 00:07:35.439
<v Speaker 1>Environment at the exact moment it's declared. Yes, here's where

156
00:07:35.480 --> 00:07:38.040
<v Speaker 1>it gets really interesting. I like to picture a closure

157
00:07:38.160 --> 00:07:39.160
<v Speaker 1>like a snow globe.

158
00:07:39.720 --> 00:07:40.639
<v Speaker 2>Snow globe.

159
00:07:40.800 --> 00:07:43.959
<v Speaker 1>Yeah, the function is the little house inside, and the

160
00:07:44.040 --> 00:07:48.639
<v Speaker 1>closure traps all the surrounding snow, the variables in the

161
00:07:48.639 --> 00:07:51.120
<v Speaker 1>outer scope. Oh, I see, It traps them exactly as

162
00:07:51.160 --> 00:07:53.399
<v Speaker 1>they were when the globe was sealed. It prevents the

163
00:07:53.439 --> 00:07:55.600
<v Speaker 1>outside world from melting them or messing with them.

164
00:07:55.680 --> 00:07:59.040
<v Speaker 2>That's a great visualization and understanding that snow globe is

165
00:07:59.160 --> 00:08:04.040
<v Speaker 2>crucial because of the notorious loop counter ambiguity.

166
00:08:03.399 --> 00:08:05.240
<v Speaker 1>Bug, oh Man, the vara bug.

167
00:08:05.360 --> 00:08:07.800
<v Speaker 2>Yep. If you declare a loop with var, it gets

168
00:08:07.800 --> 00:08:09.959
<v Speaker 2>hoisted to the top of the function, and.

169
00:08:09.920 --> 00:08:12.839
<v Speaker 1>If you're creating closures inside that loop, they all end

170
00:08:12.920 --> 00:08:15.519
<v Speaker 1>up sharing that exact same vari reference.

171
00:08:15.600 --> 00:08:18.360
<v Speaker 2>So it mutates unexpectedly. By the time the loop is done,

172
00:08:18.439 --> 00:08:21.319
<v Speaker 2>all your closures point to the final maximum value of

173
00:08:21.399 --> 00:08:23.439
<v Speaker 2>varas it causes so many bugs.

174
00:08:23.560 --> 00:08:27.040
<v Speaker 1>The closures can also fix this right like using four eights.

175
00:08:26.800 --> 00:08:29.519
<v Speaker 2>Exactly for each creates a fresh scope for every iteration,

176
00:08:29.879 --> 00:08:32.559
<v Speaker 2>or you know, just using e S six's let qword

177
00:08:32.639 --> 00:08:34.840
<v Speaker 2>solves it by properly block scoping the variable.

178
00:08:34.919 --> 00:08:37.399
<v Speaker 1>It all comes back to managing states safely, and that

179
00:08:37.440 --> 00:08:41.720
<v Speaker 1>transitions perfectly into how we process data declaratively. We're fluent

180
00:08:41.799 --> 00:08:43.639
<v Speaker 1>chains and high level operation.

181
00:08:43.799 --> 00:08:46.039
<v Speaker 2>Yeah, moving away from manual loops entirely.

182
00:08:46.360 --> 00:08:50.559
<v Speaker 1>In standard OP you use method chaining like string dot

183
00:08:50.600 --> 00:08:52.159
<v Speaker 1>substring dot to lower case.

184
00:08:52.039 --> 00:08:54.799
<v Speaker 2>It reads left to right. But in FP you use

185
00:08:54.879 --> 00:08:58.039
<v Speaker 2>function chaining and lambda expressions.

186
00:08:58.039 --> 00:09:00.240
<v Speaker 1>A fat arrow function give you.

187
00:09:00.279 --> 00:09:05.360
<v Speaker 2>A really terse one line syntax that implicitly returns values, which.

188
00:09:05.120 --> 00:09:08.679
<v Speaker 1>Perfectly aligns with the FP rule that every function must

189
00:09:08.679 --> 00:09:10.320
<v Speaker 1>return a usable result.

190
00:09:10.440 --> 00:09:13.600
<v Speaker 2>The book shows this incredible example using dot map from

191
00:09:13.600 --> 00:09:14.720
<v Speaker 2>the low dash library.

192
00:09:14.879 --> 00:09:16.960
<v Speaker 1>Oh, the one extracting student full names.

193
00:09:17.080 --> 00:09:19.440
<v Speaker 2>Right, you extract the names from a whole collection of

194
00:09:19.480 --> 00:09:21.679
<v Speaker 2>objects without writing a single for loop.

195
00:09:21.879 --> 00:09:24.399
<v Speaker 1>You're just treating the data and the control flow as

196
00:09:24.440 --> 00:09:26.799
<v Speaker 1>simple connections between high level components.

197
00:09:26.840 --> 00:09:27.519
<v Speaker 2>It's so clean.

198
00:09:28.559 --> 00:09:32.240
<v Speaker 1>But wait, if we're purely nesting functional calls inside out. Yeah,

199
00:09:32.320 --> 00:09:34.799
<v Speaker 1>like concat to lowercase, say.

200
00:09:34.720 --> 00:09:36.559
<v Speaker 2>Right on the Lisp style nesting.

201
00:09:36.679 --> 00:09:39.080
<v Speaker 1>Right, that looks incredibly unreadable to me. How is this

202
00:09:39.159 --> 00:09:41.879
<v Speaker 1>actually better for developers if they can't easily read what

203
00:09:41.960 --> 00:09:42.759
<v Speaker 1>the code is doing.

204
00:09:43.039 --> 00:09:46.159
<v Speaker 2>This raises an important question, because you're right, deep nesting

205
00:09:46.200 --> 00:09:49.360
<v Speaker 2>is awful for human readability, and that is exactly why

206
00:09:49.480 --> 00:09:52.120
<v Speaker 2>functional programmers use tools like low dash or.

207
00:09:52.120 --> 00:09:53.960
<v Speaker 1>REMDA to create fluent chains.

208
00:09:54.080 --> 00:09:58.639
<v Speaker 2>Exactly, they create pipelines. The data flows sequentially from one

209
00:09:58.879 --> 00:10:01.120
<v Speaker 2>black box operation to the next, so.

210
00:10:01.039 --> 00:10:03.200
<v Speaker 1>It reads top to bottom or left to right again.

211
00:10:03.320 --> 00:10:06.639
<v Speaker 2>Yes, you preserve the mathematical purity, but you keep it

212
00:10:06.720 --> 00:10:09.399
<v Speaker 2>readable for the humans maintaining the code.

213
00:10:09.480 --> 00:10:12.399
<v Speaker 1>So what does this all mean, I mean FP and

214
00:10:12.480 --> 00:10:15.240
<v Speaker 1>JavaScript isn't just a trendy API you plug in.

215
00:10:15.399 --> 00:10:16.039
<v Speaker 2>No, it's not.

216
00:10:16.279 --> 00:10:20.879
<v Speaker 1>It's a profound shift in thinking. By embracing pure functions,

217
00:10:21.360 --> 00:10:25.679
<v Speaker 1>treating objects as immutable values, and leveraging those higher order

218
00:10:25.720 --> 00:10:29.799
<v Speaker 1>functions and closures we talked about, you build modular, highly

219
00:10:29.840 --> 00:10:31.720
<v Speaker 1>predictable applications.

220
00:10:31.120 --> 00:10:34.720
<v Speaker 2>And you don't even have to abandon object oriented programming entirely.

221
00:10:34.399 --> 00:10:36.799
<v Speaker 1>To do it right. The text mentions that sweet spot.

222
00:10:36.919 --> 00:10:39.559
<v Speaker 2>Yeah, JavaScript is a hybrid language. It allows you to

223
00:10:39.559 --> 00:10:42.679
<v Speaker 2>blend a rich op domain model for the broad architecture

224
00:10:42.679 --> 00:10:46.840
<v Speaker 2>with pure functional operations handling the data transformations inside.

225
00:10:47.000 --> 00:10:49.039
<v Speaker 1>It's the best of both worlds, truly. You know, before

226
00:10:49.080 --> 00:10:50.720
<v Speaker 1>we wrap up, I want to leave you the listener

227
00:10:50.720 --> 00:10:53.120
<v Speaker 1>with the final thought. We briefly touched on this concept

228
00:10:53.159 --> 00:10:56.120
<v Speaker 1>from the text called lazy evaluation right.

229
00:10:55.960 --> 00:10:59.000
<v Speaker 2>Deferring execution until the data is actually needed, just to

230
00:10:59.039 --> 00:11:00.559
<v Speaker 2>save cpusite.

231
00:11:00.320 --> 00:11:04.559
<v Speaker 1>Exactly, only computing data at the exact moment it's strictly

232
00:11:04.600 --> 00:11:05.919
<v Speaker 1>required to form an output.

233
00:11:06.000 --> 00:11:07.000
<v Speaker 2>It's highly efficient.

234
00:11:07.360 --> 00:11:10.720
<v Speaker 1>But what if we applied that same architectural philosophy to

235
00:11:10.879 --> 00:11:12.399
<v Speaker 1>our own human productivity?

236
00:11:12.600 --> 00:11:13.679
<v Speaker 2>Oh that's interesting.

237
00:11:13.919 --> 00:11:18.480
<v Speaker 1>Think about our information consumption? What if we stopped eagerly

238
00:11:18.559 --> 00:11:22.240
<v Speaker 1>processing the massive flood of daily data, the emails, the news,

239
00:11:22.279 --> 00:11:26.519
<v Speaker 1>the social media, and only evaluated the information strictly required

240
00:11:26.559 --> 00:11:28.240
<v Speaker 1>for the immediate decision in front of us.

241
00:11:28.399 --> 00:11:30.799
<v Speaker 2>Wow, we'd probably have a lot less mental burnout.

242
00:11:31.039 --> 00:11:33.759
<v Speaker 1>Right, Just like saving CPU cycles, maybe we need to

243
00:11:33.759 --> 00:11:37.320
<v Speaker 1>save our cognitive cycles. A functional mindset for the brain.

244
00:11:37.600 --> 00:11:40.399
<v Speaker 1>I love that something for you to moul over. Thanks

245
00:11:40.440 --> 00:11:42.480
<v Speaker 1>for tuning into this deep dive and we'll see you

246
00:11:42.480 --> 00:11:42.919
<v Speaker 1>next time.