SPEAKER_01

Stable salt is built on stable partition, is built on rotate, is built on reverse, is built on iter swap, right? Range swap. It's abstractions all the way down, and when you get to the bottom, the abstraction, you know, the the the complexity disappears.

Conor

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.

SPEAKER_01

Well, the meaning is what we give it, right? Ultimately we we we we build things, hopefully to make the world a better place. But if if if these kind of quality ideas are important to us, then then these ideas should come along for the ride and should be the way we think about things, I think.

Conor

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 to say we're back. Should we talk about what we're gonna talk about? Or is this the open? Maybe this is the open. Well, well, yeah. I mean, for the for the listener, we were just chatting for the last 20 plus minutes because uh Ben was eating his lunch and an ice cream sandwich, because I had no time to prepare lunch. And now we hit the record button. And we gotta figure out what we're gonna talk about because we don't have any necessarily pre-what do you call them, lined up topics. Anyways, listeners, 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 what we are? So 289? Uh I think so. Maybe it's 288. I might have gotten 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 gonna work. Uh yeah. We might just have to record a couple. I'm gonna have to queue up like at least a month, if not two months. I mean, it's sometimes already like a single conversation gets cut into four episodes, which is a month right there. So I I think like a two two months should give me enough wiggle room.

SPEAKER_01

I would say two months is a good thing to shoot for. Definitely the first month, expect expect to be very sleep deprived.

Conor

not advice or feedback, but just the number one thing people people do tell me that that first month just the fact that 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 gonna be interesting. Like as as soon as she's like less than seven hours a night, she is pining for more sleep, so it shall be an adventure.

SPEAKER_01

Yeah, well, you j you go to sleep when the baby sleeps, I think. That's what people say. That's kind of what you have to do.

Conor

Yeah.

SPEAKER_01

And the baby only sleeps two hours at a time, usually, sort of thing.

Conor

Fingers crossed that we get one of those babies that just very quickly I've I have a number of friends and uh 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.

SPEAKER_01

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 uh get used to the small hours. I used to watch I used to my oldest, I used to have him on a a pillow and I used to be on the couch and I would do 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 3 a.m. 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 between like 2006.

Conor

Oh, that's like right when it didn't when did YouTube start? I think 2005 it launched. I was I was gonna say that's like right right when it there must have just been like a couple cat videos on on YouTube. Well the the elephant video and yeah, some cat videos. Wow. Yeah, I didn't actually I've actually been concerned, that's well, not that it 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 uh 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 uh 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 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.

SPEAKER_01

Anyways, enough baby talking about it you have that ahead of you.

Conor

Yeah. Stay tuned, listener, for uh, I don't know, what do you call it? Parent corner coming to a podcast near you.

SPEAKER_01

Parent corner.

Conor

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 uh 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 it was gonna 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 gonna be that hard, but we've never gotten the update on that. Anyways, what are our topics for today? Is there anything at the top of mind that you'd like to chat about?

SPEAKER_01

What have you been up to since we last spoke? Because I uh um of course I went to C now, so we could talk some about that.

Conor

Oh yeah, I totally forgot that I also went to NPC. 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 CPP North. Sure, that's a great to topic for at least our first episode. How was uh 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 that's right. It's not available online, but should be at some point in the future, correct?

SPEAKER_01

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 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 the 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 typically get to talk about with in in your day-to-day job with your coworkers, you get to talk in a different a different level with people who understand different things. And you get to learn a lot. You get to learn a lot.

Conor

Yeah. Yeah, C Now was actually my first conference ever back in 2019. Right. Yeah, it was 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.

SPEAKER_01

That's Yeah, and it's not it's not that it's a different it's a different vibe. It's like 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 and getting 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.

Conor

Yeah, yeah, absolutely. So what were the I mean I I brought the schedule up, but you know, it's would be very boring for me to scroll through and be like, oh, tell me about this. So what were the 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 uh or I don't know what order you want to do.

SPEAKER_01

How how did your talk um Well let's see, let's I I've got the schedule here too. Let me just check the keynotes to begin with. Yeah, I mean uh so Barry Revzin 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 this was another I think basically, you know, he's a really good speaker. He knows 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 sever there were some slots where I couldn't decide which talk to go to, which is always always the case. A little bit frustrating, but you just have to wait for the videos to come out. I really liked Rob Leahy's talk, or actually he gave a sort of double slot talk about about using senders at at sort of the lowest level. I forget the name of the talk, you have it up there? Towards async everything part one of the things. That's the one. Yeah. So he really presented a cut, like I say, back-to-back talks, which actually standalone, but one also leads 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 IOU ring. That was 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.

Conor

Yeah, he has a background in theater or some kind of speaking, which came out. 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 seemed like he had 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 he 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 uh presenter.

SPEAKER_01

