Algorithms + Data Structures = Programs - Episode 288: C++ Now, Lasting Quality & Programming as Theory Building

Episode Date: May 29, 2026

In this episode, Conor and Ben chat about C++ Now 2026, lasting software quality, programming as theory building and more.Link to Episode 288 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)SocialsADSP: The Podcast: TwitterConor Hoekstra: LinkTree / BioBen Deane: Twitter | BlueSkyShow NotesDate Recorded: 2026-05-27Date Released: 2026-05-29C++ Now 2026C++ Now: Keynote: Reflection Is Only Half the Story - Barry RevzinC++ Now: Towards Async Everything Part 1 - Rob LeahyC++ Now: Towards Async Everything Part 2 - Rob LeahyC++ Now: Lasting Quality - Michael CaisseFrom Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AIPeter Naur, "Programming as Theory Building" (1985)Intro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Stable salt is built on stable partition, is built on rotate, is built on reverse, is built on itter swap, right? Range swap. It's abstractions all the way down. And when you get to the bottom, the abstraction, you know, the complexity disappears. So let's take a step back here because I feel like my ice cream sandwich for lunch was not substantial enough food for my brain to operate at the level that yours is operating at right now. Well, the meaning is what we give it, right? Ultimately, we build things, hopefully to make the world a better place. But if these kind of quality ideas are important to us, then these ideas should come along for the ride

and should be the way we think about things, I think. Welcome to ADSP, the podcast, episode 288 recorded on May 27, 2006. My name is Connor, and today with my co-host, Ben. We chat about the most recent C++ now, lasting software quality, programming as theory building, and more. We are back. Well, actually, should we talk about? I was about, I was about to say we're back.

Should we talk about what we're going to talk about? Is this the open, though? Maybe this is the open. Well, yeah. I mean, for the, for the listener, we were just chatting for the last 20 plus minutes because Ben was eating his lunch. I was eating an ice cream sandwich because I had no time to prepare lunch. And now, now we hit the record button.

And we got to figure out what we're going to talk about because we don't have any necessarily pre, what do you call them? Lined up topics. Anyways, listen. You may leave comments on the GitHub discussion for episode 289 if you can hear the creaks of Ben's headphones, and we will address in future conversations. Is that when we are after 289?

I think so. Maybe it's 288. I might have an off-by-one error. Let me check. It is episode 288. I was off-by-one. So we're closing in on 300 episodes. Five years straight.

We haven't missed a week yet. I have been thinking when the baby comes how that's going to work. Oh, yeah. We might just have to record a couple. I'm going to have to queue up like at least a month, if not two months. I mean, sometimes already like a single conversation gets cut into four episodes, which is a month right there. So I think like two months should give me enough wiggle room. I would say two months is a good thing to shoot for.

Definitely the first month, expect to be very sleep deprived. It's just how it goes. That's the number one piece of, not advice or feedback, but just the number one thing people do, tell me that that first month. Just the fact. The baby is waking up every couple hours. And admittedly, between Shima and I, I operate much better on less sleep. And I've done it before.

She does not. So it's going to be interesting. Like, as soon as she's like less than seven hours a night, she is pining for more sleep. So it shall be an adventure. Yeah. Well, you go to sleep when the baby sleeps, I think. That's what people say. That's kind of what you have to do.

Yeah. And the baby only sleeps. Two hours at the time, usually, sort of thing. Fingers crossed that we get one of those babies that just very quickly, I have a number of friends and one sibling that have kids, and I guess extended family through Shima that have kids. And I've heard varying different stories. Some babies, you know, are much better sleepers, much more soon.

Others are not. It's, what do you call it, toss of the dice, what you end up with? Yeah. Yeah, my youngest didn't sleep through the night until he was, I think a year old. That's a long. That's a long time. So get used to get used to the small hours.

I used to watch, I used to my oldest, I used to have him on a pillow and I used to be on the couch and I was doing the feeding in the middle of the night and I would watch reruns of Daltrek Next Generation because that was the only good thing that was on at like 2 a.m. or 3am

