WEBVTT

1
00:00:00.120 --> 00:00:05.000
<v Speaker 1>What if I told you that the secret to ultimate

2
00:00:05.040 --> 00:00:10.560
<v Speaker 1>creative freedom encoding actually relies on having this massive micromanager

3
00:00:10.720 --> 00:00:13.919
<v Speaker 1>hovering over your shoulder, just constantly nagging you.

4
00:00:14.759 --> 00:00:17.519
<v Speaker 2>I mean it sounds completely counterintuitive, right, Yeah. We usually

5
00:00:17.519 --> 00:00:20.839
<v Speaker 2>associate strict rules with a lack of creativity, but in

6
00:00:20.879 --> 00:00:25.039
<v Speaker 2>modern software development, constraints are well, they're exactly what gives

7
00:00:25.079 --> 00:00:27.960
<v Speaker 2>you the space to innovate without blowing everything up.

8
00:00:28.000 --> 00:00:30.399
<v Speaker 1>And that paradox is exactly what we are digging into

9
00:00:30.440 --> 00:00:32.799
<v Speaker 1>today because for you listening, if you've ever felt like

10
00:00:33.159 --> 00:00:35.679
<v Speaker 1>learning a programming language is just I don't know, an

11
00:00:35.679 --> 00:00:38.679
<v Speaker 1>exercise in reading a stereo manual in a foreign language.

12
00:00:38.679 --> 00:00:40.920
<v Speaker 2>Oh, absolutely, today we actually have.

13
00:00:40.920 --> 00:00:44.399
<v Speaker 1>A cheek code we're diving into excerpts from Matt Newberg's

14
00:00:44.479 --> 00:00:49.320
<v Speaker 1>highly regarded iOS twelve programming Fundamentals with Swift. But we

15
00:00:49.359 --> 00:00:50.640
<v Speaker 1>aren't here to memorize.

16
00:00:50.240 --> 00:00:52.359
<v Speaker 2>Syntax, right, no basic loops today.

17
00:00:52.159 --> 00:00:55.200
<v Speaker 1>Exactly, We're here to extract the core philosophy of Swift.

18
00:00:55.240 --> 00:00:58.280
<v Speaker 1>We're going to decode the blueprints of how modern iOS

19
00:00:58.280 --> 00:01:02.240
<v Speaker 1>apps are built, finding those real aha moments hitting inside

20
00:01:02.240 --> 00:01:02.960
<v Speaker 1>the architecture.

21
00:01:03.159 --> 00:01:07.560
<v Speaker 2>And Newberg's text is fantastic for this because he treats

22
00:01:07.560 --> 00:01:10.359
<v Speaker 2>Swift not just as a tool, but really as an ideology.

23
00:01:10.840 --> 00:01:13.959
<v Speaker 2>Like Swift wasn't just another language Apple threw together to

24
00:01:14.000 --> 00:01:17.799
<v Speaker 2>replace objective C. It's built from the ground up on

25
00:01:17.959 --> 00:01:22.799
<v Speaker 2>three main pillars, which are safety, strictness, and this shockingly

26
00:01:22.920 --> 00:01:29.319
<v Speaker 2>elegant internal logic. It is literally a language actively designed

27
00:01:29.319 --> 00:01:30.879
<v Speaker 2>to protect you from your own worst habits.

28
00:01:30.920 --> 00:01:33.560
<v Speaker 1>Okay, let's unpack this because that protection starts at the

29
00:01:33.560 --> 00:01:36.319
<v Speaker 1>most foundational level, right, Like how we store data. So

30
00:01:36.640 --> 00:01:38.719
<v Speaker 1>assuming you already know the basics of variables, you know

31
00:01:38.719 --> 00:01:41.400
<v Speaker 1>they act kind of like shoe boxing. Yep, classic analogy, right,

32
00:01:41.439 --> 00:01:43.719
<v Speaker 1>you put data in, you write a name on the box.

33
00:01:43.719 --> 00:01:47.120
<v Speaker 1>But Swift is like border let obsessed with the status

34
00:01:47.159 --> 00:01:48.840
<v Speaker 1>of the lid on that box. You can't just make

35
00:01:48.879 --> 00:01:50.959
<v Speaker 1>a variable. You have to declare it using var or

36
00:01:51.040 --> 00:01:53.319
<v Speaker 1>let exactly. So var means the lid is off, the

37
00:01:53.359 --> 00:01:56.840
<v Speaker 1>contents can change. But using let is like putting data

38
00:01:56.959 --> 00:01:59.840
<v Speaker 1>inside and then immediately super gluing the lid shut.

39
00:02:00.040 --> 00:02:02.239
<v Speaker 2>It's a great way to put It becomes a permanent constant.

40
00:02:02.719 --> 00:02:05.480
<v Speaker 1>Right. And what blows my mind is that if you

41
00:02:05.640 --> 00:02:08.400
<v Speaker 1>use var for a box, but the compiler notices you

42
00:02:08.479 --> 00:02:12.319
<v Speaker 1>never actually change what's inside, it will literally pause the build,

43
00:02:12.719 --> 00:02:15.680
<v Speaker 1>throw a warning, and nag you to superglue it with let.

44
00:02:16.400 --> 00:02:19.719
<v Speaker 1>I mean, why is the compiler so obsessed with immutability?

45
00:02:20.000 --> 00:02:24.719
<v Speaker 2>Well, basically because immutability breeds certainty, and certainty breed speed

46
00:02:24.759 --> 00:02:28.360
<v Speaker 2>and safety under the hood. When you define something with lead,

47
00:02:28.759 --> 00:02:31.719
<v Speaker 2>you are establishing a hard contract with the compiler. Oh okay,

48
00:02:31.840 --> 00:02:34.960
<v Speaker 2>you're saying, I swear this value will never ever mutate.

