1
00:00:00,001 --> 00:00:07,040
Happy New Year! Yes, Happy New Year! We had a rather delayed start to podcasting in 2025,

2
00:00:07,040 --> 00:00:12,240
but here we are back again. Yeah, we had a nice, longish Christmas break,

3
00:00:12,240 --> 00:00:20,000
at least when it comes to the podcast. But lots has been happening while we've been away,

4
00:00:20,000 --> 00:00:25,040
so we should catch up with a few announcements. Actually, there's one announcement which happened,

5
00:00:25,600 --> 00:00:31,760
I think it was maybe even yesterday as we record this, which is a... So there's obviously a whole

6
00:00:31,760 --> 00:00:38,560
load of Swift working groups that have been created and have been running for the last few

7
00:00:38,560 --> 00:00:44,880
years. Things from like the Swift website work group is one that I'm a member of. There's a

8
00:00:44,880 --> 00:00:49,680
Swift documentation work group, which both of us are members of. There's lots of these working

9
00:00:49,680 --> 00:00:56,160
groups that have... There's a contributor experience one, I think, and probably some...

10
00:00:56,160 --> 00:00:59,920
Oh, there's the diversity work group as well. So there's lots of these work groups that are going

11
00:00:59,920 --> 00:01:08,240
on. And so far, they've all been organized by the Swift team. But I noticed a post yesterday,

12
00:01:08,240 --> 00:01:16,080
which was the announcement of a community working group. So it is a Swift on Android

13
00:01:16,080 --> 00:01:28,800
community work group organized by Yuenos Orlandos. And it's intending to, I guess,

14
00:01:28,800 --> 00:01:36,320
either be a precursor to an official one or just for it to exist on its own, with the goal of

15
00:01:36,320 --> 00:01:44,160
promoting and working towards broader and faster adoption for Swift on Android.

16
00:01:44,160 --> 00:01:48,880
Yeah, I was actually wondering if that's an official group or what even makes an

17
00:01:48,880 --> 00:01:57,040
official group. It sounded like this was a group as a peer to the other groups. But I guess community

18
00:01:57,040 --> 00:02:00,000
work group is slightly different. It's a bit unclear. But then again, I mean...

19
00:02:00,000 --> 00:02:05,520
Maybe I've assumed it's less official than it is. The only reason that made me make that

20
00:02:05,520 --> 00:02:11,360
assumption is because it was called a community work group, which I guessed was being organized

21
00:02:11,360 --> 00:02:14,560
without the involvement of the Swift team, although they may be involved.

22
00:02:14,560 --> 00:02:18,560
Well, certainly, if you look through the announcement post, the replies, I think

23
00:02:18,560 --> 00:02:28,240
immediately people started being active and interested in contributing, especially people

24
00:02:28,240 --> 00:02:31,280
from other working groups, the platform steering group.

25
00:02:31,280 --> 00:02:36,720
Ah, yes, there have been more posts since I checked it yesterday.

26
00:02:36,720 --> 00:02:42,160
Yeah, yeah, there's a lot going on. Really interesting. And I think it sort of also

27
00:02:42,160 --> 00:02:47,440
highlights that Android is looking at the activity. It seems to indicate that Android is

28
00:02:47,440 --> 00:02:52,560
an interesting additional platform. It seems there's quite a bit of interest in

29
00:02:52,560 --> 00:02:58,800
getting this off the ground. And yeah, maybe that's... I mean, some of this is...

30
00:02:58,800 --> 00:03:06,400
So two members are Mark Prudhommeau and Abe White of SkipTools. And you had this in iOS Dev Weekly

31
00:03:06,400 --> 00:03:08,000
recently, right? Yes.

32
00:03:08,000 --> 00:03:16,160
Mark Prudhommeau's compatibility page where he's testing Android compatibility of packages.

33
00:03:16,160 --> 00:03:21,520
It's actually, I think, based on our package list, a subset of it at least.

34
00:03:21,520 --> 00:03:24,160
I believe it is, yeah.

35
00:03:24,160 --> 00:03:32,720
And I think there's value in considering whether we should start running Android tests. And maybe

36
00:03:32,720 --> 00:03:38,480
that's an indication of the amount of activity there and how well that's being received, whether

37
00:03:38,480 --> 00:03:44,080
that's the next platform, one of the next platforms we should be looking at.

38
00:03:44,080 --> 00:03:50,800
Yeah, I think it's always good to see people interested in bringing it to more platforms.

39
00:03:50,800 --> 00:03:56,480
And to see people organize like this and kind of put some structure to it is even better.

40
00:03:58,080 --> 00:04:05,360
And like you say, Mark and Abe from SkipTools, I'm very happy and not surprised to see them

41
00:04:05,360 --> 00:04:13,440
involved in this because their product is also entirely around bringing apps

42
00:04:13,440 --> 00:04:15,680
written in Swift to Android.

43
00:04:15,680 --> 00:04:16,720
Yeah, absolutely.

44
00:04:16,720 --> 00:04:23,200
So that's great. I mean, I think it's always nice to see community or maybe it is official,

45
00:04:23,200 --> 00:04:28,480
maybe you're right that this is exactly an official work group, but it's just got a different

46
00:04:28,480 --> 00:04:28,980
word in it.

47
00:04:28,980 --> 00:04:35,200
Or it might be a precursor and become one. It's not entirely clear from the announcement. But

48
00:04:35,200 --> 00:04:39,760
again, I mean, does it really matter all that much? I think the point is that there's a group

49
00:04:39,760 --> 00:04:46,960
that deals with, sort of pulls all the different bits and pieces together, because there have been

50
00:04:46,960 --> 00:04:52,320
a couple of efforts in the past targeting Android. And I think it's great to see that this is just

51
00:04:52,320 --> 00:04:59,440
like becoming a joint effort where this is going to be turning into a proper SDK with proper

52
00:04:59,440 --> 00:05:04,720
support and all that, and a group of people who look after it. Good to see.

53
00:05:04,720 --> 00:05:13,120
And it's also great to see that the, as you say, the people in that thread, there are a mix of

54
00:05:13,120 --> 00:05:21,120
Apple people, or should I say Swift team people and community members. So it's great to see,

55
00:05:21,120 --> 00:05:25,120
even if this is not an official work group, it's great to see the Apple people immediately

56
00:05:25,120 --> 00:05:27,600
getting involved, which is just lovely to see.

57
00:05:27,600 --> 00:05:35,200
Yeah, yeah, absolutely. Right. There's been another bit of news quite recently at Fosdem.

58
00:05:35,200 --> 00:05:41,280
That was the Swift build announcement. I think you had some notes on that, didn't you?