or whenever it was. Oh yeah, this must have been pre, like YouTube pre-streaming. YouTube was YouTube was around, but it was in the very early days. Yeah, I'm talking like 2006, right? Yeah. Oh, that's like right when it didn't, when did YouTube start? I think 2005 it launched.

I was going to say, that's like right, right when it, there must have just been like a couple cat videos on YouTube at that point. And the elephant video and, yeah, some cat videos. Wow. Yeah, I didn't actually, I've actually been concerned. That's, well, not that I'm actually concerned about it. I guess we'll start talking about something tech related in a minute. But I've been thinking, because I consume.

so much podcast content and audiobooks in between. And the time to consume that is going to evaporate. But if you're telling me that while you're feeding the baby, I guess in the first few months, it's not like you're having a conversation with the kid while the kid's feeding. You have to entertain yourself. Maybe that is the opportune. Maybe I'll be chomping at the bit, you know,

for the 3 a.m. feeding when my wife's trying to sleep. Maybe I'll be thinking like, thank God. Like, I haven't been able to listen to the most recent, I don't know, insert my favorite podcast, co-recursive. Well, what is my favorite podcast right now? I don't know. Anyways, enough baby talk. Well, you have that ahead of you. Yeah.

Stay tuned, listener for, I don't know, what do you call it? Parent Corner coming into a podcast near you. Your Parent Corner. Yeah, late 2027. But I promise I won't disappear. You know, there's a podcast I listen to called Tomorrow. FM or something like that. It's hosted by two front-end web devs, Dax and some other guy.

And I think one of them was having a kid. And then as soon as the kid showed up, they haven't posted a podcast for like months, which I keep waiting for like the come, like the return to the podcast to hear. Because he was saying leading up to it that everyone was telling him and was going to be really difficult. And he said, I really hope that this is just like another thing that's like way easier for me than it is for other people so that he could come back and be like, I knew it was not going to be that hard, but we've never gotten the update on that.

Anyways, what are our topics for today? Is there anything at top of mind that you'd like to chat about? What have you been up to since we last spoke? Of course, I went to C++ now, so we could talk some about that. Oh, yeah, I totally forgot that I also went to... And you went to NDC Toronto. I went to NDC Toronto, the inaugural edition of that version of it, but technically the fifth edition of what was formerly...

formerly CPP North. Sure, that's a great topic for at least our first episode. How was C++ now? I recall looking at the program and I definitely noted a couple talks that I wanted to see. And I know you were giving a talk that I have long wanted to see that was never recorded before. And it's not available online, but should be at some point in the future, correct? Yeah, it was recorded in Aspen. So to answer your first question, it was great. really good conference as always. It just feels like, you know, it's like a holiday because you're going to Aspen.

It's a beautiful place and you're going to see friends who you've met there, many of whom now I've known for a decade and have become friends. And you're getting to talk about like the sort of, I don't know how to describe it, the high level stuff of engineering. Like you're getting to talk about topics that you don't. don't typically get to talk about in your day-to-day job, with your co-workers, you get to talk at a different level with people who understand different things. And you get to learn a lot.

You get to learn a lot. Yeah. Yeah, C++ Now was actually my first conference ever back in 2019. Right. Yeah, it was fantastic. You know, like you said, you're the type of person that goes to a conference in general, let alone C++ now is you're with like-minded folks when you are there. Yeah, and it's not that it's a different, it's a different vibe.

It's not just like, it's not like you work with people who are, who are not intelligent, right? But it's just like when you're in the day-to-day, you can't sort of stick your head up and getting a break, getting a go to a conference and just step away from work. It's really important, I think, to be able to do that. and just just kind of broaden your perspective a bit yeah yeah absolutely so what were the I mean I brought the schedule up but you know

it would be very boring for me to scroll through and be like oh tell me about this so what were the sure sure you remember what were the highlights of the talks that you went to see obviously you couldn't see all of them and then also I don't know what order you want to do how did your talk well let's see let's I've got the schedule here too let me just check the keynotes to begin with