49
00:02:35.560 --> 00:02:38.439
<v Speaker 2>And when the compiler knows for an absolute fact that

50
00:02:38.479 --> 00:02:41.800
<v Speaker 2>this memory address won't change, it can aggressively optimize the

51
00:02:41.879 --> 00:02:43.039
<v Speaker 2>underlying machine code.

52
00:02:43.080 --> 00:02:43.639
<v Speaker 1>Oh wow.

53
00:02:43.800 --> 00:02:46.520
<v Speaker 2>Yeah, it doesn't have to allocate extra resources to monitor

54
00:02:46.560 --> 00:02:48.639
<v Speaker 2>that memory space for unexpected alterations.

55
00:02:48.680 --> 00:02:51.439
<v Speaker 1>So it's not just a stylistic preference. It actually changes

56
00:02:51.479 --> 00:02:54.120
<v Speaker 1>how the code is physically compiled and run exactly.

57
00:02:54.479 --> 00:02:57.360
<v Speaker 2>I mean, think about thread safety. In a modern app.

58
00:02:57.520 --> 00:03:01.759
<v Speaker 2>You might have background threads downloading data while the main

59
00:03:01.800 --> 00:03:04.639
<v Speaker 2>thread updates the UI. If both threads are trying to

60
00:03:04.680 --> 00:03:07.159
<v Speaker 2>read and write to a var shoebox at the exact

61
00:03:07.199 --> 00:03:10.240
<v Speaker 2>same time, you get a race condition and the app crashes.

62
00:03:10.280 --> 00:03:12.479
<v Speaker 1>The dreaded crash, right, yeah, But if.

63
00:03:12.319 --> 00:03:16.039
<v Speaker 2>That shoebox is super glued shut with let one hundred

64
00:03:16.080 --> 00:03:20.680
<v Speaker 2>different threads can safely read it simultaneously without needing complex

65
00:03:20.800 --> 00:03:24.039
<v Speaker 2>locks or semaphores, just because they all know the data

66
00:03:24.199 --> 00:03:26.360
<v Speaker 2>isn't going to suddenly shift underneath them.

67
00:03:26.639 --> 00:03:30.000
<v Speaker 1>So the strictness upfront prevents the catastrophic bugs down the

68
00:03:30.080 --> 00:03:31.039
<v Speaker 1>road exactly.

69
00:03:31.199 --> 00:03:32.960
<v Speaker 2>The compiler is your safety net.

70
00:03:33.120 --> 00:03:35.879
<v Speaker 1>It forces you to declare your intent, Like if you

71
00:03:35.919 --> 00:03:39.000
<v Speaker 1>say something might change, you better actually change it, otherwise

72
00:03:39.000 --> 00:03:41.159
<v Speaker 1>you're just introducing unnecessary.

73
00:03:40.560 --> 00:03:46.039
<v Speaker 2>Risk precisely, and that insistence on absolute consistency it bleeds

74
00:03:46.159 --> 00:03:50.319
<v Speaker 2>right into Swift's a most radical mind bending rule. I mean,

75
00:03:50.439 --> 00:03:54.199
<v Speaker 2>it completely abandons a concept that developers have just accepted

76
00:03:54.240 --> 00:03:56.199
<v Speaker 2>as normal for decades.

77
00:03:55.919 --> 00:03:58.919
<v Speaker 1>Right right, the idea of primitive scaler types. Because if

78
00:03:58.919 --> 00:04:02.319
<v Speaker 1>you're coming from CR OBJECTIVEC, you're used to this weird dichotomy.

79
00:04:02.319 --> 00:04:04.800
<v Speaker 1>You have complex objects on one hand, and then you

80
00:04:04.840 --> 00:04:08.080
<v Speaker 1>have primitive raw data on the other, like a basic number,

81
00:04:08.159 --> 00:04:11.439
<v Speaker 1>say the integer one is usually just a primitive But

82
00:04:11.520 --> 00:04:15.319
<v Speaker 1>in Swift there are no primitive data types. Like literally

83
00:04:15.400 --> 00:04:18.399
<v Speaker 1>everything is an object. The number one is an instance

84
00:04:18.399 --> 00:04:18.600
<v Speaker 1>of a.

85
00:04:18.639 --> 00:04:23.040
<v Speaker 2>Struct which represents a massive paradigm shift because an object,

86
00:04:23.199 --> 00:04:26.040
<v Speaker 2>by definition is an entity that you can send messages

87
00:04:26.079 --> 00:04:29.600
<v Speaker 2>to it has properties and methods. Okay, So in Swift,

88
00:04:29.600 --> 00:04:31.839
<v Speaker 2>you don't just use the number one in an equation.

89
00:04:32.199 --> 00:04:34.600
<v Speaker 2>You can literally write the number one, follow it with

90
00:04:34.639 --> 00:04:36.839
<v Speaker 2>a dot, and send it a message like one dot description,

91
00:04:37.199 --> 00:04:39.759
<v Speaker 2>and it will return a string representation of itself. Wait,

92
00:04:40.319 --> 00:04:42.480
<v Speaker 2>the integer itself knows how to describe itself.

93
00:04:42.639 --> 00:04:45.800
<v Speaker 1>Stop right there, you're saying even the most basic components

94
00:04:45.879 --> 00:04:49.560
<v Speaker 1>are objects communicating via messages. Yes, because the book points

95
00:04:49.560 --> 00:04:52.519
<v Speaker 1>out that even basic math falls under this. When you

96
00:04:52.560 --> 00:04:55.560
<v Speaker 1>write one plus two, the plus sign isn't a native

97
00:04:55.600 --> 00:04:58.759
<v Speaker 1>math operator like it is in C. It's secretly just

98
00:04:58.800 --> 00:05:02.120
<v Speaker 1>a method discus with special syntax being sent to the