59
00:05:42,080 --> 00:05:54,560
Yeah, I think this is a very exciting project. It's been a thorn in Swift's side for a little

60
00:05:54,560 --> 00:06:00,720
while now that there are effectively two entire build systems. One, which is Xcode build, which

61
00:06:00,720 --> 00:06:05,680
is part of Xcode, either running through the Xcode application itself or running through the

62
00:06:05,680 --> 00:06:11,280
command line tool Xcode build. And then there is the entirely different Swift build command,

63
00:06:11,280 --> 00:06:21,200
which is not as capable in terms of trying to build every type of product that Xcode can build,

64
00:06:21,200 --> 00:06:29,920
but is cross platform compatible and works on Linux and works everywhere. And so they both have

65
00:06:29,920 --> 00:06:38,400
advantages. And one of the artifacts of having to build systems for Swift is a little bit of

66
00:06:38,400 --> 00:06:43,200
complexity that we've had to put into the Swift package index, which is in order to determine

67
00:06:43,200 --> 00:06:49,760
macOS compatibility for a package, we have to attempt both the Swift build and an Xcode build,

68
00:06:49,760 --> 00:06:54,880
because some packages will build with Swift build and some packages will build with Xcode.

69
00:06:54,880 --> 00:07:01,040
And it's not necessarily the case that they'll always build with either one of those two. So

70
00:07:01,040 --> 00:07:05,600
you have to kind of do both to get compatibility. So we've been in this situation where we've got

71
00:07:05,600 --> 00:07:13,840
these two build systems, and that is really less than ideal. And as I understand it, the primary

72
00:07:13,840 --> 00:07:20,960
purpose of Swift build is to get one unified build system across both of those situations.

73
00:07:20,960 --> 00:07:27,680
Yeah, I just can't wait for this to be fully unified. And obviously, we won't be able to drop

74
00:07:27,680 --> 00:07:34,800
our running of two builds in parallel with Swift build and Xcode build for a while. But

75
00:07:34,800 --> 00:07:42,240
at least there's now a future where we can delete all that duplication and extra maintenance stuff.

76
00:07:42,240 --> 00:07:47,680
Is it actually the case that we may have to in fact run three builds for a little while?

77
00:07:47,680 --> 00:07:56,800
Oh God, no, no, no, no, no, no. I think the minute this is sort of switched on, which is,

78
00:07:56,800 --> 00:08:04,400
I presume that that would be a WWDC announcement that this is the now official build system.

79
00:08:04,880 --> 00:08:11,360
For what is it going to be Swift 6.2, I suppose. I think at that point,

80
00:08:11,360 --> 00:08:12,880
And Xcode 17.

81
00:08:12,880 --> 00:08:20,000
Yeah, I think at that point, we do whatever is the default. But there has to be a date when it's the

82
00:08:20,000 --> 00:08:24,720
default. And I think that's the date for us to sort of unify it. And then we just have to wait

83
00:08:24,720 --> 00:08:30,480
for the older Swift versions to drop off the matrix. And then we can finally delete the

84
00:08:32,240 --> 00:08:38,160
duplication of running these builds and builds and the documentation generation, which is also

85
00:08:38,160 --> 00:08:42,400
sort of, you know, we have to maintain two different ways of doing that. And it's just,

86
00:08:42,400 --> 00:08:46,080
I'm just super glad about this.

87
00:08:46,080 --> 00:08:53,280
Even if we won't be running three builds per package, we may end up running three build

88
00:08:53,280 --> 00:09:01,760
systems for a while because for the Xcode 17, Swift 6.x, whatever that is, that will need the

89
00:09:01,760 --> 00:09:06,800
new build system and the old two, as you say, will be there for previous versions until they

90
00:09:06,800 --> 00:09:09,520
drop off, which is probably several years away.

91
00:09:09,520 --> 00:09:11,840
Well, my hope is...

92
00:09:11,840 --> 00:09:17,840
Complexity gets worse for a little bit, but this is in the pursuit of a better solution. So I'm

93
00:09:17,840 --> 00:09:19,280
still happy to see it.

94
00:09:19,280 --> 00:09:24,240
Yeah, absolutely. Plus, from what I've seen, it's effectively a flag on Swift build, I believe,

95
00:09:24,240 --> 00:09:30,880
to use the new build system, obviously, with a corresponding toolchain. And I think an Xcode

96
00:09:30,880 --> 00:09:37,120
build might even have the same that you can use Xcode build as the front end to use the build

97
00:09:37,120 --> 00:09:44,400
system. I'm not sure how Swift, like the Apple platforms would work, because right now you can't

98
00:09:44,400 --> 00:09:51,920
really build for iOS and to be US and stuff with Swift build. But I suppose all this will sort of

99
00:09:51,920 --> 00:09:59,200
be part of that. I mean, this, the open sourcing of Swift build is sort of, I think, a requirement

100
00:09:59,200 --> 00:10:09,440
to actually have Swift packages that you use, you know, that you build iOS apps from, like you do

101
00:10:09,440 --> 00:10:16,720
with Swift build, which you right now need to use Xcode for. So there has to be a world where this

102
00:10:16,720 --> 00:10:21,040
is also unified. And I suppose this is the first step towards that. Well, certainly I hope that's

103
00:10:21,040 --> 00:10:24,400
the case, because otherwise we have gained nothing.

104
00:10:25,360 --> 00:10:31,760
Right. Yeah. No, I'm confident that what you laid out there is their intention.

105
00:10:31,760 --> 00:10:34,960
Yeah. Let's see what happens in June.

106
00:10:34,960 --> 00:10:40,640
Exciting times for build systems on Swift. It's not a topic that a lot of people

107
00:10:40,640 --> 00:10:44,960
imagine that they'll care a lot about. But here we are.

108
00:10:44,960 --> 00:10:46,320
Here we are.

109
00:10:46,320 --> 00:10:54,880
There's another bit of news, which is a bit older. I had this in my notes for a while. That was an

110
00:10:54,880 --> 00:11:02,720
interesting forum thread on the Swift forums about open source funding. This was opened by Taylor

111
00:11:02,720 --> 00:11:11,680
Swift, user Taylor Swift, Diana on the Swift forums. And this is interesting in itself. So

112
00:11:11,680 --> 00:11:19,040
Diana, you know, raises some or brings up some thoughts on how open source can be funded and

113
00:11:19,040 --> 00:11:26,720
maintained so such that it's not just on free labor of people who are volunteering their time

114
00:11:26,720 --> 00:11:32,320
to work on stuff. But I also noticed an interesting link in that thread. So the thread is from