yeah I mean so Barry Reveson gave the first keynote, and I think that was a really good one. It was about reflection. He's given several talks on reflection now. This was another, I think, basically, you know, he's a really good speaker. He knows that he knows all about reflection, and it was a really good opening keynote. Aside from that, the talks which stood out to me, there were some slots where I couldn't decide which talk to go to, which is always the case, a little bit frustrating. but you just have to wait for the videos to come out.

I really liked Rob Layhe's talk, or actually he gave us a double-slot talk, about using senders at sort of the lowest level. I forget the name of the talk. You have it up there? Towards async everything, part one and part two. Yeah. So he really presented a cut,

like I say, back-to-back talks, which actually stand-alone, but one also leads it into the other, right? And he was talking about using senders to drive the sort of lowest-level, OS-level mechanisms of asynchronous I-O. So I-O-U-ring. That was really good. And I definitely want to see those talks again when they come out on video. There was a lot of information in there.

Rob is an extremely polished speaker. Yeah, he has a background in theater or some kind of speaking, which, came up, we interviewed him once while we were walking in Venice after having like a couple glasses of wine. And I could not get over how like you seem like he'd been preparing for this moment his entire life. And I was like, how are you more composed than like some other folks we have interviewed? And I think you mentioned that, yeah, he used to do some kind of theater or what do you call it, not Toastmasters, but I have to have to look it up what he did. Something like that. He's a very, very polished presenter.

So I thought his talks were great. I also thought Michael Case's talk was one that I've been waiting for for a while. It's called lasting quality. And he talked about the idea of structural quality in code. So this is to be contrasted with, so the kind of quality that we're used to is, we might say one pillar is functional quality, right? So that's things like, does the code? meet the specification? Is it, you know, is it, is it, is it bug free as far as we can make it? Does it,

does it perform well? These are functional, this is functional quality, right? And then another pillar of quality is process quality. And this is like, can we deliver on time? Can we repeatedly perform this for the organization without the team burning out? You know, this is a process quality is a kind of a team thing and an execution thing, right? And then, and both of those, things functional quality and process quality they tend to be you know they're the things we can measure basically and so they get measured right and so they get used the third pillar structural quality is actually the most important and the one that is least measurable and therefore the one that is least talked about or measured in organizations but if you have

structural quality the other two kind of naturally flow from it there is a prerequisite for the I do. And structural quality is things like, you know, things that we, when we say code is beautiful, we have, we, we know what we see, right? We know, we know when we see beautiful code and that beautiful code is, has good structural quality. And it's things like, is it maintainable, is it testable? Is it efficient, right? Is it in there? But it's more of these intangible things or somewhat less tangible things than the other measurable parts. How nice is the code to work, in a sense of, you know, does changing one part cause ripple effects through other parts? Is it compartmentalized?

Is it abstracted and composed and things like that? These are things that is much harder to measure, right, in a quantitative way. But structural quality is, you know, if you don't have that, everything else is worse. And if you have that, everything else is better. Yeah, that sounds like a very interesting talk. And definitely, yeah, I don't. know. I mean, I was thinking if you tried to measure that stuff, like, is it possible? I know that Klang-Tidy has a, like, complexity heuristic of, like, based on the nestedness of stuff, but that

doesn't really capture, like, there's definitely, like, if you design something, I remember one time early in my career, there was, like, report system within the software that we had, and you could add these, what were called category reports. Shout out to anybody that works on the Axis software system. And I remember at one point I had to add like a nested category report. I don't know if the code was good at the time because I was so early in my career. But I remember I knew I was going to have to do this like multiple times with multiple reports. So I did it in such a way that like I did a ton of upfront work in order with the like not just to hack this one thing in, but like with keeping in mind I was going to have to do this a bunch of times. So it was a ton of work the first time.

But then subsequent times, right. It was very, very easy to just like make a couple surgical changes, Bada bada boom, everything worked. And yeah, like, there's no good way of, how do you, how do you quantify