99
00:05:02.120 --> 00:05:05.199
<v Speaker 1>object one. But here's where I push back. If basic

100
00:05:05.240 --> 00:05:08.839
<v Speaker 1>arithmetic is actually a complex message passing operation, isn't that

101
00:05:08.920 --> 00:05:12.000
<v Speaker 1>horribly inefficient? I mean, why reinvent the wheel if it's

102
00:05:12.000 --> 00:05:14.439
<v Speaker 1>going to add massive overhead and slow the car down.

103
00:05:14.639 --> 00:05:17.519
<v Speaker 2>It's a very valid concern, and honestly, if Swift were

104
00:05:17.680 --> 00:05:21.399
<v Speaker 2>purely an interpreted language, that overhead would be a total nightmare.

105
00:05:22.000 --> 00:05:25.639
<v Speaker 2>But here's the genius of the architecture. Swift uses a

106
00:05:25.680 --> 00:05:30.920
<v Speaker 2>highly advanced compiler infrastructure called LVM okay LLVM right so

107
00:05:30.959 --> 00:05:33.079
<v Speaker 2>when you are writing the code, yes you are treating

108
00:05:33.120 --> 00:05:35.720
<v Speaker 2>one as an object and plus as a method. You

109
00:05:35.759 --> 00:05:39.240
<v Speaker 2>get all the high level expressive benefits of object oriented programming.

110
00:05:39.319 --> 00:05:41.839
<v Speaker 1>Right, it reads better exactly, But when you hit.

111
00:05:41.800 --> 00:05:46.120
<v Speaker 2>Build, the strict compiler analyzes that operation because it knows

112
00:05:46.160 --> 00:05:48.639
<v Speaker 2>exactly what the instruct is and it knows exactly what

113
00:05:48.680 --> 00:05:51.240
<v Speaker 2>the plus method does, it just strips all that high

114
00:05:51.279 --> 00:05:52.639
<v Speaker 2>level object abstraction away.

115
00:05:52.680 --> 00:05:54.800
<v Speaker 1>Wait, it just deletes the object part yep.

116
00:05:54.600 --> 00:05:57.079
<v Speaker 2>It compiles it down to the exact same bare metal,

117
00:05:57.519 --> 00:06:00.879
<v Speaker 2>highly optimized machine code instructions that sewed use. So you

118
00:06:00.920 --> 00:06:03.600
<v Speaker 2>get the cognitive benefits of everything being an object with

119
00:06:03.720 --> 00:06:05.519
<v Speaker 2>literally zero run time penalty.

120
00:06:05.800 --> 00:06:08.399
<v Speaker 1>Oh wow, here's where it gets really interesting. Then it's

121
00:06:08.439 --> 00:06:11.439
<v Speaker 1>all about radical simplification for the developer exactly.

122
00:06:11.519 --> 00:06:13.519
<v Speaker 2>I mean, think about the cognitive load and objective C.

123
00:06:14.120 --> 00:06:17.439
<v Speaker 2>You had primitive C types and you had objective C objects.

124
00:06:17.720 --> 00:06:21.920
<v Speaker 2>You constantly had to mental context switch, like wait, is

125
00:06:21.920 --> 00:06:24.720
<v Speaker 2>this an ent or an NS number? Which rules apply?

126
00:06:25.000 --> 00:06:26.399
<v Speaker 1>Right? That sounds exhausting.

127
00:06:26.639 --> 00:06:29.800
<v Speaker 2>It was By making everything an object in Swift, the

128
00:06:29.920 --> 00:06:33.240
<v Speaker 2>language achieves incredible consistency. You only have to learn one

129
00:06:33.240 --> 00:06:35.680
<v Speaker 2>set of rules for how things interact in your entire

130
00:06:35.720 --> 00:06:39.319
<v Speaker 2>code base. Basically, nouns are objects, verbs are messages.

131
00:06:39.360 --> 00:06:41.800
<v Speaker 1>Nouns are objects, verbs are messages. Man, I love that.

132
00:06:42.560 --> 00:06:45.720
<v Speaker 1>So okay, if everything is an object, down to a

133
00:06:45.759 --> 00:06:48.720
<v Speaker 1>true or false boollion, how do swift manage the identity

134
00:06:48.759 --> 00:06:50.720
<v Speaker 1>of all these objects. Let's look at how it separates

135
00:06:50.759 --> 00:06:53.680
<v Speaker 1>the blueprints from the actual buildings or you know as

136
00:06:53.680 --> 00:06:56.079
<v Speaker 1>the source material uses blueprints versus dogs.

137
00:06:56.279 --> 00:06:59.959
<v Speaker 2>Ah. Yes, it's the classic object oriented analogy, but swift

138
00:07:00.319 --> 00:07:03.079
<v Speaker 2>enforcement of it is what really matters. You have object

139
00:07:03.079 --> 00:07:07.160
<v Speaker 2>types like classes, strucks, and enoms, and then you have

140
00:07:07.240 --> 00:07:08.560
<v Speaker 2>instances of those types.

141
00:07:08.800 --> 00:07:11.000
<v Speaker 1>Right, So a dog class is just a concept. It

142
00:07:11.079 --> 00:07:14.120
<v Speaker 1>is purely a blueprint sitting in a file. The dog

143
00:07:14.160 --> 00:07:16.879
<v Speaker 1>class defines that all dogs have a bark method and

144
00:07:16.920 --> 00:07:20.600
<v Speaker 1>a name property exactly, But that blueprint doesn't actually exist

145
00:07:20.639 --> 00:07:22.800
<v Speaker 1>in the memory of your app until you instantiate it.

146
00:07:23.279 --> 00:07:26.519
<v Speaker 1>So if you create two actual instances from that blueprint,

147
00:07:26.600 --> 00:07:30.040
<v Speaker 1>like Fido and Rover, they share the exact same machinery