115
00:11:32,320 --> 00:11:40,080
December. And someone brought up a bounty platform that's being used by tourists, apparently, and

116
00:11:40,080 --> 00:11:48,160
it's called Algora. And a person jumped in the thread and said they've actually updated the

117
00:11:48,160 --> 00:11:58,320
platform to be Swift specific. So I think there's some Swift specific stuff. And there's swift.algora.io

118
00:11:58,320 --> 00:12:09,280
is the homepage. And it's a bounty and tipping platform where you can use GitHub commands to

119
00:12:09,280 --> 00:12:16,880
put up bounties and give tips inside issues and pull requests. So you could have an issue

120
00:12:17,520 --> 00:12:22,160
where you do a slash bounty and then a dollar amount or equally have an issue and you do slash

121
00:12:22,160 --> 00:12:30,400
tip dollar amount and username and tip someone an amount of money, which I found really,

122
00:12:30,400 --> 00:12:34,080
really interesting, like an interesting way to get funding into an open source project.

123
00:12:34,080 --> 00:12:39,600
Also slightly, you know, what makes me a bit nervous that there's a slash command where you can

124
00:12:39,600 --> 00:12:46,480
just spend money like real money that seems like super, super easy. But then again, that's the

125
00:12:46,480 --> 00:12:54,560
point, right? To make it easy for people to actually fund stuff. And I thought that's really

126
00:12:54,560 --> 00:13:00,240
interesting, maybe to think about and talk about and see if that's something you could use. I think

127
00:13:00,240 --> 00:13:07,760
often, and we've talked about this in the past, the problem is not that companies don't have the

128
00:13:07,760 --> 00:13:14,000
money or even the willingness to fund open source work. It's the how, right? There's a

129
00:13:14,880 --> 00:13:21,920
how do I get the credit card into the right person's hands to then make a payment to the

130
00:13:21,920 --> 00:13:28,480
maintainer? It's really strange or often difficult that an open source maintainer doesn't have a

131
00:13:28,480 --> 00:13:34,000
company set up, doesn't have a billing set up and I can't really get to the money that might even be

132
00:13:34,000 --> 00:13:39,040
there. It's this disconnect between, you know, there's a service that's being offered effectively

133
00:13:39,040 --> 00:13:45,920
and needed, but the person who needs it doesn't really control the money and needs to get

134
00:13:45,920 --> 00:13:50,480
approval from somewhere. And, you know, big companies, that's often a huge headache.

135
00:13:50,480 --> 00:13:57,600
It's easy to buy a book or to fly to a conference and then get money into a maintainer's hand is

136
00:13:57,600 --> 00:14:02,240
effectively what I'm trying to say. And if maybe if companies were set up to be able to

137
00:14:02,240 --> 00:14:08,400
have a pool of money for bounties, and then, you know, certain members of the team who

138
00:14:08,400 --> 00:14:14,960
control that and could dole that out that way, that might even be interesting or might be a

139
00:14:14,960 --> 00:14:21,040
good approach to help fix this problem. - I think there's two sides of it. I think

140
00:14:21,040 --> 00:14:28,240
you're absolutely right that one of the sides is getting that credit card into the system,

141
00:14:28,240 --> 00:14:33,600
actually being able to make the payment. But the other part, especially as the companies that you're

142
00:14:33,600 --> 00:14:38,560
dealing with get bigger, the other part is having approval. So like people will have,

143
00:14:38,560 --> 00:14:43,200
like you mentioned, it's easy to get approval for a book or, you know, something like that,

144
00:14:43,200 --> 00:14:50,560
that will help you learn something because companies have in place the mechanism for

145
00:14:50,560 --> 00:14:55,840
staff training and that kind of thing. And so you can normally find a bucket to put stuff in.

146
00:14:55,840 --> 00:15:02,960
You can find a bucket to put almost everything you want in a company. And open source funding is

147
00:15:03,440 --> 00:15:08,000
there is no bucket for open source funding in most companies. - And that's the unfortunate thing,

148
00:15:08,000 --> 00:15:12,880
isn't it? - Yeah. And so it's all very easy for a company to wave their hand and say, "Oh yeah,

149
00:15:12,880 --> 00:15:18,480
we should support open source software." And it's a whole different thing to actually get to the

150
00:15:18,480 --> 00:15:24,240
point where getting that credit card is the problem. So you have to have that pre-credit

151
00:15:24,240 --> 00:15:31,360
card bit, which is the, well, let's make a bucket for open source funding. And that's obviously

152
00:15:31,360 --> 00:15:36,560
a much bigger and more difficult conversation inside most companies. I do think though,

153
00:15:36,560 --> 00:15:45,360
that just looking at this site, that this seems like a great way to do that second step in the

154
00:15:45,360 --> 00:15:53,680
chain. And I wonder if there's anything they can do, like, can they prepare, like, here's a kit

155
00:15:53,680 --> 00:15:59,280
that you can take to your, you know, your finance department to explain why you should support open

156
00:15:59,280 --> 00:16:04,800
source and get that first bit done as well. Because that's obviously, I think, the bigger of

157
00:16:04,800 --> 00:16:10,400
the two problems. Although I think this is great. - Yeah, I think it's a bit like, you know, at some

158
00:16:10,400 --> 00:16:17,200
point companies decided, well, it's actually helpful to have a training budget, you know,

159
00:16:17,200 --> 00:16:22,880
a conference budget. But companies at some point need to realize, well, it's actually not only

160
00:16:22,880 --> 00:16:28,160
helpful, but even critical to also have an open source maintenance budget because they're leaning

161
00:16:28,160 --> 00:16:35,360
on that work. And there's going to be a point where the risk is just going to be really high

162
00:16:35,360 --> 00:16:42,240
if stuff falls in disrepair and is being maintained. And I think it's about time that

163
00:16:42,240 --> 00:16:49,840
this gets on people's radar, that this is really critical. But there's another point I wanted to

164
00:16:49,840 --> 00:16:56,160
make, and I actually replied in the forum thread about this. And that's that this sort of stuff

165
00:16:56,160 --> 00:17:03,120
is often quite transactional in the sense that, and slash bounty is an example of it. I put a

166
00:17:03,120 --> 00:17:14,640
bounty on this issue. I think open source work doesn't always fall into a clear feature or a

167
00:17:14,640 --> 00:17:24,560
clear bug fix. Sometimes it's just maintenance. And that can be updating dependencies, updating CI,

168
00:17:25,120 --> 00:17:30,480
modernizing the code base, you know, with language or dependency changes, that stuff.

169
00:17:30,480 --> 00:17:37,920
A CVE popping up, and you know, you can't start a bounty program once the CVE has already happened,

