KOPYA NG SALIN 🔗
WEBVTT
00:00:00.160 --> 00:00:04.080
I'm not saying that all functions that can't fit on a single screen are too long.
00:00:04.400 --> 00:00:09.599
But we've entered we've definitely entered the realm of this is outside the ordinary and deserves attention to justify itself.
00:00:09.599 --> 00:00:09.839
Yeah.
00:00:10.080 --> 00:00:35.840
Because like some of the best code that I've seen, it's just it is like it's not even C it's like closure, and all of them are just these beautiful little concise composed, you know, everything, it's it's you know what when you hear Stepanov or Sean Parent or or you Ben talk about like the composability of Albert, you can see that everything was so beautifully crafted to fit together that you only ever need to invoke, you know, five, six, seven things, and you just read it and it's like it's like reading poetry.
00:00:35.840 --> 00:00:36.560
It's it's so nice.
00:00:36.560 --> 00:00:39.280
And and you never are asking yourself, is this too long?
00:00:39.280 --> 00:00:40.719
Because it's obvious that it's not.
00:01:18.959 --> 00:01:22.319
Yeah, well, we could talk a bit about default construction if you like.
00:01:22.319 --> 00:01:23.280
Sure, yeah.
00:01:23.280 --> 00:01:24.480
Steer the boat, Ben.
00:01:24.480 --> 00:01:25.280
Steer the boat.
00:01:25.280 --> 00:01:27.599
Well, I was thinking about this this morning some more.
00:01:27.599 --> 00:01:30.719
It occurred to me that default construction is really a poor term.
00:01:30.719 --> 00:01:35.120
The term that we've sort of had all these years, and it sort of confuses two ideas.
00:01:35.120 --> 00:01:55.920
It confuses the uh and and one of the one of the things that we inherited from C and one of the things that kind of the idea of regular types and Stepanoffian stuff try to do is to say, well, let's the great thing about C is you can make types that behave like the built-in types, right?
00:01:55.920 --> 00:01:59.680
And and and so Gottmeier says, you know, when in doubt, do what the ints do.
00:01:59.680 --> 00:02:02.640
But actually, actually we don't like what the ints do.
00:02:02.640 --> 00:02:04.799
This this is kind of bad advice, right?
00:02:04.799 --> 00:02:14.080
Because we don't like interprotions, we don't we and we and we don't, you know, in recent years we've started to realize that we don't actually like uninitialized construction, right?
00:02:14.080 --> 00:02:15.439
Which is what the ints do.
00:02:15.439 --> 00:02:16.080
Yeah.
00:02:16.080 --> 00:02:21.439
That's not actually a good way to make your type to to to design your types, right?
00:02:21.680 --> 00:02:24.639
Yeah, we don't we like very little things that the ints do.
00:02:25.199 --> 00:02:28.960
And and so, you know, default construction conflates two ideas.
00:02:28.960 --> 00:02:32.080
One is uninitialized construction, doing what the ints do.
00:02:32.080 --> 00:02:34.159
And that I think is just a bad idea.
00:02:34.159 --> 00:02:44.479
The other applies for some types, and there's a reasonable idea, which is the idea of nullery construction, which is basically saying, okay, the author of the type was able to provide reasonable defaults, right?
00:02:44.479 --> 00:02:47.599
Nullery construction for some types is perfectly fine.
00:02:47.599 --> 00:02:51.599
Uninitialized construction is almost always a bad idea.
00:02:51.599 --> 00:02:58.879
Now there are certain now the and the reason why we've we've held on to it for so long, perhaps, is has been the performance argument, right?
00:02:58.879 --> 00:03:02.879
Which is that I don't want to initialize this whole array of zero things.
00:03:02.879 --> 00:03:07.680
And and interestingly, in in in recent years, we've seen things like resize and overwrite.
00:03:07.680 --> 00:03:13.919
We've seen effectively the expansion of the construction idea to cover these performance arguments, right?
00:03:13.919 --> 00:03:17.439
But but we still don't like uninitialized construction.
00:03:17.439 --> 00:03:19.280
That's still kind of a bad thing.
00:03:19.599 --> 00:03:25.280
Yeah, so uh I had one student come back to I like I don't disagree with you, just for the record.
00:03:25.280 --> 00:03:26.319
I'll start with that.
00:03:26.319 --> 00:03:43.120
But I had one student once come back to me after a class and he's like, look, he said, one of our main performance bottlenecks right now, he's like, I need to be able to resize a vector of trivially constructible things, but Vector insists on initializing all the objects.
00:03:43.120 --> 00:03:48.319
And he said, one of my main performance bottlenecks right now is the initialization of those objects.
00:03:48.319 --> 00:04:02.800
And these are like people who work on like really large physics simulation engines, like you've got, you know, who knows, whatever, billions of particles or something, and you really, really, truly don't want to initialize that memory with zeros, because that's like a performance problem for you.
00:04:02.800 --> 00:04:07.039
And I've never encountered code like this in my own time.
00:04:07.039 --> 00:04:12.560
But whenever I think about this argument, I go back to this person and I'm like, what is a good answer there?
00:04:12.560 --> 00:04:16.639
And I've never come up with like what I think is like actually a good answer for this situation.
00:04:16.959 --> 00:04:28.240
Yeah, and you know, it that event that the the thinking here eventually leads us to things like, you know, how C defines lifetime and um all that kind of stuff.
00:04:28.240 --> 00:04:33.279
And indeed things like resize and overwrite for string, which I don't think exists for vector, right?
00:04:33.279 --> 00:04:47.920
Which might be another piece of but uh, you know, so the other thing is that Stepanovian regularity is defined as having the special member functions basically, being copyable, having a quality, in fact also having comparison.
00:04:47.920 --> 00:04:56.319
And and also being default constructible, which
Load full transcript
again I think is a poor term to use, because actually it's not needed.
00:04:56.319 --> 00:05:06.480
It's not needed, I don't think, to define regular, and it's not really needed to even implement the standard library for the most part, you know.
00:05:06.480 --> 00:05:22.240
So so supplying default constructibility because we think that's what's needed for the code, actually, if we think about containers, it's only vector resize and and square bracket operator on on the map types that require default constructability.
00:05:22.240 --> 00:05:25.120
There are no other functions on containers that don't I I think.
00:05:25.439 --> 00:05:26.160
What were those two?
00:05:26.160 --> 00:05:29.120
The second one was the square brackets on map types, the first one was.
00:05:29.439 --> 00:05:30.879
Yeah, the indexing operator.
00:05:30.879 --> 00:05:34.160
And that arguably is a poorly designed API, right?
00:05:34.160 --> 00:05:35.680
Indexing into a map in C.
00:05:35.680 --> 00:05:38.800
Default constructs the object if it wasn't there.
00:05:39.120 --> 00:05:41.920
I just I just watched, it was it was on my list for a long time.
00:05:41.920 --> 00:05:46.079
There's a is it two-hour video called The Worst Language Ever?
00:05:46.480 --> 00:05:47.600
Oh, I've seen the title.
00:05:47.600 --> 00:05:48.800
I haven't watched the video, yeah.
00:05:49.040 --> 00:05:51.279
Yeah, it's a clickbaity title.
00:05:51.279 --> 00:05:59.759
It's about C, but really it's like a master class in like, you know, becoming a language expert and finding all the different things.
00:05:59.759 --> 00:06:09.120
And that's in the first ten minutes, I think it talks about that being one of the biggest kind of warts of the container types is is that kind of behavior.
00:06:09.120 --> 00:06:15.839
And it it puts it up against Python and Java and a bunch of other languages, and it's like no other language does this because it's absurd.
00:06:15.839 --> 00:06:17.839
Like it's not at all what you expect.
00:06:18.240 --> 00:06:26.800
Default construction, I should say I'd like to stop using the term default construction and and indeed say non-initializing construction versus nullery construction, right?
00:06:26.800 --> 00:06:43.360
So non-initializing construction, which is what the language applies to built-in types, basically, that that leads us down the route of, oh, you know, we have to deal with it historically, so now we have erroneous behavior, for example, for reading from non-initialized built-in types.
00:06:43.360 --> 00:06:59.199
It also kind of flies in the face of, you know, one of the original things at C, one of the original kind of selling points, if you like, of C over C is that we don't have to declare all our automatic variables up front only to assign them later.
00:06:59.199 --> 00:07:02.319
We can wait till we need the variable to declare it.
00:07:02.319 --> 00:07:05.279
And at that point we know how to initialize it, presumably.
00:07:05.279 --> 00:07:10.800
And you know, this is certainly a best practice I know that Jason espouses, and then you can mark it const and all those good things, right?
00:07:10.800 --> 00:07:15.279
And and Connor, I know you've talked about the initialize, then modify anti-pattern.
00:07:15.279 --> 00:07:23.199
You know, so the idea of non-initializing construction just is anathema to to this kind of best practices worldview.
00:07:23.360 --> 00:07:26.319
Yeah, I'm not gonna disagree with you for sure.
00:07:26.319 --> 00:07:29.680
And then there's fallback solutions if you really need them.
00:07:29.680 --> 00:07:38.480
Like you can make an optional of the thing and then uh fill it in later, which I don't love optional, but that is a good use case for optional, right?
00:07:38.720 --> 00:07:41.519
Yeah, it's it's the major use case I have, I think.
00:07:41.519 --> 00:07:42.800
Deferred construction.
00:07:43.120 --> 00:07:46.879
I just I feel like I just want to say out loud to anyone who just heard me say that.
00:07:46.879 --> 00:07:50.480
Still try to figure out if you don't need optional first, right?
00:07:50.480 --> 00:07:53.839
Don't just be like, oh, I'll just use optional here because I don't have a plan.
00:07:53.839 --> 00:07:54.959
You know, don't do that.
00:07:55.920 --> 00:07:57.920
What does I I don't use these algorithms?
00:07:57.920 --> 00:07:59.199
Or or sorry, go ahead, Jason.
00:07:59.199 --> 00:08:03.600
I was gonna say, I I don't use these algorithms, but I know that they were added.
00:08:03.600 --> 00:08:07.519
The uninitialized underscore operations.
00:08:07.519 --> 00:08:11.680
What does yeah, what does your commentary here, Ben, say about those?
00:08:11.680 --> 00:08:16.000
Like I'm this is a more of like because I like Oh, you're talking about the algorithms in memory.
00:08:16.079 --> 00:08:19.439
I think it's copy uninitialized and move uninitialized, is that right?
00:08:19.680 --> 00:08:40.240
Yeah, but I think they might have even come up I've never looked at I've I've seen them maybe even in Thrust or some other libraries, and and they are like for I think performance reasons, but like when I hear potentially like an argument for do we do we even obviously they're not gonna do this to C ⁇ , but we're talking hypothetically here, you know, do we even need quote unquote, you know, default construction?
00:08:40.240 --> 00:08:48.480
Like, does that I mean what does the existence of these uninitialized algorithms or operations like mean in in this kind of context?
00:08:48.639 --> 00:08:49.519
Like I don't have the answer.
00:08:49.519 --> 00:08:51.679
I haven't used them a whole lot.
00:08:51.679 --> 00:09:01.519
I I tend to think something is telling me, I'm remember if I'm remembering right, they are often used in the implementation of types like vector.
00:09:01.519 --> 00:09:11.120
And they are for things like I I I ha I yeah, I I need to I need to do things which involve micromanagement of lifetimes.
00:09:11.360 -->
00:09:11.600
Yeah.
00:09:11.600 --> 00:09:13.360
Constexpr in 26.
00:09:13.360 --> 00:09:14.639
Looking up the details here.
00:09:14.639 --> 00:09:16.320
I've never done I've never used them.
00:09:16.320 --> 00:09:20.480
This is like and this is officially going on a list for an upcoming C weekly episode.
00:09:20.480 --> 00:09:21.519
Perfect.
00:09:21.759 --> 00:09:22.000
Yeah.
00:09:22.000 --> 00:09:29.600
I I've I've only ever used them in things like implementing like my own containers, my own vector, for example.
00:09:30.080 --> 00:09:34.320
It's clearly not necessary for the constexpr implementation of vector.
00:09:34.320 --> 00:09:37.759
Otherwise, it would have been constexpr in C20.
00:09:37.759 --> 00:09:40.879
That's how these things tend to fall out in the standard.
00:09:40.879 --> 00:09:41.919
So I am curious.
00:09:42.240 --> 00:10:01.600
Yeah, I just I Googled uninitialized on CPP reference, and the set that comes up when you Google or Google that search that, is std uninitialized copy, uninitialized fill, uninitialized move, uninitialized value construct, unitialized default construct, and initi uninitialized construct use and then there's ranges versions of those also, it seems.
00:10:01.600 --> 00:10:07.039
Yeah, and they're they're all defined in memory, not algorithm, although it says specialized memory algorithm.
00:10:07.039 --> 00:10:17.360
Page and confusingly puts it under the algorithm, or it doesn't put it under, but to the left of the specialized memory algorithms is the algorithm library.
00:10:17.679 --> 00:10:25.840
So I'm gonna think of these things as specialist tools for managing lifetime in things like containers, like we said.
00:10:25.840 --> 00:10:35.039
I think if you find yourself using these in application quote quote application code, then then maybe take a step back and look at encapsulating it in.
00:10:35.519 --> 00:10:35.679
Right.
00:10:35.679 --> 00:10:38.480
No raw uninitialized algorithms.
00:10:38.480 --> 00:10:41.679
Not as catchy as uh Sean's no raw loops, but hey.
00:10:41.919 --> 00:10:47.440
Yeah, the the idea of uninitialized or non-initializing construction, like for ints, right?
00:10:47.440 --> 00:11:05.759
So if we think about this more, I think I was thinking about this like so and I and I looked inside elements of programming and it defines regular types in chapter 1.5, and it doesn't actually say that your default construction is required, it says construction is required, and then it goes on to say that default construction is when you have no argument.
00:11:05.759 --> 00:11:12.879
Uh but it's not necessarily true, I think, for a consistent view of of regularity that we require default construction.
00:11:12.879 --> 00:11:22.080
The the one axiom, if you like, of regularity is that if you copy a T, then the A and the B should compare equal after the copy.
00:11:22.080 --> 00:11:22.480
Right?
00:11:22.480 --> 00:11:26.159
That's that's the axiom that links copying and equality.
00:11:26.159 --> 00:11:29.519
And it and it presupposes that you have a T available.
00:11:29.519 --> 00:11:34.639
How that T was constructed, the we don't really care at that point, right?
00:11:34.639 --> 00:11:44.559
And it may be also be true that some of the containers in their internals from time to time require nullery construction.
00:11:44.559 --> 00:11:45.039
Right.
00:11:45.039 --> 00:11:48.799
And that I'm not I'm not using deliberately not saying default construction.
00:11:48.799 --> 00:11:54.559
But if if we if we just say int x with with no initializer, right?
00:11:54.559 --> 00:12:00.000
So that the storage is there, the int is it alive?
00:12:00.000 --> 00:12:04.799
I think it's alive, but it has but but it's partially formed.
00:12:04.799 --> 00:12:11.200
And these are also the words of elements of programming, it's partially formed, which is to say that you can either destroy it or assign to it.
00:12:11.679 --> 00:12:12.240
And you cannot read it.
00:12:12.559 --> 00:12:13.600
What it says in EOP.
00:12:13.600 --> 00:12:14.639
You cannot read it.
00:12:14.639 --> 00:12:17.600
That's erroneous behavior from from 26 onwards, right?
00:12:17.600 --> 00:12:27.200
Um Well, you know, part of me wants to ask, what what is the point of constructing an object that cannot be in any meaningful way used?
00:12:27.200 --> 00:12:35.440
It it seems to me like if the the the fact of the matter is like built-in types do not have class invariant, right?
00:12:35.440 --> 00:12:38.480
They're not class types, we don't think of them as having class invariants.
00:12:38.480 --> 00:12:39.679
But maybe we should.
00:12:39.679 --> 00:12:47.440
And if we were to do that, then we would naturally think, well, you know, if I'm constructing an int and not initializing it, then that's upholding none of its invariants.
00:12:47.440 --> 00:12:49.440
It can't be used in any meaningful way.
00:12:49.440 --> 00:12:54.480
And that is part of its interface, and therefore that is you know, I expect after I construct an int that I can use it.
00:12:54.720 --> 00:12:56.320
Yeah, that's a fair argument.
00:12:56.559 --> 00:12:58.480
Anyway, that's my soapbox.
00:12:58.799 --> 00:12:59.519
Yeah, no.
00:12:59.519 --> 00:13:09.120
And I think adjacent to your soapbox is I've made a point of demonstrating this in a few talks, and I bring it up with students whenever it makes sense to.
00:13:09.120 --> 00:13:15.519
And it's it was one of the points that I end up making at the very end of this rule of n talk.
00:13:15.519 --> 00:13:16.639
Well, I don't whatever.
00:13:16.639 --> 00:13:17.919
I make the point somewhere in the talk.
00:13:17.919 --> 00:13:18.960
Depends on the version.
00:13:18.960 --> 00:13:33.759
If the thing does not have a default constructor, like if you must provide something to construct the thing, I have come to the conclusion personally that this object should not be movable under most cases.
00:13:33.759 --> 00:13:38.159
Because the now, so can I
ask a clarifying question?
00:13:38.320 --> 00:13:40.480
Do you mean it should only be copiable?
00:13:40.799 --> 00:13:41.279
Yes.
00:13:41.279 --> 00:13:41.840
Okay.
00:13:41.840 --> 00:13:43.120
Potentially, yeah.
00:13:43.120 --> 00:13:44.799
Copyable or I mean, yeah.
00:13:44.799 --> 00:13:48.159
So I made what I did was I was trying to illustrate the point.
00:13:48.159 --> 00:13:55.360
So I made a simple ring buffer type, and it's probably broken by the standards of many people's ring buffer notions, whatever.
00:13:55.360 --> 00:14:01.679
But it requires a size because it needs to know how much storage to create, right?
00:14:01.679 --> 00:14:09.120
Now, me in an alternate universe would have made that size a uh template parameter, but I didn't want to for the sake of this example.
00:14:09.120 --> 00:14:10.480
I made it a runtime parameter.
00:14:10.480 --> 00:14:12.159
So it you must provide a size.
00:14:12.159 --> 00:14:19.360
If you provide a size of zero, it's gonna allocate an array of zero internally, but it's still a valid pointer, valid storage, right?
00:14:19.360 --> 00:14:25.679
So, or actually I might have even put a contract on it saying that the size is greater than zero because I was just trying to illustrate a bunch of different points.
00:14:25.679 --> 00:14:29.120
But regardless, I have something that holds a pointer to a thing.
00:14:29.120 --> 00:14:35.120
Think like unique pointer, but think a unique pointer that cannot be constructed with a null pointer.
00:14:35.120 --> 00:14:40.000
Like that is an invalid use case, a unique pointer that must be constructed with a valid pointer.
00:14:40.000 --> 00:14:51.120
If you move out from this unique pointer, the thing that is left behind, the moved from object, is now in effectively an unusable state, like you're talking about.
00:14:51.120 --> 00:14:56.879
Like I can, well, unique pointer is a tough one, because you can still get back the null pointer that was in it.
00:14:56.879 --> 00:15:08.080
Anyhow, in the ring buffer thing that I illustrated, I now have a function, I now have an object where the only meaningful thing I can do is assign to it again, like you're talking about with an integer.
00:15:08.080 --> 00:15:08.559
Right.
00:15:08.559 --> 00:15:10.559
And so I said, you know what?
00:15:10.559 --> 00:15:26.240
I am, for the sake of the argument, so that we can talk about it, I'm gonna delete the move operations here and say, if moving always puts this thing in a state where it is not usable in any meaningful way, then it shouldn't be movable.
00:15:26.240 --> 00:15:29.039
And I just want people to think about that also, right?
00:15:29.039 --> 00:15:32.399
And I think that's I know, I think it's related to what your argument is.
00:15:32.720 --> 00:15:33.279
For sure.
00:15:33.279 --> 00:15:37.360
And this line of thinking leads us to uh, you know, destructive move, right?
00:15:37.360 --> 00:15:44.879
Which is if we had destructive move, I think your argument
might change and say, well, it is movable because move destroys the old thing, right?
00:15:44.879 --> 00:15:45.360
Right.
00:15:45.360 --> 00:15:45.840
Yeah.
00:15:45.840 --> 00:15:46.799
But we don't.
00:15:46.799 --> 00:15:56.879
And but many, you know, a certain a workable mental model, certainly a workable mental model is that after you move something, you should only assign or destroy assign to it or destroy it, right?
00:15:56.879 --> 00:15:57.279
Yes.
00:15:57.279 --> 00:16:00.080
That that is that is where many people start.
00:16:00.080 --> 00:16:03.440
That is how many people think of things, that is certainly a workable mental model.
00:16:03.440 --> 00:16:13.039
It happens that in the minutiae of C, that is not quite correct because it after it's moved from, it still is a member of the class.
00:16:13.039 --> 00:16:14.960
Its invariants still hold.
00:16:14.960 --> 00:16:18.480
Functions that don't have preconditions may still be called.
00:16:18.480 --> 00:16:25.039
And there are details of implementing some containers and or algorithms perhaps which rely on some of those things.
00:16:25.360 --> 00:16:31.360
And there's no way to know if the object has ever been moved from.
00:16:31.360 --> 00:16:38.720
If you ever pass anyone an immutable reference to this thing, it's possible they moved it.
00:16:38.720 --> 00:16:39.120
Right?
00:16:39.120 --> 00:16:39.440
Yeah.
00:16:39.440 --> 00:16:44.720
Like you you you pass an L you pat you think you're passing an L-value reference to a function.
00:16:44.720 --> 00:16:46.399
Haha, joke's on you.
00:16:46.399 --> 00:16:49.039
Internally inside the function, they still called stdMove.
00:16:49.039 --> 00:16:56.240
They cast it to an R value reference, they moved out the thing, and when your function is returned to you, you have an object that has now been moved from.
00:16:56.240 --> 00:16:57.679
There's no way to enforce it.
00:16:57.679 --> 00:16:58.240
Right.
00:16:58.240 --> 00:16:59.519
So, yes.
00:16:59.519 --> 00:17:03.039
Like the ideal, but we but but it's still C.
00:17:03.039 --> 00:17:05.839
The ideals are great, but we're programming it C.
00:17:05.839 --> 00:17:07.839
Yeah, I know.
00:17:10.319 --> 00:17:13.920
Well, as as I've been listening to this, you know, just hanging on for dear life.
00:17:13.920 --> 00:17:26.160
I've had this little voice in the back of my head while you know Jason and the second part of this conversation is talking about the multidimensional extension to that Howard Hinnan table, and I feel like uh my my brain is vibrating.
00:17:26.400 --> 00:17:38.799
By the way, I think that table certainly one of the early talks Howard gave with that table in it was a criminally underviewed talk, which I think I can dig up the links, and it was a talk at Bloomberg, it was an invited that Howard gave up.
00:17:39.039 --> 00:17:47.759
Alright, I will definitely I mean I have already, because I've been trying to at least, if not, find the links, get the you know, type the name down in the future.
00:17:47.759 --> 00:17:56.400
I have the article that meant and in the bottom of the image there is a hyperlink to the talk that that Howard Hinnant gave.
00:17:56.400 --> 00:17:57.759
I'm not sure if it's the exact same one.
00:17:57.759 --> 00:17:59.599
That's a problem with images, folks, though.
00:17:59.599 --> 00:18:07.279
You know, you can't click on the hyperlink in a in a JPEG or a PNG, or at least not yet, you know, maybe some future uh photo format.
00:18:07.680 --> 00:18:13.920
Uh send it to Claude and ask it to uh extract that URL for you, and then you could click on it.
00:18:14.240 --> 00:18:14.480
Maybe.
00:18:14.480 --> 00:18:19.920
I'm not sure that's the best you've uh you could just type it into the browser.
00:18:19.920 --> 00:18:22.400
Uh or you could just search for Howard Hinanth.
00:18:22.400 --> 00:18:29.680
I was also gonna say, we have we haven't actually reviewed uh, you know, maybe so yeah, talk a little bit about the other talk and we could talk about the comfort.
00:18:29.680 --> 00:18:35.599
Yeah, but like CPPCon, I I know Betton, you were only there for Friday, but uh Jason, uh I imagine you were there for the whole week.
00:18:35.599 --> 00:18:39.599
I mean you can tell us true or false, and and maybe you saw some talks while you were there.
00:18:39.599 --> 00:18:49.920
Like I always when I was a listener before I was a podcaster, I always liked getting like highlights of oh, I should definitely go watch this talk instead of having to sift through all hundreds of them to find the best one.
00:18:49.920 --> 00:18:52.480
So if you have any recommendations, if you don't, that's fine.
00:18:52.480 --> 00:18:53.599
But yeah, over to you.
00:18:53.599 --> 00:18:54.160
All 17.
00:18:54.720 --> 00:19:01.279
I'm gonna say unfortunately, I don't really have anything intelligent to tell you about CBPCon because I was absolutely wiped out.
00:19:01.279 --> 00:19:04.319
I flew from Europe, as many people do.
00:19:04.319 --> 00:19:14.160
But um, and then I taught the workshop on Saturday and Sunday, and then I actually had to fly to another client on Monday night, and I got back on Tuesday.
00:19:14.160 --> 00:19:14.799
Oh wow.
00:19:14.799 --> 00:19:25.920
So I missed like, yeah, I missed basically all of Monday and Tuesday, and then I had my own talks on Wednesday and Friday and a book signing on Thursday, and it was just like I I I wasn't really present.
00:19:26.480 --> 00:19:28.799
Well, in that case, I'm gonna plug a couple of talks.
00:19:28.799 --> 00:19:37.440
One, one by Dave Stefan, who is a regular at Denver Meetup, and it's called uh Refactoring in Three Acts or something of that.
00:19:37.440 --> 00:19:39.200
A Tale of Three Acts.
00:19:39.200 --> 00:19:40.400
I think that's a good talk.
00:19:40.400 --> 00:19:43.519
That is actually on YouTube, unlisted at the moment.
00:19:43.519 --> 00:19:48.880
But the actually it seems like the early access talks are free for everyone.
00:19:48.880 --> 00:19:49.920
I have no idea.
00:19:49.920 --> 00:19:50.960
I'm not sure.
00:19:50.960 --> 00:19:54.880
And the other talk I'm gonna plug is of course my colleague Michael Case's talk.
00:19:54.880 --> 00:19:56.960
That was on the Friday, so I did see it.
00:19:56.960 --> 00:20:01.359
And he was showing, and now I've forgotten the name of the talk, but Connor, no doubt you could dig it up.
00:20:01.359 --> 00:20:12.880
He was talking about the thesis, the abstract of his talk said, you know, doing basically doing doing firmware slash bare metal firmware with with contemporary C.
00:20:12.880 --> 00:20:23.680
Bringing bringing firmware into the the contemporary practices rather than staying in escaping 1996 was I think one of the phrases in the abstract.
00:20:23.920 --> 00:20:25.680
Alright, I will link to both of those and yeah.
00:20:25.680 --> 00:20:26.720
Be sure to check those out.
00:20:26.720 --> 00:20:29.519
Jason, do you want to h highlight any of your other talks you've given?
00:20:29.519 --> 00:20:42.000
And I should say I I promised my wife I would uh change a diaper in in it, so we have to uh time box the uh the question is how did you how did you time the child is what the real question I have here.
00:20:42.400 --> 00:20:45.920
Oh, I mean I imagine the diaper just needs to be changed and oh yeah.
00:20:45.920 --> 00:20:48.559
In the first month it's like a dozen times a day at least.
00:20:48.720 --> 00:20:49.200
Yeah.
00:20:49.200 --> 00:20:51.839
You know, without I you know what I'm gonna do?
00:20:51.839 --> 00:20:56.000
I'm gonna instead plug Dave's talk, which I have not seen yet.
00:20:56.000 --> 00:21:19.119
Because I have realized with side conversations with Dave plus seeing many of his talks, he he usually previews them at our meetup that he and I are coalescing, perhaps is the right term, convertible converging on on like how one actually goes about writing code that's maintainable, I think.
00:21:19.119 --> 00:21:26.880
And and so I am sure Tave's talk is good, and if Ben plugs it, then it's definitely good.
00:21:26.880 --> 00:21:42.079
And uh yeah, like you'll almost certainly I'm guessing that the average person who watches it will be slightly annoyed and say, I can't do that in my code, but then it's gonna bother you for the rest of your life because you're gonna wonder if you can pull it off in your code.
00:21:42.400 --> 00:21:42.640
Yeah.
00:21:42.640 --> 00:21:46.799
You're probably you're making me think certainly of the function length idea.
00:21:47.200 --> 00:21:47.519
Yes.
00:21:47.519 --> 00:21:48.480
Functional length.
00:21:48.480 --> 00:21:50.960
And so another talk, yeah, function length.
00:21:51.279 --> 00:21:54.400
The line length of functions, the number of lines in a function.
00:21:54.640 --> 00:21:54.880
Yeah.
00:21:54.880 --> 00:21:57.279
So they definitely asks in that talk.
00:21:57.440 --> 00:21:58.000
Sorry, Karen.
00:21:58.400 --> 00:21:59.519
And he oh no, he has.
00:21:59.519 --> 00:22:04.799
Very small numbers, what people most people would could think can to be impossibly small.
00:22:04.960 --> 00:22:08.160
And we should ask Connor.
00:22:08.160 --> 00:22:10.559
What do you think is the outside of APL?
00:22:10.559 --> 00:22:11.279
Let's say you're writing.
00:22:11.279 --> 00:22:13.759
Yeah, yeah.
00:22:13.759 --> 00:22:14.480
Yeah, right.
00:22:14.480 --> 00:22:17.759
What do you think is a how small is small?
00:22:17.759 --> 00:22:27.119
Is or what would you can the slight slightly more focused question is what length of function would you be wary about okaying in the code review?
00:22:27.119 --> 00:22:30.079
You know, if you saw a thousand line function in the code review, would that be too long?
00:22:30.079 --> 00:22:30.480
No, yeah.
00:22:30.480 --> 00:22:31.759
I mean that's way past the threshold.
00:22:31.759 --> 00:22:32.799
That would be okay.
00:22:32.799 --> 00:22:35.759
So if you saw a hundred line function, it depends.
00:22:36.000 --> 00:22:44.319
It depends, but like I uh in general, depending on the level that you're at, I really think my favorite functions are like, you know, five to ten.
00:22:44.319 --> 00:22:49.200
Like the grokkability and understandability of it is just like obvious.
00:22:49.200 --> 00:23:00.000
As soon as you as soon as I'm scrolling on GitHub in your PR, and I I do the the side by side, I don't do the unified, so it's like however many lines that is, then I then I'm asking.
00:23:00.000 --> 00:23:01.519
I'm not saying it's bad.
00:23:01.519 --> 00:23:05.039
I'm just saying I'm now asking myself, right to be this long?
00:23:05.039 --> 00:23:05.920
Sometimes it does.
00:23:05.920 --> 00:23:10.000
I'm not saying that all functions that can't fit on a single screen are too long.
00:23:10.319 --> 00:23:15.599
But we've entered we've definitely entered the realm of this is outside the ordinary and deserves attention to justify itself.
00:23:15.599 --> 00:23:15.839
Yeah.
00:23:16.079 --> 00:23:26.240
Because like some of the best code that I've seen, it's just it is like it's not even C it's like closure, and all of them are just these beautiful, little, concise, composed, you know, everything.
00:23:26.240 --> 00:23:41.759
It's it's you know what when you hear Stepanov or Sean Parent or or you, Ben, talk about like the composability of Albert, you can see that everything was so beautifully crafted to fit together that you only ever need to invoke, you know, five, six, seven things, and you just read it and it's like it's like reading poetry.
00:23:41.759 --> 00:23:42.559
It's it's so nice.
00:23:42.559 --> 00:23:45.279
And and you never are asking yourself, is this too long?
00:23:45.279 --> 00:23:46.720
Because it's obvious that it's not.
00:23:46.720 --> 00:23:50.079
It's obvious that you know it's just really well written code.
00:23:50.079 --> 00:23:54.000
C plus plus, I I don't find stum you stumble into that as often.
00:23:54.559 --> 00:23:54.880
No.
00:23:54.880 --> 00:24:00.640
The talk I gave at NDC Toronto the expression expression-based C.
00:24:00.640 --> 00:24:01.680
That's what it was.
00:24:01.680 --> 00:24:02.240
Thank you.
00:24:02.240 --> 00:24:03.359
That was directly.
00:24:04.400 --> 00:24:05.599
It is as of a couple months ago.
00:24:05.839 --> 00:24:06.960
It should be online now.
00:24:06.960 --> 00:24:08.480
That one is.
00:24:08.480 --> 00:24:13.759
I created that talk because of the mindworm from Dave from years ago.
00:24:13.759 --> 00:24:14.480
Alright.
00:24:14.480 --> 00:24:16.079
So that talk.
00:24:16.079 --> 00:24:22.319
Watch one of Dave's recent talks, then go watch that talk and and maybe you'll see where I was coming from.
00:24:22.640 --> 00:24:38.319
And Dave has practiced this in a decent sized codebase, you know, like in his in his production codebase, he is he has deliberately uh ratcheted up in CI the requirements for function length or function shortness, you know.
00:24:38.319 --> 00:24:48.799
And he's gone down from, you know, turning it on first and setting it something arbitrary like 100 and fixing those and then bringing it down over time to 50, below 50.
00:24:48.799 --> 00:24:49.920
I think he stopped.
00:24:49.920 --> 00:24:59.039
He, you know, like all of these things, he stopped before perhaps his complete ideal, but he stopped in a pragmatic sense at like 35 or something like that.
00:24:59.359 --> 00:25:05.519
And I've had students from Dave's teams many times, and that seems to be a process that's working.
00:25:05.519 --> 00:25:18.240
And I will say, last my last chat with him, we seem to agree that the only time where you can assume that this rule would be broken is if something where it's just naturally expressed in more lines of code.
00:25:18.240 --> 00:25:24.480
Like for some reason you're decoding a protocol and you naturally have a switch with like 50 case statements.
00:25:24.480 --> 00:25:28.319
Like, and and there's just there's no logical way to split this in half, right?
00:25:28.319 --> 00:25:29.039
Then yeah.
00:25:29.440 --> 00:25:39.839
And you don't, you know, if the compiler could optimize an array lookup into function pointer as well, then maybe you could bring it down, but sometimes performance the case that you can't.
00:25:40.319 --> 00:25:42.720
And but also readability of the code.
00:25:42.720 --> 00:25:47.200
Like sometimes it's it's just it just makes more sense, I think, often, but not always.
00:25:47.359 --> 00:25:47.599
Anyhow.
00:25:47.599 --> 00:26:13.839
I had this talk I was I had this talk that I wanted to give years ago and have never given it, and it was called format-driven development, which sounds kind of like something that a lot of people would disagree with, but it's really more of like a design talk in that like when I think about the that long case statements, like I'm really I'm praying that it's like case, colon, return, you know, single thing, and semicolon.
00:26:13.839 --> 00:26:30.960
And
like it, it like drives me not insane, but just like there's something about and and I've I've gone on a little in other talks, like I've given other speakers a hard time when they don't like use a monospace font and they don't use like formatting like that because there's oh it's just slideware.
00:26:30.960 --> 00:26:54.240
And I'm like, you're making it harder for people to like use the pattern recognition engine that is in all of our brains, and and so like when you see a case statement like that, and then only one of the case statements breaks into multiple lines and it's in the middle, it's just like, oh, like throw that thing in a function so that like even if all of it's raw code and then you have one function so that you can keep that kind of linear style and aligned style.
00:26:54.240 --> 00:27:00.000
Anyways, that's that kind of stuff I think leads to it goes hand in hand with keeping your functions short.
00:27:00.000 --> 00:27:14.319
Because when you when you try to reduce indentation, when you try to you know keep things linear and symmetric, you just naturally end up with shorter because the easier things to keep symmetric and readable and like and parallel with each other are short functions.
00:27:14.319 --> 00:27:18.960
When you have a big glob, you end up like with things that aren't at the same abstraction level.
00:27:18.960 --> 00:27:24.079
And and yeah, so anyways, I think if I had made the talk, people would have been like, this is stupid.
00:27:24.079 --> 00:27:27.839
You shouldn't you shouldn't be driving the writing of your code based on form.
00:27:27.839 --> 00:27:35.440
Like literally, I've done PRs where like some line was too long, and then I just refactored the whole function just to make it look more it didn't do anything different.
00:27:35.440 --> 00:27:42.400
It was just like reformatting, but at the end of it, it looks so much you would you would imagine I did something amazing there, but really it was just uh functionality.
00:27:42.400 --> 00:27:45.680
And I think that is my wife pinging on what's uh asking me to go.
00:27:45.759 --> 00:27:49.680
So you have more important things to do than talk to us.
00:27:49.680 --> 00:27:50.240
You do.
00:27:50.240 --> 00:27:52.880
Yes, well absolutely arguably, I guess, yeah.
00:27:53.039 --> 00:27:55.920
You do raising a baby is more important.
00:27:55.920 --> 00:27:56.559
Indeed.
00:27:56.559 --> 00:27:58.400
Yes, it is, it's more important.
00:27:58.400 --> 00:28:04.480
Uh but thank you so much, Jason, for taking the time uh across the pond at a different time zone and uh to Ben as well.
00:28:04.480 --> 00:28:05.680
I guess you're in a different time zone as well.
00:28:05.680 --> 00:28:06.720
Yeah, thanks, Jason.
00:28:06.720 --> 00:28:07.519
Yeah, absolutely.
00:28:07.519 --> 00:28:13.039
Hopefully, we'll bump all the three of us uh in a conference in the next three hundred and sixty five days.
00:28:13.039 --> 00:28:13.519
Yeah.
00:28:13.519 --> 00:28:14.400
At some point.
00:28:14.400 --> 00:28:24.559
Be sure to check these show notes either in your podcast app or at adspthepodcast.com for links to anything we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave thoughts, comments, and questions.
00:28:24.559 --> 00:28:25.359
Thanks for listening.
00:28:25.359 --> 00:28:26.960
We hope you enjoyed and have a great day.
00:28:26.960 --> 00:28:29.119
I am the anti price.
00:28:29.519 --> 00:28:29.839
Um