148
00:07:30.079 --> 00:07:32.639
<v Speaker 1>to bark, but they hold onto their own distinct names.

149
00:07:32.800 --> 00:07:36.279
<v Speaker 2>Yes, and this brings us to encapsulation of functionality and

150
00:07:36.319 --> 00:07:39.319
<v Speaker 2>maintenance of state. Like Fido doesn't need to know how

151
00:07:39.319 --> 00:07:42.879
<v Speaker 2>his vocal cords work to bark. Right, the blueprint handles

152
00:07:42.879 --> 00:07:46.319
<v Speaker 2>the machinery makes sense, but state maintenance is where things

153
00:07:46.439 --> 00:07:50.480
<v Speaker 2>get really critical. Fido must keep track of being Fido.

154
00:07:51.240 --> 00:07:54.600
<v Speaker 2>Rover must keep track of being Rover. Their data, their

155
00:07:54.720 --> 00:07:58.879
<v Speaker 2>state belongs to them alone, and Swift uses the self

156
00:07:58.959 --> 00:08:00.519
<v Speaker 2>keyword to enforce this boundary.

157
00:08:00.720 --> 00:08:03.879
<v Speaker 1>Okay, so is the self keyword essentially like a psychological anchor.

158
00:08:03.920 --> 00:08:06.199
<v Speaker 1>It's the code's way of making sure Fido knows he

159
00:08:06.279 --> 00:08:09.680
<v Speaker 1>is definitively Fido and prevents him from accidentally speaking for

160
00:08:09.800 --> 00:08:11.439
<v Speaker 1>Rover when someone asks for his name.

161
00:08:11.759 --> 00:08:15.319
<v Speaker 2>It is exactly a psychological anchor, right, and honestly it

162
00:08:15.399 --> 00:08:19.439
<v Speaker 2>is the only thing preventing massive enterprise apps from descending

163
00:08:19.519 --> 00:08:22.680
<v Speaker 2>into total chaos. How so, well, imagine an app with

164
00:08:22.839 --> 00:08:27.360
<v Speaker 2>tens of thousands of objects in memory simultaneously. If any

165
00:08:27.399 --> 00:08:30.120
<v Speaker 2>piece of code could just casually reach over and modify

166
00:08:30.199 --> 00:08:33.519
<v Speaker 2>Rover state, tracking down a bug would be impossible.

167
00:08:33.639 --> 00:08:35.440
<v Speaker 1>Yeah, that would be a nightmare.

168
00:08:35.519 --> 00:08:38.320
<v Speaker 2>So what object in Swift is essentially a protective capsule

169
00:08:38.360 --> 00:08:41.159
<v Speaker 2>wrapped around its own data. No other object can pierce

170
00:08:41.200 --> 00:08:45.240
<v Speaker 2>that capsule unless Fido's specific API. The rules defined in

171
00:08:45.279 --> 00:08:48.559
<v Speaker 2>his blueprint allows it. The self keyword is how Fido

172
00:08:48.639 --> 00:08:50.519
<v Speaker 2>refers to his own capsule from the inside.

173
00:08:50.639 --> 00:08:51.279
<v Speaker 1>Got it.

174
00:08:51.279 --> 00:08:54.600
<v Speaker 2>It is absolute proof of identity, guaranteeing that an object

175
00:08:54.639 --> 00:08:56.559
<v Speaker 2>is only operating on its own internal state.

176
00:08:56.720 --> 00:09:00.440
<v Speaker 1>So it creates this beautiful modular safety Phido and are

177
00:09:00.519 --> 00:09:04.000
<v Speaker 1>perfectly secure in their own protective capsules. But objects just

178
00:09:04.039 --> 00:09:06.720
<v Speaker 1>sitting in memory holding state is kind of useless.

179
00:09:06.440 --> 00:09:07.799
<v Speaker 2>Right, reboring app Yeah?

180
00:09:07.919 --> 00:09:09.519
<v Speaker 1>Right. The whole point of state is that it reacts

181
00:09:09.559 --> 00:09:11.799
<v Speaker 1>to verbs, which means we have to talk about how

182
00:09:11.840 --> 00:09:15.519
<v Speaker 1>Swift handles the actual work. You know the functions, right.

183
00:09:15.440 --> 00:09:19.360
<v Speaker 2>If variables and instances are the nouns, functions are the

184
00:09:19.360 --> 00:09:21.799
<v Speaker 2>heavy machinery that processes those nouns.

185
00:09:21.840 --> 00:09:25.159
<v Speaker 1>Okay, Let's take the classic textbook analogy the function as

186
00:09:25.159 --> 00:09:27.559
<v Speaker 1>a machine. So you have a funnel on top for

187
00:09:27.639 --> 00:09:30.679
<v Speaker 1>the inputs the parameters, you have the gears inside doing

188
00:09:30.720 --> 00:09:33.519
<v Speaker 1>the logic, and you have a tube at the bottom

189
00:09:33.679 --> 00:09:35.320
<v Speaker 1>spitting out the return value.

190
00:09:35.559 --> 00:09:36.919
<v Speaker 2>A perfect mental image.

191
00:09:36.960 --> 00:09:40.679
<v Speaker 1>But Swift does something incredibly clever with the funnel. It

192
00:09:40.759 --> 00:09:44.759
<v Speaker 1>separates the public interface from the private implementation by using

193
00:09:44.840 --> 00:09:47.200
<v Speaker 1>external and internal parameter names.

194
00:09:47.279 --> 00:09:51.159
<v Speaker 2>Yeah, and this is a feature entirely dedicated to developer readability.

195
00:09:51.519 --> 00:09:54.240
<v Speaker 2>When you define a function's parameters, you can give one

196
00:09:54.360 --> 00:09:57.639
<v Speaker 2>name to be used externally by whatever is calling the function,

197
00:09:58.080 --> 00:10:00.559
<v Speaker 2>and a completely different name to be used innally within