170
00:17:37,920 --> 00:17:43,520
you sort of need to have someone there who knows the code base and can jump in and fix it. And

171
00:17:43,520 --> 00:17:50,640
there needs to be an understanding that there's just base level maintenance that needs to be

172
00:17:50,640 --> 00:17:55,760
paid. And that is doing these tasks that are listed, but also having someone who actually

173
00:17:55,760 --> 00:18:01,920
knows the code base, because you can't start ramping up when stuff is really urgent. You

174
00:18:01,920 --> 00:18:07,920
know, you sort of need to keep the engine running on some level to have actually people there who

175
00:18:07,920 --> 00:18:13,680
can make the changes. And I think that that sometimes gets overlooked in these discussions

176
00:18:13,680 --> 00:18:19,040
when open source is talked about, because it's about, you know, a next big feature,

177
00:18:19,040 --> 00:18:29,280
a big bug fix or stuff like that. And it just doesn't always come in nice little packages like

178
00:18:29,280 --> 00:18:35,760
that, if that makes sense. Yeah, I think that the maintenance point is really well made. And

179
00:18:35,760 --> 00:18:43,280
certainly, for some, you know, the more popular your open source project becomes, the more

180
00:18:43,280 --> 00:18:48,560
important things like that becomes, because it is impossible to ignore CVEs at some point,

181
00:18:48,560 --> 00:18:54,720
if you have an open source project, which has got significant usage out in the wild.

182
00:18:54,720 --> 00:19:05,280
But that's the kind of stuff that's really hard to get people to, like you say, it's hard to

183
00:19:05,840 --> 00:19:10,720
Yeah, that's not bounty work. That's, that's, that's work that you need. I guess that's what

184
00:19:10,720 --> 00:19:15,200
a core team is for, right? On most projects, most projects of any significant size have

185
00:19:15,200 --> 00:19:24,480
a core team of maintainers. And funding that core team of maintainers is, is a different problem.

186
00:19:24,480 --> 00:19:30,960
Which, yeah, I mean, open source funding, we could talk for hours on open source funding is,

187
00:19:30,960 --> 00:19:40,160
I think it's something we both have lots of thoughts on. But I'm glad to see any kind of

188
00:19:40,160 --> 00:19:45,280
initiative like this to help. And this one does look good. Yeah, let's see what comes of it.

189
00:19:45,280 --> 00:19:52,320
Yeah, absolutely. Before we get on to recommendations this week, there's just a

190
00:19:52,320 --> 00:19:58,800
little kind of public service announcement that I want to make, which is, as I was looking through

191
00:19:58,800 --> 00:20:03,120
all of the packages to, you know, figure out what I was going to talk about this week.

192
00:20:03,120 --> 00:20:08,240
There's a common problem, and I'm finally going to talk about it, which is

193
00:20:08,240 --> 00:20:14,320
readme file. So as you as you've, you've made this new package, you've created something that

194
00:20:14,320 --> 00:20:19,520
you're very passionate about, and you want to tell the world about it. So you write your readme file.

195
00:20:19,520 --> 00:20:23,680
And of course, as the package author, you're very familiar with the subject matter

196
00:20:24,320 --> 00:20:32,160
area. And so you start writing, and it's very easy to assume a lot of knowledge that the people

197
00:20:32,160 --> 00:20:38,640
reading it might not have. And I see this problem all the time in terms of package readmes. And I

198
00:20:38,640 --> 00:20:45,040
came across one, this is not part of the picks for this week. But I will mention this one package,

199
00:20:45,040 --> 00:20:52,000
because it was, I think it was a great example of this. And it was a package called fit parser,

200
00:20:52,000 --> 00:21:01,680
F-I-T parser, which has a great readme file. And it explains exactly how to use the package. And it

201
00:21:01,680 --> 00:21:05,680
tells you how to import it. And it tells you how to add it to your dependencies, and all the rest

202
00:21:05,680 --> 00:21:14,640
of it. But it doesn't tell you what these fit files that it's dealing with are. And only at the

203
00:21:14,640 --> 00:21:20,880
very bottom of the readme file, did I spot a mention of Garmin. And it turns out that these

204
00:21:20,880 --> 00:21:29,920
fit files are Garmin kind of workout data, or root data, or something like that. But we get into the

205
00:21:29,920 --> 00:21:41,600
bottom of a, you know, 500,000 word, sorry, 500 or 1000 word readme to figure that out. And I thought

206
00:21:41,600 --> 00:21:48,480
it was just worth mentioning that, that try and read your readme file from the perspective of

207
00:21:48,480 --> 00:21:54,640
someone who has absolutely no domain knowledge at all, before, before publishing a package,

208
00:21:54,640 --> 00:22:00,560
because I'm not sure whether I would have picked this to read, but there's a good chance that I

209
00:22:00,560 --> 00:22:04,560
wouldn't, that most people wouldn't even have got to the bottom of the readme file, they would have

210
00:22:04,560 --> 00:22:13,360
just moved on. Yeah, I was actually going to do a conference talk once I even started to write it,

211
00:22:13,360 --> 00:22:18,880
but I forget why the conference, I think the conference was postponed or cancelled or

212
00:22:18,880 --> 00:22:27,600
something like that. And I was going to talk about readme files for open source projects,

213
00:22:27,600 --> 00:22:37,440
and relate it to kind of marketing your app to the public. Because what you're actually doing

214
00:22:37,440 --> 00:22:41,680
with the readme file is you're marketing your package to developers. And so there's a whole

215
00:22:41,680 --> 00:22:48,240
load of similarities between what you need to do to get a successful app marketed to people

216
00:22:48,240 --> 00:22:53,600
in the real world on the App Store, and what you need to do to do that for developers on the Swift

217
00:22:53,600 --> 00:22:59,840
Package Index. Maybe I'll resurrect that conference talk and do it at some conference sometime,

218
00:22:59,840 --> 00:23:04,000
because I think there's a lot to be, there's a lot that could be improved in that area.

219
00:23:04,000 --> 00:23:12,640
Absolutely. I suppose we sort of look at more readmes than normal, but still it is quite

220
00:23:12,640 --> 00:23:20,000
noticeable that sometimes people assume a bit too much about their package. And the other thing is,

221
00:23:20,000 --> 00:23:25,600
I often see lengthy installation and usage instructions, which...

222
00:23:25,600 --> 00:23:29,600
Me too. I don't understand it.

223
00:23:29,600 --> 00:23:35,680
It's a bit tricky, right? Because if your package is just on GitHub, and it's not surrounded by