the, like, ease of extending a system? Like, there's no, because every system is going to be completely different. Like, extensibility of a system is completely defined by, like, what kind of system you're building.

There's no, there's no, like, a script you can write that's going to, like, assess. You have built a very, a very, like, right? It's not,

it's much less measurable, right? it's exactly but it does correlate with the idea of software design right so the design of systems being this kind of separable idea from the implementation right it correlates with the idea of like you know a hallmark of good structural quality is having good APIs well what do we mean by good APIs it's it's a good design it's one that can be composed and is appropriately abstracted it's one that doesn't do unexpected things when you start putting different parts together, right? And it's not, you know, it's not really about the implementation at that level, you know, implementation and correctness and, you know, performance are things we can measure below that level. But at the level of the API, it's much more.

Right now, there are some things like, you know, performance arguably is a feature of an API, or at least it is possible to write APIs which preclude the best performance, right? And it's possible to write other APIs which are more sympathetic to performance. But I think even there, we're talking more about, it's more like efficiency versus performance, right? If we can say efficiency is not doing extra work and performance is doing the work you have to do as quickly as possible, right? So performance is more of an implementation concern. Efficiency is an API concern, perhaps. Yeah, absolutely.

That sounds like a, I mean, none of these talks are out, right? Not yet, no. Yeah, they're going to, but anyways, as always, we always talk about these talks, and then I'm sure a few of the listeners go and check. We will have links that link to nothing while the talks are not available. And then either I check sporadically or sometimes someone will message me on their choice of social media platform saying, oh, the talks are up, you can link them now. So we will be sure to link to these when they are out.

Yeah, well, there are a couple of papers I would like to point you to, Conner, that came across my feed, and I sent them to Michael while he was making his talk. and, you know, they are really important, I think. So I think back in February or March, so it's a fairly recent paper, a researcher, I assume, her name is Margaret Ann Story, she's at the University of Victoria, Canada. She published a paper that's called

From Technical Debt to Cognitive and Intent Debt, and the subtitle is Rethinking Software Health in the Age of AI. But the sort of taxonomy here, of debt is what's really interesting, right? So technical debt is a term we're familiar with. It tends to be, we call it debt, but it's not really debt in a finance sense because, you know, in the financial debt is a tool

that, you know, like you can use. That is much less the case when we talk about technical debt. We think of it as just a bad thing. Now occasionally if you have, you know, occasionally if you're a startup and you want to ship really fast, you might make a, you might make a definite decision to take on technical debt. But by and large, it's something we try to avoid as engineers, right? Anyway, so technical debt is well known.

Technical debt is, you know, to distill it to something very simple, we could say it's a software system that has technical debt is harder to change, right? So it's some kind of, you know, just to say it very simply at a higher level, we could say technical debt correlates with ability to, or lack of ability. to change the software. Okay, so it's a thing that exists in the software, in the code. Whereas cognitive debt, cognitive debt talks about the team who built the software and their understanding of the code, right?

The code can work, but also the team might be losing understanding of how it works. That's cognitive debt, and it lives inside people, right? And we see that, you know, as people leave the team, they take with them the cognition and they might increase the cognitive debt, you know, in particular, if they had ownership over one piece and they leave, then the knowledge about how that piece works is now leaving with them, or at least some of it is, right? And then the third kind of debt is intent debt. This is arguably the most important kind of debt of all. And this is the, this is the knowledge about why we made those decisions in building the software, right? Why does the software work this way? Not, not, it's different

from tech debt, obviously. It's different from cognitive debt in the sense that it is not really thinking about how the software works and how we understand it, but it's talking about why did we write it that way in the first place. What problem were we solving? And what are the problems today? and are they the same, right? And that is very difficult to fix if you lose, right? That is typically on many teams that is held by a couple of people who've been on the team a long time and they're the people you go to to ask about things, right? Why are we doing it this way?