198
00:10:00.600 --> 00:10:02.000
<v Speaker 2>the gears of the function itself.

199
00:10:02.200 --> 00:10:05.799
<v Speaker 1>So what does this all mean? Having external and internal

200
00:10:05.840 --> 00:10:09.120
<v Speaker 1>parameter names is basically like running a restaurant, isn't it? Oh?

201
00:10:09.200 --> 00:10:10.159
<v Speaker 2>I like where this is going?

202
00:10:10.519 --> 00:10:15.360
<v Speaker 1>The external name is the fancy, beautifully described dish on

203
00:10:15.399 --> 00:10:18.919
<v Speaker 1>the menu that the customer orders, but the internal name

204
00:10:19.279 --> 00:10:21.919
<v Speaker 1>is the shorthand slang the cooks yelled to each other

205
00:10:21.960 --> 00:10:24.200
<v Speaker 1>in the kitchen to actually get the dish made.

206
00:10:24.360 --> 00:10:26.039
<v Speaker 2>That is a brilliant way to conceptualize it.

207
00:10:26.120 --> 00:10:26.639
<v Speaker 1>Yeah. Yeah.

208
00:10:26.679 --> 00:10:30.720
<v Speaker 2>The book uses the example of an echo function. Externally,

209
00:10:30.960 --> 00:10:36.159
<v Speaker 2>the function signature might read echo string high times three.

210
00:10:36.279 --> 00:10:37.519
<v Speaker 2>It reads almost like plain.

211
00:10:37.320 --> 00:10:40.480
<v Speaker 1>English right, super clear, But internally.

212
00:10:40.039 --> 00:10:42.279
<v Speaker 2>Typing out the word times over and over in some

213
00:10:42.440 --> 00:10:46.720
<v Speaker 2>complex mathematical algorithm is tedious, So internally the developer might

214
00:10:46.799 --> 00:10:50.919
<v Speaker 2>just label that parameter in the public API remains incredibly

215
00:10:50.960 --> 00:10:54.960
<v Speaker 2>expressive and clear, while the internal logic remains concise.

216
00:10:55.039 --> 00:10:57.600
<v Speaker 1>And because of the strictness of the compiler, Swift allows

217
00:10:57.639 --> 00:11:00.559
<v Speaker 1>for function overloading like you can have two totally different

218
00:11:00.600 --> 00:11:03.279
<v Speaker 1>machines in the factory with the exact same name, say

219
00:11:03.360 --> 00:11:05.519
<v Speaker 1>a function called process, as long as the funnels are

220
00:11:05.519 --> 00:11:08.600
<v Speaker 1>shaped different exactly. One process function might expect a string,

221
00:11:08.840 --> 00:11:11.480
<v Speaker 1>another might expect an integer. You just drop your data

222
00:11:11.519 --> 00:11:13.240
<v Speaker 1>and in The compiler is smart enough to route it

223
00:11:13.279 --> 00:11:16.559
<v Speaker 1>to the correct machine based solely on the data type.

224
00:11:16.240 --> 00:11:18.879
<v Speaker 2>And it can only do that because of the absolute

225
00:11:18.879 --> 00:11:21.519
<v Speaker 2>certainty we talked about earlier. It knows a string is

226
00:11:21.559 --> 00:11:25.120
<v Speaker 2>not an integer, so there's no ambiguity. But that strictness

227
00:11:25.399 --> 00:11:29.399
<v Speaker 2>also applies to what happens inside the machine. By default,

228
00:11:29.600 --> 00:11:32.919
<v Speaker 2>parameters passed into a function are constants. They are those

229
00:11:32.960 --> 00:11:34.200
<v Speaker 2>superglued shoe boxes.

230
00:11:34.480 --> 00:11:35.360
<v Speaker 1>Oh interesting.

231
00:11:35.639 --> 00:11:37.519
<v Speaker 2>Yeah, the function can look at the data, it can

232
00:11:37.600 --> 00:11:40.120
<v Speaker 2>use the data to calculate a new result, but it

233
00:11:40.320 --> 00:11:44.840
<v Speaker 2>absolutely cannot change the original data outside the function, unless.

234
00:11:44.559 --> 00:11:48.519
<v Speaker 1>You explicitly break that rule with the inout parameter. Yes,

235
00:11:48.639 --> 00:11:50.840
<v Speaker 1>the book notes that if you actually want a function

236
00:11:51.039 --> 00:11:53.600
<v Speaker 1>to modify a variable from the outside world to alter

237
00:11:53.720 --> 00:11:56.559
<v Speaker 1>the original shoebox, you can't just pass the value. You

238
00:11:56.639 --> 00:12:00.879
<v Speaker 1>have to pass the actual memory address in the using

239
00:12:00.919 --> 00:12:03.759
<v Speaker 1>an ampersand symbol the inner. If I want my function

240
00:12:03.840 --> 00:12:05.600
<v Speaker 1>to permanently alter my string I have to type in

241
00:12:05.639 --> 00:12:09.279
<v Speaker 1>my string. Why force this weird piece of punctuation, I mean,

242
00:12:09.320 --> 00:12:11.120
<v Speaker 1>why not just let it change?

243
00:12:11.600 --> 00:12:16.320
<v Speaker 2>Because you are passing by reference instead of passing by value.

244
00:12:16.399 --> 00:12:19.240
<v Speaker 2>Under the hood, you aren't handing the function a copy

245
00:12:19.240 --> 00:12:21.639
<v Speaker 2>of the data. You are handing it a pointer to

246
00:12:21.720 --> 00:12:24.799
<v Speaker 2>the exact physical location in memory where that data lives.

247
00:12:25.360 --> 00:12:28.559
<v Speaker 2>Modifying data outside of function's own scope is called a