224
00:23:35,680 --> 00:23:42,880
any of Swift.org, or maybe even the Swift Package Index, where there are other places on how to use

225
00:23:42,880 --> 00:23:51,680
it, right? We have the pop-up, "Use this package," where it guides you through that. If you look at

226
00:23:51,680 --> 00:23:59,200
a package outside that context, there is no other immediate surrounding context to fill that in.

227
00:24:00,000 --> 00:24:02,560
But I guess at some point, you know...

228
00:24:02,560 --> 00:24:14,960
My issue there is, it's not the mention of installation. It's the depth which people go to.

229
00:24:14,960 --> 00:24:17,360
Yeah, and then there's Carthage and Exkoda.

230
00:24:17,360 --> 00:24:23,360
Exactly. Like, mentioning this is compatible with Swift Package Manager,

231
00:24:23,360 --> 00:24:25,040
CocoaPods, and Carthage...

232
00:24:25,040 --> 00:24:25,760
And then link out.

233
00:24:26,320 --> 00:24:30,080
That's all you need to say. You don't need to say how. Maybe you need the pod name.

234
00:24:30,080 --> 00:24:38,080
Exactly, yeah. But it's quite often half the README file is installation.

235
00:24:38,080 --> 00:24:44,000
I guess in some cases, it's from an era when it wasn't that obvious, right? When you had to sort

236
00:24:44,000 --> 00:24:46,800
of... "Well, how do I use it? Was it pod, or is it Carthage?"

237
00:24:46,800 --> 00:24:55,840
Of course. And it also becomes a standard within the community. "Oh, well, everyone else is telling

238
00:24:55,840 --> 00:25:00,720
people how to install it, so surely I need to do the same." I think there's a bit of that happening

239
00:25:00,720 --> 00:25:01,040
as well.

240
00:25:01,040 --> 00:25:06,000
We've been running quite long, but there is actually one other topic I'd like to bring up

241
00:25:06,000 --> 00:25:13,200
before we do our recommendations. And that's another interesting thread. It's a pitch on

242
00:25:13,200 --> 00:25:22,000
the Swift forums. It's about last expression as return value. And the reason is twofold. I wanted

243
00:25:22,000 --> 00:25:25,840
to talk about this. So A, it's an interesting technical discussion. It's quite lengthy. It's

244
00:25:25,840 --> 00:25:38,320
a super popular thread. And so what it's about is, you know, like in a map, you can omit return,

245
00:25:38,320 --> 00:25:45,120
and it'll return the value. And that's sort of a rule. If it's a single line expression,

246
00:25:45,120 --> 00:25:48,880
you can elide the return. That makes code more concise.

247
00:25:50,080 --> 00:25:54,400
And there's now a discussion to make that a general rule, like the last expression will

248
00:25:54,400 --> 00:26:00,640
be taken as the return value. And you're a very passionate Ruby developer as well,

249
00:26:00,640 --> 00:26:05,520
right? Where that is actually normal, right? That's a standard in Ruby, as I understand,

250
00:26:05,520 --> 00:26:05,920
isn't it?

251
00:26:05,920 --> 00:26:17,360
It is. And it's something that... So I am or I was a Ruby developer. And it's something that never

252
00:26:17,360 --> 00:26:26,000
really quite sat right with me in Ruby. I think there are situations where it makes sense. If

253
00:26:26,000 --> 00:26:34,000
you've got one exit from a function, and it's the last line, then that's fine. But in almost

254
00:26:34,000 --> 00:26:38,560
every other situation, I thought that was a negative point of the language, actually. And

255
00:26:38,560 --> 00:26:43,440
I agreed. I thought it was great when Swift added the single line return. So it's...

256
00:26:44,400 --> 00:26:48,480
Where there is nothing else that could be happening other than a return, it's fine. And I

257
00:26:48,480 --> 00:26:55,360
thought that was a reasonable change to the language. But I'm not sure I would want to see it

258
00:26:55,360 --> 00:26:55,760
fall down.

259
00:26:55,760 --> 00:27:01,920
It's an interesting discussion. And I like these threads that are bounced back and forth. And

260
00:27:01,920 --> 00:27:07,120
there's lots of people making great points this way and that way. It's like, I just don't want

261
00:27:07,120 --> 00:27:14,000
to be the person who has to decide this in the end. But I loved reading it and seeing people,

262
00:27:14,560 --> 00:27:17,920
throwing around ideas and explaining why it's a good idea or a bad idea.

263
00:27:17,920 --> 00:27:25,520
And it's sort of a meta discussion about how this is being debated that I wanted to talk a bit

264
00:27:25,520 --> 00:27:32,160
about. I find the quality, the general quality of discussion, the depth and the breadth to be

265
00:27:32,160 --> 00:27:37,600
really, really good. Like in the forums in general, I know people have conflicted thoughts

266
00:27:37,600 --> 00:27:42,480
about the Swift forums. But I, in general, find the discussion is really high quality. And

267
00:27:43,200 --> 00:27:49,680
sometimes it flames up a bit, but I think it's for internet forums, it's actually really good.

268
00:27:49,680 --> 00:27:56,640
One thing I noticed in this thread in particular, and there are threads like this where there's

269
00:27:56,640 --> 00:28:02,000
lots of participation, and that's around topics that are not as technical, right? Whether to

270
00:28:02,000 --> 00:28:08,320
return and how to return in the last expression isn't on the same level as talking about some of

271
00:28:08,320 --> 00:28:13,840
this existential stuff or distributed actors. And that's where you really, I find it impossible to

272
00:28:13,840 --> 00:28:20,800
contribute there because it's so technical. But here, the audience is broader, it's easier to

273
00:28:20,800 --> 00:28:28,640
add thoughts. But even so, it struck me that when the developer experience is brought up in this

274
00:28:28,640 --> 00:28:36,080
context, it's typically brought up by people on behalf of other groups. So it struck me that

275
00:28:37,040 --> 00:28:45,680
it almost always only enters the discussion via representative. The Swift forums are really

276
00:28:45,680 --> 00:28:53,280
technical, and it isn't a fair, unbiased representation of the whole Swift ecosystem

277
00:28:53,280 --> 00:28:57,920
of developers, right? Only the people who are really interested in the language and are typically

278
00:28:57,920 --> 00:29:04,160
quite experienced end up on the Swift forums and then end up entering these discussions, right? So

279
00:29:04,160 --> 00:29:11,280
it's really highly selective towards a more experienced crowd, which then means these,

280
00:29:11,280 --> 00:29:17,920
the opinions only get related. Now, people will say, "Well, I teach Swift, and this is what people