You know, tell me if this is ringing true. You've worked on teams like this where, you know, you've had questions like, why do we this? I'll go ask Alice or go ask Bob, right? They've been here because they've worked here for 10 years. is they remember they know. And so the paper is really interesting because one of the observations is you can you can fix technical debt, right? You can fix technical debt if you don't have cognitive debt, right? Or at least it's easier to, right? And also you can fix cognitive debt to some

extent if you don't have intent debt, right? But it's very, very difficult to fix intent debt. and we see these kind of macro level ideas playing out in teams right how many times for instance have you seen or indeed how in terms of yourself have you yourself rewritten something so you could understand it you know here's some subsystem personally wrote it has left the company or moved on i've taken it over what am i going to do i'm going to try and understand it how am i can understand it. I'm going to rewrite parts of it. You know, it happens like every day. We see it when, when, when teams hand over projects that they built to other teams, right? This happens sometimes. This is in the paper as well, I think. Team A builds some library,

some software. They know it intimately, right? They've been involved in building it. They spent a year, two years, whatever, building the software. They know about all the intent, all the cognition. But then, you know, they move on to a different project, they move, they hand the project to another team who wants to take it forward, maintain it, maybe add some things in future. There is only one way that really works, which is if you have a long period of overlap during which the new team can work hand in glove with the old team and ask whatever questions they need to until the knowledge is transferred, right? That is the only way I've really seen that ever work.

And so those are the kind of macro level things that play out as a result of these ideas of tech debt versus cognitive debt versus intent debt. It's a very interesting kind of taxonomy. And, you know, the, so the subtitle of the paper is talking about AI in the age of AI. And it's making the point that, you know, these things are all still important, right? And AI actually runs the risk of increasing these debts, these debts in these three buckets. Maybe if we can control tech debt, that's one thing. And we can maybe do that a little more. But AI really can't touch cognitive debt or intent debt at the moment, apart from increasing them, of course.

AI can't. Connor is looking very thoughtful. right the way in which we use AI at the moment overwhelmingly cannot because cognition lives in the minds of humans

and intent that also lives somewhat in the minds of humans and lives in things like design documents and things that capture why decisions were made and if we're using AI just to implement features, generate code as a glorified

auto-complete yeah, we can review the code it produces, we can make sure as far as we can that the technical debt stays low. But these other two kinds of debt, it's not really speaking to that. They require a different strategy. I mean, well, first I'll say that this is, it is very interesting. I've never thought about cognitive debt or intent debt. And my main thought was it kind of dovetails with the piece of advice from some technical book or something that I've read at one point that says, you know,

a comment should say why, not how. You know, the how should be in the code. But the comment should say, this is the motivation or the reason for why we're doing it. And if the why is obvious, then you don't really need to comment. Your code should be written in a way that, you know, because some people consider comments like an anti-pattern if you've written a code in a way that, like, you know, the best code is self-describing.

But a lot of the time... It's certainly an ideal maybe to strive for. Everything is, of course, imperfect. So, you know, as much as we can strive for that, we never actually achieve that goal. Yeah, yeah, yeah. Anyway, so that was my thought. Your comment saying that AI can't touch, I mean, my first thought was that sometimes potentially the intent is there in like the Git history of a code base, you know, it's there.

It's just not at the top service level. And is, I mean, you know, this is, we should, we should, we should save part two of this conversation for updates on AI because I have been dying to talk to you, but then I, you know, I get the sense that you'd rather talk about other things. But now that, now that AI has come up, the door is open for me to walk through. Well, okay. But wait, we'll table that. Let's, yeah, let's finish the thread. We're on. Yeah, yeah. I mean, it dovetails with the idea, you know, that, was it Gerald Sussman who said, code should be written for humans to understand and only incidentally for computers to execute.

I'm paraphrasing, but it was something of that nature. Yes, yeah. And there is a paper behind the paper, which is in the references, which is Peter Now's paper. It's called Programming as Theory Building. And it's a really interesting. So Peter Nower of, if you know the name, if you know Backers Now form, that's the same person.