248
00:12:28.639 --> 00:12:31.759
<v Speaker 2>side effect, and side effects are historically the root cause

249
00:12:32.080 --> 00:12:35.879
<v Speaker 2>of the most maddening bugs in software engineering. By forcing

250
00:12:35.919 --> 00:12:39.799
<v Speaker 2>you to physically type that out symbol, the compiler is

251
00:12:39.879 --> 00:12:42.759
<v Speaker 2>forcing you to sign a waiver. A waiver basically, yeah,

252
00:12:42.840 --> 00:12:45.799
<v Speaker 2>it's a bright yellow warning sign. You are explicitly acknowledging

253
00:12:45.840 --> 00:12:48.919
<v Speaker 2>at the exact moment you write the code caution, I'm

254
00:12:48.960 --> 00:12:51.960
<v Speaker 2>allowing this machine to reach outside of itself and permanently

255
00:12:52.000 --> 00:12:53.679
<v Speaker 2>alter the reality of the larger app.

256
00:12:53.720 --> 00:12:56.159
<v Speaker 1>It's audited correctness and action. Again, you can do the

257
00:12:56.240 --> 00:12:58.320
<v Speaker 1>dangerous thing, but you have to look the compiler in

258
00:12:58.320 --> 00:12:59.799
<v Speaker 1>the eye and say, I know this.

259
00:12:59.799 --> 00:13:01.120
<v Speaker 2>Is dangerous exactly.

260
00:13:01.519 --> 00:13:04.279
<v Speaker 1>Okay, So up to this point, we've treated these function

261
00:13:04.399 --> 00:13:07.279
<v Speaker 1>machines as heavy you know, bolted to the factory floor,

262
00:13:07.519 --> 00:13:10.919
<v Speaker 1>the data comes to them. But in Swift, these machines

263
00:13:10.919 --> 00:13:14.600
<v Speaker 1>have wheels. They can morph, shrink into a briefcase, and

264
00:13:14.600 --> 00:13:15.600
<v Speaker 1>travel across the app.

265
00:13:15.720 --> 00:13:18.559
<v Speaker 2>Yeah, this is where Swift bridges the gap into being

266
00:13:18.679 --> 00:13:23.320
<v Speaker 2>a modern functional programming language. Functions in Swift are what

267
00:13:23.360 --> 00:13:25.600
<v Speaker 2>we call first class citizens.

268
00:13:25.360 --> 00:13:28.440
<v Speaker 1>Which means a function isn't just an action, it is

269
00:13:28.559 --> 00:13:31.279
<v Speaker 1>a value in and of itself. Like. You can treat

270
00:13:31.320 --> 00:13:34.720
<v Speaker 1>a function exactly like you would treat a string of text. Right,

271
00:13:34.799 --> 00:13:37.679
<v Speaker 1>You can assign an entire function to a variable. You

272
00:13:37.720 --> 00:13:40.600
<v Speaker 1>can pass a function into the funnel of another function.

273
00:13:41.039 --> 00:13:44.120
<v Speaker 1>And when you do that, Swift allows you to aggressively

274
00:13:44.159 --> 00:13:46.360
<v Speaker 1>shrink the syntax into anonymous function.

275
00:13:46.519 --> 00:13:48.159
<v Speaker 2>Yes, the infamous anonymous function.

276
00:13:48.320 --> 00:13:50.759
<v Speaker 1>Right. If you just need a tiny piece of logic,

277
00:13:50.919 --> 00:13:53.559
<v Speaker 1>you can strip away the function's name, the return type,

278
00:13:53.600 --> 00:13:56.399
<v Speaker 1>the parentheses, even the parameter names. You replace them with

279
00:13:56.440 --> 00:13:58.600
<v Speaker 1>this magic shorthand like zero dollars, and.

280
00:13:58.600 --> 00:14:01.440
<v Speaker 2>It is incredibly jarring if you weren't used to it.

281
00:14:01.720 --> 00:14:05.159
<v Speaker 2>You go from this beautifully readable English like syntax with

282
00:14:05.240 --> 00:14:09.799
<v Speaker 2>external parameter names to something that looks like cryptic mathematical shorthand.

283
00:14:09.919 --> 00:14:10.320
<v Speaker 1>Totally.

284
00:14:10.360 --> 00:14:12.840
<v Speaker 2>A massive block of code might be reduced to just

285
00:14:13.000 --> 00:14:15.080
<v Speaker 2>curly braces and zero twos, And.

286
00:14:15.120 --> 00:14:17.840
<v Speaker 1>Honestly, isn't that a problem? Like I totally get why

287
00:14:17.840 --> 00:14:20.519
<v Speaker 1>brevity is nice for seasoned developers who want to type less.

288
00:14:20.840 --> 00:14:22.960
<v Speaker 1>But if we strip away all the context and just

289
00:14:23.039 --> 00:14:26.399
<v Speaker 1>leave a cryptic zero dollar floating in some curly braces,

290
00:14:26.919 --> 00:14:29.879
<v Speaker 1>aren't we sacrificing the readability swift is supposed to be

291
00:14:29.879 --> 00:14:30.480
<v Speaker 1>famous for.

292
00:14:30.639 --> 00:14:31.320
<v Speaker 2>That's a fair point.

293
00:14:31.360 --> 00:14:34.799
<v Speaker 1>Doesn't this create boilerplate that is actively hostile to a

294
00:14:34.840 --> 00:14:37.080
<v Speaker 1>beginner trying to read someone else's code.

295
00:14:37.200 --> 00:14:40.279
<v Speaker 2>It's a very common critique when developers first encounter it.

296
00:14:40.679 --> 00:14:43.399
<v Speaker 2>But the philosophy here isn't about brevity just for the

297
00:14:43.440 --> 00:14:47.440
<v Speaker 2>sake of typing less. It's about elevating the signal by

298
00:14:47.480 --> 00:14:48.360
<v Speaker 2>removing the noise.