So I thought his talks were great. I also thought Michael Case's talk was one that I'd 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 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 a team thing and a and a 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 f kind of naturally flow from it. There is a prerequisite for the other two. 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 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 in there. But it's more of these intangible things or somewhat less tangible things than than the other measurable parts. How nice is the code to work in in the sense of, you know, does changing one part cause ripple effects through other parts? Is it is it compartmentalized, is it is it uh 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.

Conor

Yeah, that sounds like a very interesting talk. And definitely Yeah, I don't know how I mean uh I was thinking if you tried to measure that stuff, like is it possible? I know that Clang tidy has a like complexity heuristic of like based on the nestedness of stuff, but that doesn't really capture like there there's definitely like like if you design something, I remember one time early in my career there was like a 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 uh 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 I knew I was gonna 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 gonna 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 bing, 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 there's no because every system's gonna be completely different, like extensibility of a system is completely defined by like what kind of system you're building. There's no right there's no like uh script you can write that's gonna like assess you have built a very a very good like right.

SPEAKER_01

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 and correctness and you know uh performance are things we can measure below that level, but at the level of the API, um it's much more now that 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? Certainly, 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.

Conor

Yeah, absolutely. That sounds like a I mean, none of these talks are out, right?

SPEAKER_01

Not yet, no.

Conor

Yeah, they're gonna. 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 the talks are up, you can link them now. So we will be sure to link to these when they are out.

SPEAKER_01

Yeah. Well, there are a couple of papers I would like to point you to, Connor, that came across my feed and and I sent them to Michael while he was making his talk, and you know that they they are really important, I think. So I think back in February or March, so if it's a fairly recent paper, uh 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 the the the uh 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 we call it debt, but it's not really debt in a finance sense, because you know, in the financial world, debt is a tool that that you know like you can use. That 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 to distill it to something very simple, we could say it's uh 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 high level, we could say technical debt correlates with ability to or or lack of ability to change the software. Okay, so it's a it's a thing that exists in the software, in the code. Whereas cognitive debt, cognitive debt talks about the 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 and we see that, you know, as people leave the team, they take with them the cognition and they increase and they might increase the cognitive debt, you know. In particular, if they had ownership over one piece and they leave, then the knowledge of 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 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 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, you this is tell me if this is ringing true. You've worked on teams like this where you know you've had questions like, why would why we do this? Oh, go ask Alice or go ask Bob, right? They've been here, they've because they've worked here for 10 years, they've they remember, they know. And the so the paper is really interesting because one of the observations is you can you you can fix technical debt, right? You can fix technical debt if you don't have cognitive debt, right? That 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, person who wrote it has left the company or moved on, I've taken it over. What am I gonna do? I'm gonna try and understand it. How am I gonna understand it? I'm gonna rewrite parts of it. You know, it happens like every day. We see it when 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 they hand the project to another team who wants to take it forward, maintain it, maybe add some things in the 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 that 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 uh taxonomy. And and you know, the so the 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 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.

Conor

I mean Well, first I'll say that this is um 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, 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 a 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.

SPEAKER_01

It's certainly uh 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.

Conor

Yeah, yeah, yeah. Anyway, so that was my thought. Your comment saying that AI can't touch. I mean, my first thought was that uh sometimes potentially the intent is there in like the git history of a code base, you know, it's it's there, it's just not at the top serviceable. And is I mean, you know, this is we should we should we should uh save part two of this conversation for updates on AI because I I have been dying to talk to you, but then I I you know I I feel I get the sense that you'd rather talk about other things, but now that now that AI's come up, the door is open for me to walk through. But well okay. But wait, we we'll we'll table that.

SPEAKER_01

Yeah, let's finish the thread. We're on. Yeah, yeah. I mean it dovetails with the idea, you know, that 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 Nauer's paper. It's called Programming as Theory Building. And it's a really interesting So Peter Nauer of if you know the name, if you know Backers Nauer form, that's 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 and so this ties in with this idea of like if 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 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.

Conor

I have never heard that, and I mean my initial thought is that is surprising kind of. I mean Well, 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 like English and communicating that is also imperfect potentially.

SPEAKER_01

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.

Conor

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.

SPEAKER_01

It lends weight.

Conor

Oh, lends weight to the idea, yeah. Well, I don't know. There's my I can tell you that my brain is like pushing back vociferously being like, what do you mean? The the thing that execute that is the sure, like are you 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 uh you can say that the code is a representation, but it 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.

SPEAKER_01

Is that is that not better than like a well let me ask you another question about your experience coding, right? You you currently work on a code base. I'm gonna guess, through no judgment, that some parts of it you consider to be better than others. Yes. I'm gonna 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 and it's a process of discovery of of what 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 and and you might come to a point where you have sufficiently solved that problem, and then you say, That code's good, I'm gonna 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 this 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.

Conor