The idea, his idea in this paper, which is really interesting is that, A program is not the code. The code is an approximation. The program is the theory built in the heads of the team who build the program, right? And so this ties in with this idea of like, if one team or one person builds a program, it's very difficult for them to actually, one of the chief problems in programming is communicating the theory, right? because the code itself is a very imperfect communication of that of that theory which is the actual program

other ways we have to communicate the theory include documentation diagrams maybe formulae things like that but they're all imperfect right the program is not any one of those things it's not even the code the program is the idea the theory in the head of the people who wrote it I have I've never heard that. And, I mean, my initial thought is that is surprising, kind of. I mean, what's my, my thought is that if you can express precisely the program you want, once it's codified, that is infinitely better than like a description. Or I guess you're saying that, like, what lives in someone's head is the program, not necessarily. Yes.

like English and communicating that is also imperfect potentially. So the code is an expression of the program, but it's not the program, right? Because if it were, then it wouldn't be possible to replace parts of it, like replace an implementation with an equivalent implementation. The fact that we can do that kind of tells us that the code is not the program. This is like mind-bending. Good. philosophical

the code is not the program and because you can replace parts with other parts different implementations that by then definition well it lends weight to the idea I think right it learns weights through the idea

it lends it lends weight oh lends weight to the idea yeah well I don't know I can tell you that my brain is like pushing back visiparously being like what do you mean the the thing that execute, that is the, sure, like,

my brain is like, there's a little voice in my head right now that's saying, like, what are we talking about here? Like, sure, maybe it's what you can say that the code is a representation, but it is a better, you know, well, is it a better representation if, if coded correctly is, is, you know, a thing that can deterministically execute. Sure. Is that not better than like a? Well, let me ask you another question about your experience coding, right?

you currently work on a code base. I'm going to guess, through no judgment, that some parts of it you consider to be better than others. Yes. I'm going to guess that right now, the thing you're working on, you will have perhaps a better idea of it in a week. You know, maybe a thing you're working on right now, you are struggling with parts of.

You have some parts of it down, other parts of you're still discovering. If this isn't quite happening today, then certainly is probably something that has happened to you. And it's a process of discovery of how it should be. And how it should be really is something that is fulfilling or solving a problem you have today. Right. And you might come to a point where you have sufficiently solved that problem.

And then you say, that code's good. I'm going to leave that for a while. But then equally, you might wake up in a month, two months, and think, oh, you know, I remember that thing I was working on and now I see, with this other context, now I see how that could be solved much more easily or much differently or much more in some way that there's something that seems nicer, right?

And so the program, in a sense, is evolving inside your head and the code that's in the machine is always an imperfect representation of it. I mean, you are, well, it depends. It depends on, I think it depends. The gears turned in Connors head right now. I mean, there's like two different, there's many, what is it, the Walt Whitman, you know, multitudes. Yeah, yeah. Something is that there, within me, there's an APL programmer.

And to tell him that, you know, or her, in my case, it's a him, that, you know, always the code is an imperfect representation of the program is just false. I mean, Cadane's algorithm in BQN is, it's the most beautiful. It is perfect, in my opinion. well, I mean, could it be slightly improved on in a different language? Maybe. But it is the closest to like the epitome of beautiful, elegant. But that programmer is juxtaposed with a different programmer. Like when I started my career, once again, shout out to Axis, you know,

multi-million dollar C++ code base, originally written in, I believe, basic and then ported it at one point back in the 90s. And so, you know, a ton of legacy code and technical debt. And absolutely, everything that you said, you know, of I'm trying to implement some feature that corresponds to some regulatory document passed by either the Canadian government or the U.S. federal or state government because in America, there's state-by-state insurance, you know, regulations. And so definitely, like, the program exists, I guess you could say, in the regulatory document and needs to be, you know, I don't know, visualized in your head and then how you're going to put that. And there's tons of things, like the limitation of my understanding of the system as it is. But, and so, yeah, I guess when I think about the person working in that large system who didn't even fully understand how the system work, 100%. You know, I do something, you know, at some point, a year later, I look back and I was like, what was I thinking?