299
00:14:48.480 --> 00:14:49.840
<v Speaker 1>Okay, unpack that for it.

300
00:14:49.919 --> 00:14:53.799
<v Speaker 2>Sure, So, when you have a function that exists solely

301
00:14:53.840 --> 00:14:56.720
<v Speaker 2>to be passed into another function, for instance, a tiny

302
00:14:56.720 --> 00:15:00.320
<v Speaker 2>sorting algorithm to alphabetize a list, writing out the full

303
00:15:00.399 --> 00:15:05.200
<v Speaker 2>funneling gear syntax actually creates boilerplate. It distracts you from

304
00:15:05.200 --> 00:15:09.559
<v Speaker 2>the pure logic. Zero dollars simply means the first argument

305
00:15:09.679 --> 00:15:14.000
<v Speaker 2>handed to this block. Once you internalize that vocabulary, the

306
00:15:14.039 --> 00:15:18.519
<v Speaker 2>developer's pure intent shines through without getting bogged down in syntax.

307
00:15:19.559 --> 00:15:22.360
<v Speaker 2>But more importantly, whether they are fully written out or

308
00:15:22.399 --> 00:15:25.840
<v Speaker 2>shrunk down to zero dollars, these traveling functions possess a

309
00:15:25.879 --> 00:15:29.519
<v Speaker 2>massive architectural superpower, which is they act its closures.

310
00:15:29.559 --> 00:15:33.080
<v Speaker 1>Closures right, the idea that a function captures its environment,

311
00:15:33.759 --> 00:15:35.960
<v Speaker 1>Let's really dig into what that actually means, because this

312
00:15:36.000 --> 00:15:38.759
<v Speaker 1>is where the architecture feels like literal magic.

313
00:15:39.039 --> 00:15:41.559
<v Speaker 2>It does feel like magic. So when you pass a

314
00:15:41.600 --> 00:15:45.000
<v Speaker 2>function across your app, say you pass a chunk of

315
00:15:45.000 --> 00:15:47.840
<v Speaker 2>logic to a background thread to download an image, and

316
00:15:47.879 --> 00:15:50.080
<v Speaker 2>you tell it to update the UI when it's done,

317
00:15:50.480 --> 00:15:53.679
<v Speaker 2>that function doesn't travel alone. It physically packs up its

318
00:15:53.720 --> 00:15:54.320
<v Speaker 2>current reality.

319
00:15:54.399 --> 00:15:55.279
<v Speaker 1>It's like a time capsule.

320
00:15:55.399 --> 00:15:55.559
<v Speaker 2>Yeah.

321
00:15:55.720 --> 00:15:59.080
<v Speaker 1>Let's say Fido's bark function relies on a specific variable

322
00:15:59.120 --> 00:16:01.519
<v Speaker 1>called what this says that exists right now in the

323
00:16:01.519 --> 00:16:04.279
<v Speaker 1>specific context. Okay, Yeah, If you pass that bark function

324
00:16:04.320 --> 00:16:06.600
<v Speaker 1>to a completely different part of the app, where Fido

325
00:16:06.759 --> 00:16:11.000
<v Speaker 1>and that variable don't natively exist, the function doesn't crash, right, No,

326
00:16:11.120 --> 00:16:13.759
<v Speaker 1>it does. It secretly captures a reference to what this

327
00:16:13.919 --> 00:16:17.159
<v Speaker 1>dog says, packs it into a little invisible bubble, and

328
00:16:17.240 --> 00:16:19.080
<v Speaker 1>carries it across the progress.

329
00:16:18.639 --> 00:16:23.519
<v Speaker 2>Exactly, the compiler dynamically manages the memory to ensure that

330
00:16:23.600 --> 00:16:27.279
<v Speaker 2>anything the closure needs to survive is kept alive, even

331
00:16:27.279 --> 00:16:29.919
<v Speaker 2>if the original environment it was created in has been

332
00:16:29.960 --> 00:16:33.600
<v Speaker 2>completely destroyed. That is wild. It takes a snapshot of

333
00:16:33.639 --> 00:16:36.080
<v Speaker 2>the state it needs, and it holds onto those memory

334
00:16:36.080 --> 00:16:39.159
<v Speaker 2>addresses so it can be opened and executed ten minutes later,

335
00:16:39.360 --> 00:16:42.440
<v Speaker 2>just flawlessly. You can even write one of these closures

336
00:16:42.440 --> 00:16:46.159
<v Speaker 2>in curly braces and immediately trigger it by slapping parentheses

337
00:16:46.200 --> 00:16:46.799
<v Speaker 2>on the end.

338
00:16:46.799 --> 00:16:48.480
<v Speaker 1>The define and call pattern.

339
00:16:48.600 --> 00:16:52.399
<v Speaker 2>Yes, it allows for incredibly dynamic fluid code execution.

340
00:16:52.799 --> 00:16:55.720
<v Speaker 1>But wait, if these closures are secretly holding onto memory

341
00:16:55.720 --> 00:16:58.440
<v Speaker 1>addresses from across the app just carrying them around, doesn't

342
00:16:58.480 --> 00:17:01.240
<v Speaker 1>that inherently risk the exact kind of chaos we were

343
00:17:01.279 --> 00:17:02.080
<v Speaker 1>trying to avoid.

344
00:17:02.159 --> 00:17:04.519
<v Speaker 2>And that is the genius of the entire system coming

345
00:17:04.599 --> 00:17:07.480
<v Speaker 2>full circle. The strictness we talked about at the very beginning,

346
00:17:07.480 --> 00:17:11.079
<v Speaker 2>the superglued chee doxes, the absolute requirement of in four

347
00:17:11.119 --> 00:17:13.960
<v Speaker 2>side effects, the rigid encapsulation of state with self, and