281
00:29:17,920 --> 00:29:21,200
struggle with." But it's not the people themselves who are struggling who actually come to the

282
00:29:21,200 --> 00:29:27,440
forums and say, "Look, this might be problematic." And I think there's a... That is kind of a bit

283
00:29:27,440 --> 00:29:33,520
problematic. I'm sure the people who make the decision will look very carefully at who's making

284
00:29:33,520 --> 00:29:40,160
these points on behalf of others. But I think it's important to understand a single person

285
00:29:40,160 --> 00:29:48,080
raising a concern about a whole group of people, you know, pupils, students, has to be weighed

286
00:29:48,080 --> 00:29:54,800
differently. And there is not going to be a fix, you know, like, it's not going to change overnight,

287
00:29:54,800 --> 00:30:00,400
or maybe even in general, that suddenly, this would be representative to the whole demographics.

288
00:30:00,400 --> 00:30:10,560
But I wonder if it might help if certain topics are perhaps highlighted to be explicitly inviting

289
00:30:10,560 --> 00:30:15,440
people who aren't as experienced to come and look and contribute and give their points of view,

290
00:30:15,440 --> 00:30:23,040
like call out, your opinion is really valuable, because you can't undo your experience, right?

291
00:30:23,040 --> 00:30:28,400
It's really hard sometimes to participate in discussions that shouldn't be about the

292
00:30:28,400 --> 00:30:33,520
most experienced people entering and saying, "Well, I don't have a problem with it, because

293
00:30:33,520 --> 00:30:38,880
I understand Swift, and I've been doing this for two decades." This maybe should be called out

294
00:30:38,880 --> 00:30:46,320
specifically, we're talking about last expression. What do you specifically as a beginner think,

295
00:30:46,320 --> 00:30:52,080
you know, would this confuse you? Would this make it perhaps easier for you to work with Swift?

296
00:30:53,600 --> 00:30:58,880
Yeah, I think I get your point here. And it's a good point. I think,

297
00:30:58,880 --> 00:31:04,000
looping back to what you said at the beginning of your discussion there about the Swift forums

298
00:31:04,000 --> 00:31:10,880
being, I think the Swift forums have improved an enormous amount since they started. When they

299
00:31:10,880 --> 00:31:21,200
started, I was so put off by them, and the kind of the conversations and the attitude of in threads

300
00:31:21,200 --> 00:31:28,240
on them that I completely stopped visiting them for maybe even years. And they have improved

301
00:31:28,240 --> 00:31:40,320
beyond belief since that point. But they are still quite an intimidating place to post.

302
00:31:40,880 --> 00:31:52,240
I certainly feel intimidated before posting anything there. And that stops me from contributing

303
00:31:52,240 --> 00:31:58,800
to everything that I would potentially otherwise contribute to. And I think, even if you were being

304
00:31:58,800 --> 00:32:04,240
requested to, your feedback was being requested, I think it would still be quite an intimidating

305
00:32:04,240 --> 00:32:09,280
place to enter one of those threads, because it's full of, as you say, people who are very

306
00:32:09,280 --> 00:32:15,760
passionate about Swift and who spend a lot of time thinking about language design, which is

307
00:32:15,760 --> 00:32:23,840
not something a novice even considers. Language design is something that by almost by definition,

308
00:32:23,840 --> 00:32:27,200
you only have an opinion on once you know the language.

309
00:32:27,200 --> 00:32:28,320
Yeah, definitely. I get that.

310
00:32:28,320 --> 00:32:36,160
So I think it's, I get your point. And it's a good point. I just don't know. I don't know how

311
00:32:36,160 --> 00:32:46,640
to solve it. I think the Swift forums are still quite intimidating. And I think finding the people

312
00:32:46,640 --> 00:32:51,760
who would have those opinions and would be able to post them, I think would be challenging.

313
00:32:51,760 --> 00:32:58,160
I think that's the point, to try and make it more inviting. I think it's a huge problem for the

314
00:32:58,160 --> 00:33:03,440
forums if someone like you, who's very experienced and a very well respected member in the community,

315
00:33:03,440 --> 00:33:11,360
feels intimidated by the forums for the programming language of that community. I think that's a huge

316
00:33:11,360 --> 00:33:19,760
problem. And I don't want to point, I feel the same. There's topics where I'm not considering

317
00:33:19,760 --> 00:33:25,040
contributing, even if I have a remote thought that might be useful, because this is out of my

318
00:33:25,040 --> 00:33:32,560
league. But I think that's a problem. I think for the forums to be really representative of the

319
00:33:32,560 --> 00:33:41,280
people actually using the language, it is a problem when people are intimidated by the main platform

320
00:33:41,280 --> 00:33:49,600
where discussion is happening. And I think that's why maybe pitches, some pitches, not all of them,

321
00:33:49,600 --> 00:33:55,360
for some pitches, there's just no hope. You need people who are super technical. But I think it

322
00:33:55,360 --> 00:34:01,920
might be worthwhile considering some pitches or evolution proposals to specifically call out,

323
00:34:01,920 --> 00:34:09,840
look, give it a thought if you have thoughts and post them and specifically invite contributions.

324
00:34:09,840 --> 00:34:16,480
Maybe it does nothing, but it can't hurt. I think that's why it can't hurt to call that out and

325
00:34:16,480 --> 00:34:24,400
maybe prod people into applying. And maybe then people could help along a bit by saying like,

326
00:34:24,400 --> 00:34:30,560
applauding people who actually come to the front and post something and encourage them further.

327
00:34:30,560 --> 00:34:34,240
I think that'd be a good thing to happen. - I agree.

328
00:34:34,240 --> 00:34:39,760
- Okay, that was a longer news section than normal.

329
00:34:39,760 --> 00:34:46,880
- Yes, maybe we'll keep the picks to a slightly shorter number of picks today.

330
00:34:46,880 --> 00:34:56,800
I will kick us off. And actually, so my first pick is a double pick and also

331
00:34:58,400 --> 00:35:02,240
related to something that you did on the Swift Package Index a little while ago.

332
00:35:02,240 --> 00:35:09,440
I know that when we were doing the documentation build system and specifically uploading the

333
00:35:09,440 --> 00:35:16,880
documentation to Amazon S3, what we do is we zip the documentation after we build it

334
00:35:16,880 --> 00:35:25,120
and then ship it to S3 and then using a Lambda function on AWS, we unzip it and put it into

335
00:35:25,120 --> 00:35:32,240
the right place on S3 because we found that moving lots of files individually was not practical up to

336
00:35:32,240 --> 00:35:40,960
S3. But I know that over the years since that original system got implemented,