Like, there's obviously a better way to do this than the way that I did it at the time. But then when I, when I juxtapose that with, like, the code artist, if you will, that many people refer to me as, whenever, I start gushing about combinators and and glyphs. I really do think that like APL is an evolution of like mathematics and notation and that like one of my career goals and quests in life is to uncover, you know, I only, I think the notation that we have in mathematics is just like the beginning of, you know, like, what is it, what is it the guy that wrote the history of mathematical notation? Like we're only, we're only like, we're only like a fraction of the way.

way through history, you know? It's going to change. 10 years, 100 years, a millennia. Will we be alive? Nobody knows, folks. Nobody knows if we're going to make it till then. But the point being is that I think that there is some like truth in some symbolic notation, whether that's APL or some evolved form or some extension of mathematical notation. That is like the purest, truest representation of some kind of thing. But I don't know. I'll stop talking and let you respond to what I've said, yeah. Well, let me ask you, I think one of the useful notions we can bring to bear here is the idea of self-similarity.

So, and I think what you said is to some extent true, but alongside the argument here, which is that programs, so programs are not usually this kind of ideal thing that you were talking about, like the, the mathematics. They are, they exist to solve some problems. they exist to do something, right? But the idea of self-similarity is one I want to talk about, because, you know, so remind me what Kadam's algorithm is, is that the... It's the mac, it goes by a couple different names,

maximum subarray sum, given a negative positive integers. What's the contiguous array subarray that equals the largest sum? So, okay, so what are some applications of that? In other words, that's an algorithm. then what problem does it solve? For example. Oh, I'm sure it solves a bunch, but off the top of my head, I mean, I don't know. I'm not asking the question to be contrary, you understand.

I'm like, I'm sure it has lots of applications. I'm just asking for examples. I don't know if the top I have. We can ask, what are some applications of Cadane's algorithm and computer vision used in 2D image process to find the brain? or most intense rectangular region in a bitmap financial analysis. Oh yeah, stock trading, you know. Okay, okay.

So the point here is, my point that I want to make is that, like, Cadan's algorithm is one implementation, and as you say, might be a very elegant one, but it's one implementation we found to solve these problems, right? But it's not necessarily the only implementation out there, right? And so the program is distinct from the algorithm that implements it, right? Man, this episode has some dead air. Don't worry, we've got a single button, truncate silence. Oh, it's going to make it look like Connor has all the answers all, like, just like that.

Well, is that the goal or is the goal just not to waste the listener's time of, every once in a podcast, there's like such a large gap. I'm like, did my podcast crash or something? And that's at like 2.3 times X. The program is separate from the implementation. So, like, so Cadain's algorithm is a solution to finding the maximum sub-array sum. And you're saying that that implementation, because Cadain's algorithm is a specific implementation. Sure. And if your problem is maximum sub-ray sum, it's a great algorithm.

If your problem, and again, the idea is self-similarity, right? Yes, it's a good way to solve maximum subray sum. Is maximum subrace sum a good way to solve the problem above it? In the case of vision or finances or the applications you mentioned, yes. Okay. But it's not. So the idea of self-similarity is like, if I can draw another example, right? If we think about, you know, when we were talking to Sean, the idea of in-place,

sort, in place stable sort, right? that is that before you know 30 years ago that was a research problem about 30 maybe 35 years ago but it was one of Steppenoff's great contributions to the field of algorithms right and and the point is that like there is no level one of the points that I made in my talk or one of my talks recently I forget which one now there is no level below which abstraction fails right There is no distinction between application code versus library code. There should be no idea of like, here's a boundary at an API level below which we hide all of the difficulties and complexity. Right.

No, everything is self-similar as we go down. We build one API in terms of the next. With the result that when we get to the very bottom, frequently things just don't only become less complex. They just disappear. Right. And so stable salt is built on stable. partition is built on rotate, is built on reverse, is built on itter swap, right? Range swap.