It depends. It depend um it depends on I think. I'm seeing the gears turn in Connor's head right now. Well, I mean, there's like there's like two different, there's many, what is it, the Walt Whitman, you know, multitudes with something 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, Kadane'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 uh the closest to like the epitome of beautiful, elegant. But that that programmer uh is juxtaposed with a different programmer. Like when I started my career, once again, shout out to Axis, you know, multi, multi-million dollar C code base, originally written in, I believe, BASIC and then ported 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 US federal or state government, because in America there's state-by-state insurance, you know, regulations. And so definitely like the the program exists, I guess you could say, in the regulatory document and needs to be, you know, you know, I don't know, visualized in your head, and then how you're gonna put that. And there's a 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 the person working in that large system who didn't even fully understand how the system worked, 100%. You know, I do think 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 com juxtapose that with like the the code artist, if you will, that uh many people refer to me as. 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 we're only Kajori. We're only like we're only like a fraction of the way through history, you know? It's gonna it's gonna change. Ten years, a hundred years, a millennia? Will we be alive? Nobody knows, folks. Nobody knows if we're gonna 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 I don't know. I'll I'll stop talking and let you respond to what I've said, yeah.

SPEAKER_01

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 the the mathematics. They they are they exist to solve some problem, they exist to do something, right?

Conor

But the idea of self-similarity is one I want to talk about because you know so remind me what Cadan's algorithm is, is that the uh it's the mac it's it goes by a couple different names, maximum subarray sum, given uh negative positive integers. What's the contig what's the contiguous array subarray that equals the largest sum?

SPEAKER_01

So, okay, so what are some applications of that? In other words, that's an algorithm, what what problem does it solve? For example.

Conor

Oh, I'm I'm sure it solves a bunch, but off the top of my head, I mean uh I'm not asking the question to be contrary, you understand?

SPEAKER_01

I'm like, I'm sure it has lots of applications. I'm just asking for examples.

Conor

I don't know if the top of my head we can ask. What are some applications of Cadan's algorithm and computer vision used in 2D image processing to find the brightest or most intense rectangular region in a bitmap, financial analysis? Oh yeah, stock trading, you know. Okay, that's the classical.

SPEAKER_01

So the so the point here is my point that I want to make is that like Cadan's algorithm is one implementation, uh, 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 the the program is distinct from the algorithm that implements it, right? Man, this episode has some dead air.

Conor

Don't worry, we we've got a single button, truncate silence.

SPEAKER_01

Oh, it's gonna make it look like Connor has all the answers all like just like that.

Conor

Well, is it is that the goal, or is the goal just not to waste the listener's time of well, every once in a while 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 you're like so Cadane's algorithm is a solution to finding the maximum subarray sum, and you're saying that that implementation, because Cadane's algorithm is a specific implementation. Sure.

SPEAKER_01

And if your problem is maximum subarray sum, it's a great algorithm. If your problem and again, the idea of self-similarity, right? Yes, it's it's a good way to solve maximum subarray sum. Is maximum subarray sum a good way to solve the problem above it? In the case of vision or finances or the the the applications you mentioned, yes. Okay. But it's 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 when we were talking to Sean, the idea of in-place sort, in place 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 Stepanov'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 iter swap, right? Range swap. It's abstractions all the way down, and when you get to the bottom, the abstraction, you know, the the the complexity disappears.

Conor

Isn't at the bottom like ones and zeros? Uh no. No? I'm gonna say no.

SPEAKER_01

What's at the bottom? I don't know. What? We don't know. Like like we arbitrarily 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 the physical world. I mean, ultimately those ones and zeros you think are nice, good-looking ones and zeros, are really mushy waveforms down deep in the hardware somewhere, then they're not like they don't have straight-line edges. Oh man.

Conor

Have you been writing reading some like deep philosophical books lately? Or this is like no, I've just been working in embedded. So let's take a step back here, because I I feel like I feel like I uh my ice cream sandwich for lunch was not substantial enough foods for my brain to operate at the level that yours 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. Um, programming as theory building. Yeah. And then abstraction and self-similarity. And what does all this mean? It means I don't know.

SPEAKER_01

I it means that uh Well, the meaning is what we give it, right? Ultimately we we we we build things, hopefully to make the world a better place. But if if if these kind of quality ideas are important to us, then then these ideas should come along for the right and should be the way we think about things, I think.

Conor

And so I guess yeah, like 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 then intent debt that'll exist, and AI is never really gonna help peering into people's heads to get the actual essence of the program. Something like that.

SPEAKER_01

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 rein on that one. People aren't talking a lot about the cognitive debt and intent debt, but I think they are really important.

Conor

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 uh I scrambled back on the raft, and so now uh I guess my my question that would I would ask is that if and because I I agree that the use of these AI tools is 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 arg I think 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 mat matter at the end of the day?

SPEAKER_01

Okay, so so so there are two different there are two different things here. One is I think that the the argument around or the 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 LLNs, 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 could 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 maths 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? Uh 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.

Conor

So in other words, you think the answer potentially is different for people on an individual basis?

SPEAKER_01

I yeah, I think people just need to decide, you know, what f what path they want their life to take in that sense.

Conor

Be sure to check these show notes either in your podcast app or at adsphepodcast.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. Thanks for listening. We hope you enjoyed, and have a great day. I am the anti brace. Um