337
00:35:40,960 --> 00:35:50,560
we've had a couple of issues where the zip tool that we used didn't quite do what we wanted to

338
00:35:50,560 --> 00:35:53,840
do. I think there was a bug at one point which caused us to try a different one, which didn't

339
00:35:53,840 --> 00:36:01,760
quite work in the same way. And it seemed like there were a couple of prominent kind of zip

340
00:36:01,760 --> 00:36:06,640
tools, but none of them do exactly what we wanted, or at least we hit some issues with them.

341
00:36:06,640 --> 00:36:12,560
And I noticed as I was looking through all the packages since the beginning of the year,

342
00:36:12,560 --> 00:36:20,800
that there have been two new zip tools added to the Package Index, both of which look to be

343
00:36:20,800 --> 00:36:27,680
completely new, as in not kind of forked from other things or created from other projects.

344
00:36:27,680 --> 00:36:36,080
Although I may be wrong, I'm not an expert in either of them, of course. One of them is called

345
00:36:36,080 --> 00:36:44,240
zip, Simply "zip" by Tomas Franzén, which has been in development for two months. And it can

346
00:36:46,880 --> 00:36:52,960
deal with zip files, both file-based and in memory. You can configure the compression levels.

347
00:36:52,960 --> 00:36:59,440
You've got a Swift API. You've got this kind of fairly nice API into a zip file. And the other

348
00:36:59,440 --> 00:37:06,720
one is called swift-zip-archive from Adam Fowler. And that's been in development for about a month.

349
00:37:07,680 --> 00:37:17,360
So both of them look to be completely new. And if you have hit problems with a zip tool in Swift

350
00:37:17,360 --> 00:37:23,360
before, they might be something that you want to check out. Yeah, I was super excited to see. I

351
00:37:23,360 --> 00:37:29,920
actually hadn't seen the first one you mentioned. I'd seen Adam Fowler's Zip. And I actually have

352
00:37:29,920 --> 00:37:35,200
that on my to-do list because, as you mentioned, we had trouble with Zip. Zip is just fiendishly

353
00:37:36,400 --> 00:37:44,480
annoying and complex and weird, where when you zip stuff, sometimes stuff gets pulled from a tree

354
00:37:44,480 --> 00:37:51,520
and is a flat list of files inside the zip. And then you lose the power. It's super annoying.

355
00:37:51,520 --> 00:37:55,760
So currently, we're actually using two different zippers, one that is zipping, the other is

356
00:37:55,760 --> 00:38:03,920
unzipping because of compatibility issues. It's a nightmare. I really want to try at least Adam's,

357
00:38:03,920 --> 00:38:11,200
and then also perhaps the other, if there's still problems, just to replace that contraption that

358
00:38:11,200 --> 00:38:16,080
we're using right now. I just, yeah, I thought it was, I thought of that issue, obviously,

359
00:38:16,080 --> 00:38:19,920
when I saw both of these. But it's also kind of interesting that both have popped up within a

360
00:38:19,920 --> 00:38:25,600
month of each other. So there was obviously something in the air over the holidays that

361
00:38:25,600 --> 00:38:31,120
made people go, maybe I should write a zip library. A little zip competition going on there.

362
00:38:31,120 --> 00:38:37,920
Exactly. Yeah, exactly. But yeah, something to check out if you have, if you have files to zip

363
00:38:37,920 --> 00:38:47,200
or unzip. My first pick is a package you, I believe, also mentioned in your iOS Dev Weekly

364
00:38:47,200 --> 00:38:55,440
newsletter, and that's Forked by Drew McCormack. And this looks like a really, really nice and

365
00:38:55,440 --> 00:39:04,480
powerful library to handle shared data in a Git-like model. So you have different data sources

366
00:39:04,480 --> 00:39:11,360
and they just think, might have an editing, an app that edits text and you want to have edits

367
00:39:11,360 --> 00:39:18,800
happening independently. And the nice thing about this is you can sort of branch stuff and then have

368
00:39:18,800 --> 00:39:24,480
custom merging strategies per type, per data type. And it allows you to customize that. And there's

369
00:39:24,480 --> 00:39:30,960
a really interesting example in the, I think it's in the Readme, if not the Readme, it's in a

370
00:39:30,960 --> 00:39:37,760
documentation to explain how that can work. So there's an incrementing integer that is used in

371
00:39:37,760 --> 00:39:46,000
two different apps. And the way the merging strategy works, you can easily see how that

372
00:39:46,000 --> 00:39:51,120
could be conflicting, right? They increment, decrement independently, and then they want to

373
00:39:51,120 --> 00:39:56,160
sync and they have different values, right? And it's unclear who should win. Because you make a

374
00:39:56,160 --> 00:40:00,560
mistake if you just let the last win, because any counting that happened on the other side would

375
00:40:00,560 --> 00:40:08,320
then be gobbled up. And the way you can easily fix that and make that really reliably syncing is

376
00:40:08,320 --> 00:40:14,800
that each just takes the delta to its last non-merge state where it branched off, right?

377
00:40:14,800 --> 00:40:19,760
And then you can actually add up the deltas and you get a reliable merge because any action that

378
00:40:19,760 --> 00:40:24,400
happened in between would still be reflected in the total outcome. It would just happen

379
00:40:24,400 --> 00:40:30,960
independently and asynchronously. And if you have a type, a data type that has that

380
00:40:30,960 --> 00:40:40,800
domain knowledge, sort of domain behavior, and you can write a sync merging algorithm like that,

381
00:40:40,800 --> 00:40:47,200
then this is really great because you can create a distributed system that actually

382
00:40:47,200 --> 00:40:53,200
merges reliably without potential conflicts. And you can see how you can even build up larger

383
00:40:53,200 --> 00:40:57,760
types if you can break it down into small components that have all sort of merging

384
00:40:57,760 --> 00:41:03,920
strategies like that, that are actually resolvable. It's not always the case. Sometimes you just can't

385
00:41:03,920 --> 00:41:11,920
resolve and you have to let last change win or whatever it might be. But sometimes your domain

386
00:41:11,920 --> 00:41:17,200
model is like that. You know exactly what the outcome should be and then you have the power

387
00:41:17,200 --> 00:41:22,000
with this tool, with this package to implement it that way. And I found that really interesting.

388
00:41:22,000 --> 00:41:29,120
I hadn't seen anything like it. So the other, we've talked about CRDTs, I think is the

389
00:41:29,120 --> 00:41:36,000
acronym. I don't even remember what the conflict... Conflict Free Resolution something.

390
00:41:37,840 --> 00:41:45,360
But what they try and do is giving you an auto merge. So you don't have to, you have no way of