It's abstractions all the way down. And when you get to the bottom, the abstraction, you know, the complexity disappears. Isn't at the bottom like ones and zeros? Uh, no? No? I'm going to say no. What's at the bottom? I don't know.

What? We don't know. Like, like, we arbitrate. rarely choose to make the bottom where it is. Yeah, it's convenient for us to to make hardware that deals in binary, right? And so that in a sense is the practical bottom for us right now. But, but that isn't the theoretical bottom, right? That doesn't mean that abstraction runs out at some level. Yeah, ultimately we live in a physical world. I mean, ultimately those ones and zeros, you think a nice, good-looking ones and zeros

are really mushy waveforms down deep in the hardware somewhere they're not like, they don't have straight line edges. Oh man. Have you been reading some like deep philosophical books lately? Or this is like... No, no.

I've just been working in embedded. So let's take a step back here because I feel like my ice cream sandwich for lunch was not substantial enough food for my brain to operate at the level that you're, is operating at right now. So, I mean, we're talking about the paper. And then at some point, we were talking about how the code is not the program.

The program lives inside our head. Yeah. Programming as theory building. Yeah. And then abstraction and self-similarity. And what does all this mean? It means, I don't know. It means that...

Well, the meaning is what we give it, right? we build things, hopefully to make the world a better place. But if these kind of quality ideas are important to us, then these ideas should come along for the ride and should be the way we think about things, I think. And so I guess, yeah, taking a massive step back, it was that AI can't help with cognitive debt and intent debt. And I guess that's why we started talking about this

is because if the program lives in our head and we're doing some level of job, you know, to the extent that the best is a perfect job, you know, sometimes it's a good job, sometimes it's a bad job of encoding the program that lives in our head into your programming language of choice. But, you know, there's a certain amount of cognitive debt that will exist and an intent debt that will exist. And AI is never really going to help peering into people's heads to get the actual. essence of the program.

Something like that. My course? I don't know. You're close. I mean, let's not say, let's not talk in absolutes here. Let's not say flat that AI cannot help. Let's rather say that the way we are using AI right now tends towards increasing cognitive debt and increasing intent debt and increasing technical debt, although we have a better

idea, perhaps, of how to keep a rain on that one. people aren't talking a lot about the cognitive debt and intent debt but I think they are really important okay I feel like I'm back on you know you might be on a very nice yacht and I'm now back on my raft I was in the ocean and I scramble back on the raft and so now now I guess my my question that would I would ask is that if and because I agree that the use of these AI tools is increased increasing cognitive and intent debt. But did people say the same thing back when like C was invented? And people stopped coding an assembly and then people stopped understanding assembly

because you could make the same argument that there was more cognitive debt. I'm not sure about the intent debt, but that people didn't understand that lower level as well. But did it matter at the end of the day? Okay. So there are two different things here. One is, I think, that the arguments around or the taxonomy of technical debt, cognitive debt, intent debt, I think stands apart from AI, right? The subtitle of the paper is like AI might be worsening these things, but I think that idea really stands apart, right? Before we had it, and before we had AI, we could have talked about the same kind of things and identified the same issues, right?

So there's that. So I think that stands alone as an idea. the other to your question right the eternal question of when a new technology comes along it causes atrophy of skills right and and this is just basically true so the question really is so like you know if you if you doubt that's true try and take a high school math paper from 1890 or whatever and you'll find it very difficult i'm sure so it's just in some sense true but the question really is like, does it matter, as you said? And that is a question that, you know, I think, I don't think, I think everyone needs to find

their own answer to that question because there is still value in having those skills. And in a world where people tend not to have those skills, there is even more value as an individual in having them sometimes. Interesting. So, in other words, you think the answer potentially is different for people on an individual basis. Yeah, I think people just need to decide, you know, what, what path they want their life to take in that sense. Be sure to check these show notes, either in your podcast app or at ADSP thepodcast.com for links to anything we mentioned in today's episode, as well as a link to a get-up discussion where you can leave thoughts,

comments, and questions. Thanks for listening. We hope you enjoyed and have a great day. I am the anti-brace.