348
00:17:14.319 --> 00:17:18.160
<v Speaker 2>all of that foundational safety is exactly what allows Swift

349
00:17:18.240 --> 00:17:21.079
<v Speaker 2>to give you the flexibility of traveling time capsules.

350
00:17:20.640 --> 00:17:21.839
<v Speaker 1>Because it knows it won't break.

351
00:17:22.039 --> 00:17:26.359
<v Speaker 2>Exactly. If the foundation wasn't rock solid, Passing shape shifting

352
00:17:26.400 --> 00:17:29.720
<v Speaker 2>memory capturing closures across a multi threaded app would result

353
00:17:29.799 --> 00:17:34.000
<v Speaker 2>in catastrophic memory leaks and race conditions. The strictness is

354
00:17:34.039 --> 00:17:35.839
<v Speaker 2>the prerequisite for the freedom.

355
00:17:35.640 --> 00:17:39.799
<v Speaker 1>That is profound. The micromanager is literally what lets you fly? Yep,

356
00:17:40.160 --> 00:17:43.119
<v Speaker 1>we really have decoded the blueprints today. We saw how

357
00:17:43.160 --> 00:17:46.559
<v Speaker 1>the strictness of let optimizes memory and thread safety under

358
00:17:46.599 --> 00:17:50.519
<v Speaker 1>the hood. We explored the radical simplification of treating everything

359
00:17:50.599 --> 00:17:53.480
<v Speaker 1>you know, even the number one, as an object, passing

360
00:17:53.480 --> 00:17:57.839
<v Speaker 1>messages with the LVM compiler just stripping away the overhead.

361
00:17:57.359 --> 00:17:58.680
<v Speaker 2>Which is still my favorite part.

362
00:17:58.960 --> 00:18:02.759
<v Speaker 1>It's so cool. And we saw how blueprints youself as

363
00:18:02.799 --> 00:18:06.200
<v Speaker 1>a psychological anchor to protect their state. And finally we

364
00:18:06.279 --> 00:18:09.880
<v Speaker 1>unpacked how functions aren't just static machines, but closures that

365
00:18:10.079 --> 00:18:13.359
<v Speaker 1>capture their reality safely traveling across the app. Because the

366
00:18:13.400 --> 00:18:16.319
<v Speaker 1>foundational rules are just so unbreakable, it.

367
00:18:16.240 --> 00:18:19.599
<v Speaker 2>Bridges the gap perfectly. I mean, it satisfies the brutal,

368
00:18:19.880 --> 00:18:25.319
<v Speaker 2>uncompromising logic required by the machine processor while simultaneously providing

369
00:18:25.640 --> 00:18:30.119
<v Speaker 2>an incredibly expressive fluid interface for the human developer trying

370
00:18:30.119 --> 00:18:31.640
<v Speaker 2>to solve organic problems.

371
00:18:31.720 --> 00:18:33.759
<v Speaker 1>It really does, and it leaves me with a final

372
00:18:33.799 --> 00:18:36.880
<v Speaker 1>thought for you, our listener to mull Over. We've spent

373
00:18:36.920 --> 00:18:39.480
<v Speaker 1>this time talking about software architecture, but think about how

374
00:18:39.480 --> 00:18:42.279
<v Speaker 1>you organize your own life, your own workflows, or your

375
00:18:42.319 --> 00:18:43.000
<v Speaker 1>team structure.

376
00:18:43.119 --> 00:18:43.559
<v Speaker 2>Oh like this.

377
00:18:43.839 --> 00:18:46.680
<v Speaker 1>Do you operate like those old school, rigid top down

378
00:18:46.720 --> 00:18:50.200
<v Speaker 1>scripts where every variable is exposed, every threat is tangled,

379
00:18:50.200 --> 00:18:54.160
<v Speaker 1>and changing one thing breaks everything else? Or could you

380
00:18:54.200 --> 00:18:57.839
<v Speaker 1>benefit from the swift philosophy? What if you built flexible

381
00:18:58.039 --> 00:19:03.759
<v Speaker 1>encapsulated objects like specif habits, dedicated systems, or clear team

382
00:19:03.839 --> 00:19:06.319
<v Speaker 1>roles that strictly maintain their own state and mind their

383
00:19:06.359 --> 00:19:10.160
<v Speaker 1>own business. What if you super glue the foundational rules

384
00:19:10.160 --> 00:19:13.039
<v Speaker 1>that shouldn't change so that your team had the ultimate

385
00:19:13.079 --> 00:19:16.279
<v Speaker 1>creative freedom to pass ideas into new environments without the

386
00:19:16.279 --> 00:19:17.480
<v Speaker 1>whole system collapsing.

387
00:19:17.680 --> 00:19:21.359
<v Speaker 2>Applying the concept of strict state encapsulation to human workflows,

388
00:19:21.799 --> 00:19:26.440
<v Speaker 2>it's an incredibly powerful framework for minimizing friction and avoiding burnout,

389
00:19:26.720 --> 00:19:29.319
<v Speaker 2>not just in code, but in how we work together.

390
00:19:29.519 --> 00:19:31.759
<v Speaker 1>Thank you so much for joining us on this deep dive.

391
00:19:32.000 --> 00:19:34.079
<v Speaker 1>You are now armed with a powerful new way to

392
00:19:34.160 --> 00:19:37.680
<v Speaker 1>understand the unseen philosophy powering the digital tools you interact

393
00:19:37.720 --> 00:19:40.039
<v Speaker 1>with every single day. And the next time you are

394
00:19:40.079 --> 00:19:43.240
<v Speaker 1>faced with a complex system that feels incredibly rigid and demanding,

395
00:19:43.680 --> 00:19:45.920
<v Speaker 1>remember to look for the cheat code, look for the

396
00:19:45.960 --> 00:19:48.880
<v Speaker 1>freedom hidden underneath the strictness. Until next time.