391
00:41:45,360 --> 00:41:52,400
actually injecting a merging strategy. But from what I've seen is that you will end up with

392
00:41:52,400 --> 00:41:59,680
conflict free merges that are conceptually correct, but give you really weird result,

393
00:41:59,680 --> 00:42:04,800
especially when it's around texts and edited texts, because you get stuff that is correctly

394
00:42:04,800 --> 00:42:10,720
merged. Like in the sense, technically there was no conflict, but the result is kind of garbage

395
00:42:10,720 --> 00:42:15,520
that comes out of it. Not complete garbage, but the edits would conflict in weird ways.

396
00:42:15,520 --> 00:42:24,400
And my understanding is that's actually not resolvable. So in these cases, it really helps

397
00:42:24,400 --> 00:42:30,160
if you have a data type that you fully understand and where you can define emerging strategy that

398
00:42:30,160 --> 00:42:35,280
is actually, that makes sense, not just technically, but also semantically and allows you

399
00:42:35,280 --> 00:42:43,120
to handle edits that happen independently. So if you have need for a shared data model,

400
00:42:43,120 --> 00:42:49,120
I think that's a great package to look at. And I believe it can work on top of iCloud and stuff.

401
00:42:49,120 --> 00:42:56,320
So it's not like it's tied to any sort of persistence strategy or even syncing mechanism.

402
00:42:56,320 --> 00:43:03,520
It really deals with the model layer and you can have the underlying stuff. You just save files,

403
00:43:03,520 --> 00:43:07,680
I think effectively, and handle the merging at an higher layer.

404
00:43:07,680 --> 00:43:13,120
And Drew has been working on this kind of stuff for many, many years now. This has been

405
00:43:13,120 --> 00:43:20,240
a kind of passion of his for a long time. And I think it probably came out of his work on,

406
00:43:20,240 --> 00:43:28,560
I think it's Ensembles, which is the product that he makes, which is an open source, or you can buy

407
00:43:28,560 --> 00:43:33,840
a version of it that gets the source or something like that, which is a synchronization framework

408
00:43:33,840 --> 00:43:41,440
for cloud synchronization of local data. So yeah, this has been on his mind for many, many years.

409
00:43:41,440 --> 00:43:46,400
So it's something that this is not someone who's just had an idea and has started writing stuff.

410
00:43:46,400 --> 00:43:51,680
This is, I would imagine, extremely well researched and based on...

411
00:43:51,680 --> 00:43:59,120
- Well, and Drew's the co-author of Agenda, the calendar note-taking app on Mac OS, iOS.

412
00:43:59,120 --> 00:44:04,640
So he does syncing. His app does syncing. It doesn't come out of nowhere.

413
00:44:04,640 --> 00:44:06,480
- He does syncing, yeah, exactly. Yeah.

414
00:44:08,720 --> 00:44:22,640
My final package for this week is Skin Smoothing Filter by Shima. And this is a package that

415
00:44:22,640 --> 00:44:30,480
effectively takes... So it uses metal and core image, and it takes an image. The example image

416
00:44:30,480 --> 00:44:42,480
in the readme is a picture of a face and kind of shoulders portrait picture. And it smooths the

417
00:44:42,480 --> 00:44:51,040
skin on the person's face. So there's obviously some kind of blurring going on because some bits

418
00:44:51,040 --> 00:44:56,080
of the image are kind of blurry, but it's identified the bits that it needs to keep

419
00:44:57,120 --> 00:45:03,040
in focus, like the eyes and hair and things like that. It doesn't mention the technology it uses

420
00:45:03,040 --> 00:45:08,640
to identify the bits that it doesn't smooth or how it detects the skin that it wants to smooth.

421
00:45:08,640 --> 00:45:17,600
But what it does say is it uses metal, which is the 3D framework underneath the entire iPhone.

422
00:45:17,600 --> 00:45:21,840
This was the replacement for OpenGL. So I'm guessing that's how they're doing the actual

423
00:45:22,560 --> 00:45:29,200
drawing and core image to actually turn it back into an image again. But it doesn't have any

424
00:45:29,200 --> 00:45:35,520
huge detail on how it's doing the job, but it's doing a very good job. You can see the picture

425
00:45:35,520 --> 00:45:44,400
in the readme file for an example. And the lady in the picture has freckles, and those freckles

426
00:45:44,400 --> 00:45:50,960
are effectively smoothed out in the resulting image. So I thought it was not probably something

427
00:45:50,960 --> 00:45:53,920
you're going to use every day, but it was something interesting that I came across as I was

428
00:45:53,920 --> 00:46:02,320
looking through all the packages this month. Right. My second and final pick is called Numerix by

429
00:46:02,320 --> 00:46:09,920
Gavin Wiggins. And that looks like a really great library for linear algebra, like vectors and

430
00:46:09,920 --> 00:46:16,720
matrices. It's using the Accelerate framework under the hood. So that's probably very important

431
00:46:16,720 --> 00:46:22,160
when you do this sort of thing. You know, in general, you typically don't have just one matrix

432
00:46:22,160 --> 00:46:27,600
or small matrix to multiply. You often do this over and over. So you are quite performance,

433
00:46:27,600 --> 00:46:33,600
you have performance concerns. That's probably something you're thinking about. And then

434
00:46:33,600 --> 00:46:40,160
Accelerate framework will give you massive boosts. And I also noticed in the readme,

435
00:46:40,720 --> 00:46:48,400
the package does really nice ASCII art printouts of matrices and vectors. So it lays them out a bit,

436
00:46:48,400 --> 00:46:54,240
which I always find really nice, because you might be debugging that sort of stuff. And what do we

437
00:46:54,240 --> 00:46:58,800
do when we debug? We put print statements in our code and print stuff out. And then it's just

438
00:46:58,800 --> 00:47:06,640
really nice to see it, not just in a long flat list or stuff like that. So I found that really,

439
00:47:06,640 --> 00:47:12,960
really neat about the package to also have that taken care of. So yeah, that's Numerics

440
00:47:12,960 --> 00:47:19,600
with an X at the end by Gavin Wiggins. That's useful to include that information. I

441
00:47:19,600 --> 00:47:23,200
would have searched for the spelling of numerics, regular spelling.

442
00:47:23,200 --> 00:47:32,800
Well, we'll leave it there, then, shall we? So thanks for listening. And we will be back

443
00:47:32,800 --> 00:47:39,280
in a few weeks with another episode. Promise not to leave it as long as we did over the holidays

444
00:47:39,280 --> 00:47:46,880
for the next one. And yeah, we'll see you in a few weeks. See you next time. Bye bye. All right.