Future of Coding - Programming as Theory Building by Peter Naur

Episode Date: January 6, 2023

This is Jimmy’s favourite paper! Here’s a copy someone posted on HitBug. Is it as good as the original? Likely not! Ivan also enjoyed this Theory Building business immensely; don’t be fooled by the liberal use of the “blonk” censor-tone to cover the galleon-hold of swearwords he let slip, those mostly pertain to the Ryle. For the next episode, we’re reading No Silver Bullet by Fred Brooks. Links The Witness, again! The Generation Ship Model of Software Development The philosophy of suckless.org Stop Writing Dead Programs, a talk by Jack Rusher, gets a whole new meaning! Someone rewrote Super Mario 64’s code to run faster and better on original N64 hardware. Music featured in this episode: Speed x Distance = Time by Blonde Redhead from the album In an Expression of the Inexpressible which, upon reflection, is actually not Ivan’s favourite. That’d be Melody of Certain Damaged Lemons. Hey listener! Send us questions so we can answer them on the show. Like, “How do you turn your worms?” Or, “What’s so great about prepromorphisms anyway?” We’ll answer them, honest! Send them here: Ivan Jimmy Or just DM us in the FoC Slack. futureofcoding.org/episodes/061Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

All right, what's Ivan going to think of my favorite paper? Is he going to call it ugly? All right, sure. And we picked this one because Ivan, at the end of the last recording, was talking about we always end on a sad note. And I picked this because I will always be happy talking about this paper. That's very warm and sweet of you jimmy and for an episode that will definitely come out just in time for

christmas oh yeah yes all right so all right let's let's dive in let's dive in programming as theory building by Peter Naur. Yeah, I do think this is a text that tries to make its main point like 12 times over and over again, right? Like it keeps trying to get you to come back to it, which might seem ridiculous, but even despite having done that, it is so misunderstood.

Yeah. Like Donald Knuth had talked about this paper and said that he completely agrees with it and then went on to say he disagrees with the major premise of it or the major point of it, which I just found so, wait, you think it's great and you agree with the idea and then you totally disagree with what Naur thinks is a main outgrowth of what he discusses here.

So I think it's interesting. So yeah, we can start the first paragraph. So the printout we're using, I'm just going to do this little meta thing here. The printout we're using is from some Agile person. I can't remember which book this Agile person recreated the Naur paper in. But we're going to completely ignore all of their commentary on it because their commentary is awful.

I don't know who this Agile person is, but they completely misunderstood the paper and they make me incredibly mad. And I put big X's across all of their sections to make sure I didn't read them because I would just get angry and turn this into something it's not supposed to be. Just as a little bit of color, one of the things that they talk about immediately after the end of the paper, after the end of the now, where they have their little kind of closing remarks, and the very first paragraph they get into talking about extreme programming. So anybody who knows what that is should know just exactly what kind of a take they're going to have on this.

Yeah, and they try to twist now into being for extreme programming in this paper. And it's like, no, stop. Yeah. Stop. They do talk a little bit about metaphor, which I don't dislike. It was really funny. I went through an Agile training that was like a five-day long Agile training. Yeah. through an agile training that was like a five day long agile training yeah and they got this whole section on the history and they went on xp and they were talking about it and they said they

said metaphor and they skipped it like they just and i was like what's that one and they explained to i was like they're like it's not useful though i was like that's literally the only useful thing yeah that i can think of in this whole workshop it It's, it's worse than that in this, in this little, um, bit at the end, because they talk about metaphor and they give some lovely examples like, you know,

an assembly line, right? You can imagine that an assembly line is a useful metaphor for communicating some aspect of a program. Uh, but then another example that they give as a metaphor is the model observer design pattern. Everybody's favorite metaphor.

Uh, so so yes it's oh that was supposed to be a metaphor i wasn't supposed to put it in my program yeah it's not actually uh it's not a a pattern with a with a specific technical definition that you're supposed to conform to it's uh it's something that will make you imagine many comparisons between these things it's a it's something standing in as a colorful example of something else that's meant to spark the mind. My favorite metaphors are profunctors. Hey you, yeah you, opening the Twitter client or the Mastodon website or Slack

to send me a nasty screed about how i'm totally misunderstanding the meaning of metaphor i will respond to whatever message you send with a photo of me holding a copy of george lakov's metaphors we live by so there don't even don't even bother all right okay i'm gonna read this uh the starting paragraph of the correct, the real paper, not the garbage that came before it. Alright. The present discussion is a contribution to the understanding of what programming is. It suggests that programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory of the matters at hand. This suggestion is in contrast to what appears to be a more common notion,

that programming should be regarded as a production of a program and certain other texts. To me, that was a beautiful intro to the paper. I have that highlighted. And of course, you know, it will make that point again and again. Yes. So we start off very direct what the point of this paper is, and I think it's actually really crucial to keep this in mind, because I don't know that the structure of the paper or the arguments are really good at reinforcing this point. No, yeah. They're a little like, you kind of have to read Naur's mind as to why he thinks this reinforces his point. He doesn't really spell it out for you. But this is really important that

the activity of programming is not about writing programs, or writing documentation, or tests, or any of that. It's about building up knowledge in our heads. I think that that's wonderful, because I love that aspect of programming so much more than I like having a useful program at the end of the day. Spoken like a philosopher. Okay, so we start off here,

and the meta of what the next sections are supposed to be about is they're supposed to show why we would want to move away from this idea of programming as the production of a program and other texts. Because he thinks that if you have that view of programming, there are certain facts about the world that are going to be hard for you to explain. And he wants to tell some stories about the things that

actually happened, people building programs, and difficulties that happened, and then try to make you offer an explanation for why those difficulties came. And his main claim is that his view, this programming as theory building view, helps explain it, and the programming as text production does not. not and and just before we get into the actual subject of that first you know section after the intro i wanted to because i have this passage highlighted as an example and i'm going to read it not because i want to say that this is bad writing even though my notes that i've written for myself would suggest that that is what i think but i want to read it because I think it will be fun for me to read aloud and fun to listen to. Let's hear it.

All right. What I am concerned with is the activity of matching some significant part and aspect of an activity in the real world to the formal symbol manipulation that can be done by a program running on a computer. With such a notion, it follows directly that the programming activity I'm talking about must include the development in time corresponding to the changes taking place in the real world activity being matched by the program execution, in other words, program modifications. Yes, that is literally the passage I have highlighted as Ivan is gonna make a big deal about that. Not even joking.

With such a notion, it follows directly that the programming activity I'm talking about must include the development in time corresponding to the changes taking place in the real world activity being matched by the program execution. In other words, program modification. Yeah, that little, is it a singular no it's two sentences it's two sentences yeah but it should have been taken out of the paper or or written uh to like let's see here uh i'll read the first couple of words in the last couple of words what i am concerned with is the activity of program modifications that That's it, right? He's concerned with this whole paragraph

basically says, the first thing that we're going to look at when we look at the theory building view of programming is how that theory building view explains some of the things that happen when programmers go to modify a program. If you're going to go and modify a program what bearing does theory have on that activity so let me pigeonhole on this unnecessarily no it's good this is important okay good so but like why he might have written it this way oh that's not important yeah i knew that you would think that so so why he might have written it this way. So let's start with that first sentence, right? I am concerned with... Sorry, what am I...

Oh my gosh. Do you want me to do it? What I am concerned with is the activity of matching some significant part and aspect of the real world to the symbol manipulation. Okay? Yeah, so that's a succinct version of it. Yeah, you skipped some. Yeah, yeah, yeah. Yeah, but this is one of the reasons I brought in

Ryle. Oh yeah, I forgot to mention. On this episode we're also reading a brief excerpt from The Concept of Mind by Gilbert Ryle. Okay, so what was Ryle trying to do? Well, in The Concept of Mind...

He's trying to rile me up we'll get there but in the concept of mind he was trying to get rid of this dualism this idea that the the mind is somehow separate from the body somehow separate from the brain and he thinks that we often use spooky language when talking about the way people think about stuff instead of just what they actually do in the real world. He had this behaviorist project where he was trying to map all this mental talk to behaviors we actually do.

You can see that same structure in this little sentence. What Naur wants to do is map all the symbol manipulation going on, all the things going on in the computer to real world activities. He actually gives us a behavioralist take on what programming is.

What are we actually doing in the real world that corresponds to programming? I'm going to jump back just a second, because maybe at this point people are wondering why even care about this. Now it actually does answer that. I actually think it's really important because I think it mimics a lot of how I've felt. I legitimately do feel like this paper gave me a better outlook on programming, on my life programming, because it helped me understand certain things. And this is how he puts it. is inappropriate, we will misunderstand the difficulties that arise in the activity, and our attempts to overcome them will give rise to conflicts and frustrations. Like, why do we want to know what programming is? Because if we don't, then not that we will

misunderstand, but because we're going to misunderstand anyways, but we will actually misunderstand the difficulties that arise, and then our attempts to overcome them will be wrong because we're based on an incorrect theory of what we're doing. So an example that I want to say of this is, so many times when we find that our software isn't working the way we wanted it to, we find that we're producing too many bugs or that, you know, whatever. We try to go to rules that we can apply,

and if we just follow all these rules, we'll solve the problem of programming. If you have a sufficiently advanced Linter type system, programming will just be easy and you won't have to worry about it. And Naur wants to say that that's the mistake that we're making. And what he's offering is maybe not the conception of what programming is that's going to work for everyone, but he's offering a really good conception of what programming is that helps explain why having a misunderstanding

of what programming is can be so harmful in the first place. Exactly. He wants this to be an exploration of what programming is, but it's not a definition. This is programming as theory building. It's a way, a lens in which we can look at programming. Yes. The first section, I could probably summarize it pretty quickly yeah let's

let's have you do that i say that and i realize my summary is going to be like very dismissive like he talks about how there's this computer program and some people tried to modify it and they did a bad job and so therefore theory building is important that's but that's there's a bet it's a true but unhelpful summary so yeah you do that jimmy he has two two-ish parts of this like compiler story that he's telling yeah all right i'll read the beginning just so we can get the kind of like unnecessarily a little uh you know symbolic language we got here case one concerns a compiler has been developed by a group a for language l and worked very well on computer x now another group b has the task to write a compiler for language l plus m a modest extension of l for computer y okay so this is the kind of thing that

we got it's easier when you're reading it i. Yeah, that's why the summary is kind of... So what happened is you have some group, they developed a compiler, and a different group needs to go modify it and port it to another computer. And initially, they work together. They actually have group A and group B are working together, and group B proposes some changes, and group A is like, hey, no, that's not a good idea, and shows them a much better way of doing things. And so 10 years later, there's some other group that is doing all these modifications

and they have not had this direct contact with group A. And a member of group A goes and sees the work that they did and they have destroyed the beautiful compiler structure because they just didn't realize the power that was underneath all of the underlying code. And had they just talked to group A, they could have saved themselves from doing that. This is why I say this is, I think, very poorly argued. Well, yeah. But to tie it in, the explanation is that group A has this theory in mind of how the compiler is supposed to be structured internally, how it's written and how it functions.

And that structure that they have in mind will help that group A understand what changes to make if changes are needed. And Group B, and the descendants of Group B, as Group B changes over time, never really learned that theory of how the compiler works. And so as they are making changes, the changes they're making are misinformed because they don't understand the, you know, the real capability of the structure that's in there. They just only have the source code and kind of a partial understanding of how it is, but they don't have the why it is. That leads them to make changes that compromise the structure more and more and more as time progresses. I think while the example's a little convoluted, and a decade goes by and the program's not as good or something, it does feel a little awkward.

But I think we've all, if you've worked in any place with legacy code, experienced this, right? Like, you go into this legacy code, and it is very hard to know how you ought to make changes to it. And yet, if there's still any of those legacy developers around, they seem to not have as hard of a time, right? Like, it's not that they're a better programmer than you. It's not that they, even that they know the program text that better than you, like you might work on it for a very long time and still find it very hard to make these changes. And it's because they held these certain sets of values and these certain ideas about where the program ought to go. And those don't line up with the way that you're thinking about it. And you don't have that sort of notion about this program.

Nauer feels he's already argued for this position and now wants to explore it more. So he says, if it is granted that programming must involve as the essential part of building up of the programmer's knowledge, the next issue is to characterize that knowledge more closely. And so he says that, you know, it should be regarded as a theory in the sense of Ryle.

And this is where this whole text to me, this is why I brought in Ryle, because I think this whole text becomes really confusing if you don't know what Ryle meant by theory. Because like when I hear theory, I think of of you know like newton's theory of gravity like what i'm working up to is something i can state succinctly as like here is how something works yeah and if you're not like being such a nerd as to put

everybody around you to sleep maybe you're thinking theory in the more colloquial sense of you know um i have this idea about what something is it's not like a you know theory of relativity kind of theory right newton's theory of relativity it's not one of those kind of things uh boar's theory of relativity curry's theory of relativity it's it's a like i've just got this kind of working knowledge that i've built up, this kind of internal understanding of the way that things are. Yeah, or maybe this hypothesis, this like, I'm going to go test it. Those are the kinds of things we think of theory. But Ryle here gives us a notion of theory

that is ultimately inexpressible. That to have a theory is not to say anything or to believe anything but to be able to do certain things not that the idea of what a theory is is inexpressible but a theory is a thing that is inexpressible yeah so this is where this all gets all right i think you missed a word in the sentence there that's why i was confused i that that's okay so maybe we should dive into ryle yeah i'm gonna start by reading a quote here from ryle that i think clarifies the whole thing and then you know we'll just mic drop in the podcast there and we won't have to worry about it a quote here from Ryle that I think clarifies the whole thing. And then we'll just mic drop in the podcast there and we won't have to worry about it.

All right, cool. So, to have a theory or a plan is not itself to be doing or saying anything. Any more than to have a pen is to be writing with it. To have a pen is to be in the position to write with it, if occasion arises to do so. So what exactly does he mean by theory? Well, he doesn't want, so Ryle doesn't want to say you have certain things in your head. You have these mental concepts going on. He wants to explain all mental concepts in terms of actions you can perform because he doesn't believe that

there is any mental stuff going on in your head. He thinks all talk of thoughts in your head is actually silly talk. And what's really going on is you're able to do certain actions. And so he's going to recast all ideas about theory, about knowledge, into action. And the ability to perform certain actions if you need to. As an example of this, I have this passage highlighted that I liked saying, here are some of the actions that demonstrate that you have a theory. So Newton's theories were used when correct predictions and retrodictions were made on the basis of them, when machines were designed in accordance with

them, when the hope of building perpetual motion machines was given up, when some other theories were abandoned or else were codified with his, when books were produced and lectures delivered enabling students to grasp the whole or parts of his theories, and lastly, when some or all of his theory-building techniques were learned from his examples and successfully applied in new investigations. To be a Newtonian was not just to say what Newton had said, but also to say and do what Newton would have said and done. Yeah. So what we have is this much richer notion of theory that isn't some propositional content we wrote down, but is actually, if you have the theory, you're able to do certain things.

It's a building up of a know-how. So having a theory is being able to make certain moves. It's being able to do certain actions. And building up a theory is preparing yourself. It's like riding a bike, right? Learning to ride a bike is trying to get to the point where you can ride the bike. And knowing how to ride a bike doesn't mean you're always riding a bike. It means you're able to do it when you need to.

And so this theory is much richer than the notion of riding a bike. It's about being able to do all sorts of different moves and being able to express lots of different things, but also to act in the world. And I also like that he takes this and sort of broadens the scope of it a little bit. Like it's not just, just you know that riding or learning to ride a bike prepares you to be able to ride a bike in the future but he he also talks about how it prepares you to deal with other similar circumstances and how having a theory in one area prepares you to do theory building in another area so example, at least one thing that is learned in listening

attentively to didactic talking is how to say just those same things or things to the same effect, or at least how to talk in that manner. A lesson in anything is also a lesson in giving and receiving lessons of that sort. I like that very much. Yeah, I think Ryle this, you know, I picked these six pages and I, you know, I think they kind of stand alone. You like that very much. Yeah, I think Ryle, this, you know, I picked these six pages, and I, you know, I think they kind of stand alone. You don't have to read the rest of the book to really get what he's getting at, because he really does try to just, like, give us these rich examples and illustrations over and over again to get his point across. Before we get back into it, I just wanted to say, I hope we stick with the ryle long enough to

get to the part the part yes which part okay well we'll get there if we get there i hope you're not planning to just kind of summarize ryle and bail on it i hope we get to do at least a little bit more because i mean we ended on page 266 right we we end this section on page 266 but as far as i'm concerned we're still on like page 262 ish no no yeah i'm saying like you're saying the part is between here and 266 yes yeah see i just don't see it all right cool it's all just like like these are bops all right that's not making it in. I can't tell if you're trolling me or not. Of course I am.

Okay, good. Well, no. No, I think it's all good parts, but I was trolling you about using the word bop. Oh, what? I don't see how you think any of this has been uh i can't tell if you're trolling me or not i cannot tell if you're trolling maybe i just missed it i'll be honest and say that i didn't read it i've read it before so i didn't read it maybe as closely and i maybe skipped over parts that were bad and i just ignored them all right cool we're almost there so

don't worry about it we'll get there okay. Okay, okay, okay. So my favorite example from this that I think just clarifies things is Sherlock Holmes. In Ryle, he talks about, you know, all these different theories. And we kind of, at least for me, I usually think of like Newton or Marx. But having Sherlock Holmes example really does give us this difference in what theories can be for. It's not that Sherlock Holmes comes up with a theory that he can go state, and that's the point of it. And yes, maybe he does that at the end of the book, but if he just had these theories and didn't do anything with them, they would be pointless. And the point of Sherlock's theories is to find the crims and

lock them up, right? That's the goal also though that like Sherlock does different things to build his theory so I'll just read this Sherlock Holmes theories were not built by the same methods as those of Marx nor were the uses or applications of them similar to those of Marx but both were alike in delivering their theories in didactic prose which kind of weird. I don't know that Sherlock Holmes really delivered his theories in didactic prose. He does, when he explains it. He's like, here's how I deduced the solution to this crime.

Yeah, and so what I think is really interesting about this is if we think of programming as theory building, we have to ask ourselves, in what way do we express those theories? And I think that Naur's point is that there's all sorts of different ways. The program itself is one, the documentation is another, but it doesn't exhaust all of it. A lot of where this programming activity really comes out is as we go and make modifications over time, as we have discussions with product people or

another engineer or whoever on what's possible, what changes will be easy, what changes will be hard, when should we rewrite this application. It's all of these activities that are so crucial to programming that this idea that programming just is writing down the program and the documentation, ignore. So this is curious to me because, and I'm going to quote, I think my favorite blonde redhead album, Inexp said that theories are inexpressible. And yet here you are talking about the different ways that theories can be expressed. There's some disconnect there that I don't understand. And I'm curious if you can talk me through that a little bit.

Yeah. So this is why what I think is often confusing. I agree with you. But one way of putting it that I don't think is necessarily adequate, but maybe will help, is that the whole of the theory is inexpressible. That I could sit and write forever all of the things that I think I know, and first off, it wouldn't exhaust the theory, right? There would still be more left to say. But also, that that wouldn't make you gain the theory. So for example, if I knew how to juggle, which I don't, I could write down all the facts about juggling,

and that doesn't now make you able to juggle if you read all those facts. Yeah, that's a good point. Right? Like you can't just now go juggle. And so the point of it being in a... But I might be able to write about juggling. Yes, you might be able to recite all the facts about juggling. You might be able to tell me, you might be able to trick someone into thinking you know how to juggle if all they can do is hear you talk about juggling. Yes.

I have a theory of how to talk about juggling, but I don't have a theory of juggling. Exactly. And so this is the distinction that there's actually this know-how that you only have it if you're able to do certain things. And the theory is that know-how. That it's something we possess. We possess this know-how. And so having a simulation of that know-how where you can go talk as if you have the theory isn't to have the theory itself. So to make the, stretch the analogy, the Turing test where this thing can convince you

that it's a person is not the same as being a person. Yeah, absolutely. Yeah. And so that's the idea that we have here is that there's, and the only way to gain this theory is not merely to listen, not merely to read documentation, but to do these activities. And I think Naur would add the best way, if you want to gain the original theory of a program, you need to work with its original authors who have that theory. I think one great example that I've brought up a million times already of this kind of activity is The Witness. The Witness doesn't teach you how to play the game by language. It puts you into this world and gives you examples, and you learn, you kind of get this know-how of these puzzles, even if, for some of them, I couldn't have expressed the rules to you, I knew the rules of the puzzle. And I think Naur wants to say the same thing about programming, that there's certain things that we know how to do do even if we couldn't give a didactic explanation. That's just one way we can express, we

can show our theory. So the next section of the Ryle paper gets into something that we're kind of touching on, we're talking around it loosely, and I think now we can actually dive in and get into the concrete parts of it. I was going to say get into the meat of it, but once again, I am trying to avoid animal metaphors. So my favorite metaphors are animal metaphors and functional programming. So I'm going to read a whole paragraph, and then I'm going to ask you a question about it, and I hope you can help me make some sense of this. Sounds great. To come now to the work of building theories.

First, I'm not restricting this phrase to those operations which, like mathematics, jurisprudence, philology, and philosophy, can be done in an armchair or at a desk. Columbus could not have given his account of the west side of the Atlantic without voyaging thither, nor could Kepler have given his account of the solar system unless he and Tycho Brahe had spent many weary hours visually studying the heavens. Nonetheless, we distinguish the theories which they finally built and then taught to the educated world by word of mouth or in print, from the exertions and observations without which they would not have built those theories. The formulations of their theories embody reports of, or references to, the courses set and observations made, but they do not embody the courses set or the observations made themselves. The results of research can be delivered in prose, but researching

does not generally consist only in operating with pens, but also in operating with microscopes and telescopes, balances and galvanometers, log lines, and litmus papers. So, I get what this is saying, right? It's like the theory building process, it involves doing a lot of that work, right? Like getting to the theory of how to ride a bike that you hold in your mind that enables you to do the act of riding the bike requires practicing riding a bike, right? But there's something about this that feels to me a little bit at odds with the preceding part. And it's this sort of singularization of what a theory is. So for example, we're talking about the theory of riding a bike, right? It's the thing that enables you to do the act of riding a bike. But all of these examples of talking about theories,

right? Like Newton's theories, right? Theory of gravity, Newton's theory of relativity, right? Newton's theory of radiation. All of these theories are kind of singularized. And what I'm curious is, why not just say that Kepler and Columbus were constantly forming theories from the very beginning, right? This paragraph says that Columbus could not have given his account of the west side of the Atlantic without voyaging thither nonetheless we distinguish the theories which they finally built and then taught right like the theory they finally built feels like it's this thing that you have to do all this work to arrive at and I almost feel like like why not treat a theory as like this soup of the mind

that is ever brewing and the expression of which is just like taking a a drop of that soup why try and treat the theory as the singular thing right like Like the theory of riding the bike, every time I ride the bike, it's a kind of a different approach that I have to it, right? Like I might ride the bike very conservatively if I'm on pavement or much more playfully if I'm on grass, or if I'm in a skate park, I might ride the bike in a way that involves catching a lot of sick air. Those are all different sort of permutations of the riding a bike theory. And so why treat it as a singular thing rather than treat it as more of a continuous kind of amorphous, like maybe a little bit of riding the bike in the skate park is also benefited by the theory of riding a skateboard in the skate park and those two shouldn't be treated as separate theories they're kind of just like two slices of a continuous space why why why the singularization yeah i'll be honest and say i

don't have a great reason i do think he ryle tries to give us a reason, but it does seem very particular to his project. And it seems that the point of this somehow is to combat some other, he's subtweeting somebody here, right? He's like trying to, he doesn't want to mention them, but there's somebody else who disagrees with him. And he really wants to put the point home that you can't collapse these things. And I'll be honest, I agree with you that I don't quite see why. And I actually think your interpretation fits up much better with what Naur wants, because he doesn't say, when do we have the theory? He says, programming is theory building. And with programming, I don't know that we ever arrive at the final theory. I don't know

that there's an end point. I don't know that there is ever a moment where it's like, and now I have that theory, and I don't need to do all of the work of building anything. And so yeah, I do think that if you read Ryle, I see the distinction he's making even if we don't think that there's an exact end point. Maybe it's asymptotic, right? Like over time the building work becomes less and less and the having becomes more and more and i do think that that kind of that sort of asymptotically approaching

having and as opposed to building makes a lot of sense to me and i think that actually works kind of for his example uh here of the farmer that That is kind of a metaphor that he's trying to use. So he talks about functional programming as a farmer. All right, so I'll read it. If a farmer has made a path, he is able to saunter easily up and down it. That is what the path is made for. But the work of making the path

was not the process of sauntering easily, but of marking the path was not the process of sauntering easily, but of marking the ground, digging, fetching loads of gravel, rolling, and draining. And the reason I want to give this example is, you know, he ultimately says just like having a theory is to be able to saunter, building the theory is not. But it's not as if the farmer builds his path once and doesn't have to maintain it. It's just that the work of maintaining the path is way less than the work of creating it to begin with. And so I think the same, I think Ryle would say is true of theories. The work of creating the theory is this, you know, this big

undertaking. And then once we have the theory, we might come back and tweak it and modify it and maintain it. And in that we're still doing those we might come back and tweak it and modify it and maintain it. And in that, we're still doing those same activities of getting the gravel and rolling and draining, etc. But it's definitely nowhere near as involved as the initial creation was. So I've got an issue with this still. I've got this sort of sense of unease about this conception of a theory as, like it does in all of the examples given, it is given a kind of a discreteness or a singularization that I'm uncomfortable with.

And to illustrate that even further, I'm gonna grab an example that comes after the example of Kepler and Tycho Brahe and Columbus, but before the example of the farmer, Jimmy. Here we go. Next, in talking of building theories, I'm not referring only to the classical examples of famous discoveries, but to a class of tasks in which all the people who have had any education

participate in some degree on some occasions. The housewife trying to find out whether a carpet will fit a floor is engaged in an unambitious task of theorizing. She is investigating something and the results of her investigations will be statable. Both what she reports to her husband and what she does with the carpet will show what theory she has reached since her mornings work with tape measure pencil and paper was preparing her both to lay the carpet this way round and not that and to tell her husband that the carpet will go there that way round since the shape and size of the floor and of the carpet are so and so. Holy f***.

We will never escape from sexism in these writings, will we? Okay. So this is actually, aside from this being absolutely awful, great because it sets up an example of, or it's like this kind of characterizes what I don't like about the singularization of the theory, right? So she's, she's skipping over the unambitious part of the unambitious task of theorizing, which Naur quotes, Naur quotes the unambitiousness, but we'll get, we'll get back to that. She's investigating something and the results of her investigations will be statable. That kind of implies that you go through this effort to build we'll get back to that she's investigating something and the results of her investigations

will be statable that kind of implies that you go through this effort to build the theory and in so doing develop a theory that you can then state stating a theory not being the same as other kinds of action that require the theory but i don't think that that that's quite it i don't think that um this this housewife is you know doing the work with pencil and tape measure and whatever to arrive at this theory i think like she's gradually refining her sense of whether this carpet will fit but it's not like it starts when she sets about her day. So here, I'll say this. in an undesired shape carpets that are the wrong color carpets are too high or low a pile carpets made of human hair carpets that have mold carpets that are stolen carpets that are actually conveyor

belts carpets that are poisonous living carpets carpets that are used to wrap a body and throw it into the river but not really just for a tv show that nobody has to die for for this digression and shag carpets because i grew up in a room with shag shag. These are all things that she brings to this activity already. And there's this like when you learn to ride a bike, you are bringing to it the existing theory you have about how your body works. And that's a weird thing to say. You have a theory about how your body works. I don't say you have a theory about how your body works I don't think you have a theory about how your body works. I don't think you have a theory about how to ride a bike I don't think you have a theory about what carpet should go there I it like it feels wrong to me to try and say that a theory is a thing that you can

Point to in any way because any one of these theories the more you pull on it the more you're going to realize well it's supported by this other knowledge it's supported by knowledge that comes from similar past experiences or wildly unrelated past experiences or knowledge that is related to some other domain entirely, or just any different kind of knowledge. All of the knowledge together is what I think enables you to do the things that you do. And so I get the, and I appreciate and enjoy the part of this that is talking about the relationship between the actions that you're able to take, the things you're able to do. You're able to ride a bike.

You're able to swim. But what I don't like is trying to sort of map that back in a one-to-one way to something that is in your head. That feels sort of like a misapplication of formalism to me. Well, okay. I think I can put this together in a way you might enjoy. Okay. Okay. So Ryle, first off, agrees with what you just said

because he doesn't think there is anything in your head. That's the point of this whole book. There's nothing in your head. Talk of, mental talk of thoughts and these sorts of things, it's the ghost in the machine is the phrase that's used. We are machines. We are physical beings. And he wants to say, we don't have any of these mental attributions people want to give to us. What we have is actions in the world. So I've now, I've been skimming this trying to answer your question of like, why does he distinguish between the building of the theory

and the having of the theory? And it's because he says later on, on 265 here is kind of where he gets into it. He said, he thinks that people have misunderstood how we actually reason through things, how we actually come to have ideas. And he says here that these epistemologists, the people he's subtweeting, the people he doesn't like, think that we think in terms of drawing conclusions using words like if and so and because that reflect the act of reasoning or inferring or drawing conclusion from premises and this is how we build theories as we sit in our heads reasoning and drawing conclusions and he wants to say that's not what we do we don't sit and reason and draw a conclusion and and make all these

premises and he goes on to the next section to really talk about that he that's not what we do. We don't sit and reason and draw a conclusion and make all these premises. And he goes on to the next section to really talk about that. He wants to say instead, those are things that are part of the didactic explanation of a theory, not how we actually come to have one. So that's why he wants to make this distinction, because he thinks if we don't, we mistake the way we present our ideas as if that's how our brains really work. And our brains don't work that way. makes sense i mean um i hope you leave that whole pause in i can't because the strip silence is a thing. Podcast players do. Gotcha. I don't turn that on. I think this is the point. I think you're actually agreeing with Ryle's project here.

Maybe not his way of putting it, but at least I think he would agree with what you're trying to get at. That we don't have these theories in our head. They aren't these single unified things the reason he wants to separate these two is because he thinks people get confused and think that we uh spend all day here you go this is not in the text we agreed to to read uh so he talks about like people who talk as if for example john doe could and should sometimes be described as having woken up and started to do judging conceiving subsuming or abstracting as spending more than three seconds in entertaining a proposition or moving from some

premises to a conclusion or is sitting on a fence alternatively whistling and deducing or as having had an intuition of something a moment before he coughed like his point is we don't sit and reason our way through all of these things we present things as reasons after the fact so is this the part of Ryle you didn't like? Was the theory has a definitive end? No. Oh, we still haven't got the part you didn't like. Okay.

No, no, no, no, no. The part that I didn't like was the housewife trying to find out whether a carpet will fit a floor is engaged in a task of unambitious theorizing uh-huh yeah sorry yes the the sucker i i did overlook the terrible sexism and i shouldn't uh but i kind of rolled my eyes and moved on yes that no and i i only dig into it not to to um to virtue signal as i want to do but because it was a good example of sort of my discomfort with this idea of theories being a singular thing in the mind. But your exploration of the idea that there is no in the mind, there is only the actions that one takes that we can sort of assess and reflect on and respond to. I think that helps. It helps to, even though there's a lot of talk of

theory and my plebeian understanding of what theory means is a very kind of mental sort of thing. It helps for me to say, yeah, just ignore what the mind is and only pay attention to the actions in the world. I think that helps. Yeah, so I think we've gotten this idea of theory from Ryle. Yeah. And even if we don't agree with it in its whole thing, and I personally don't, in all honesty,

I think it's actually really important for understanding what Naur is now trying to say. Mm-hmm. Right, because he wants to go on what exactly is this theory? In terms of Ryle's notion of theory, what has to be built by the programmer is a theory of how certain affairs of the world will be handled by the programmers has primacy over such other products as program text, user documentation, and additional documentation such as specifications. So that's the goal.

That the valuable thing is the theory that is built up by the programmers doing the programming, not the resulting program or any secondary documentation. And thus, if you have a compiler written by team A, and then team B comes in and learns a little bit about that compiler from team A, team B gets a little bit of that theory built up within them. But as time goes on, and 10 years later, team B isn't really staffed by anybody who understands the compiler anymore, they might have the source code, they might have the documentation,

but they don't have the theory. And this, Naur thinks, is crucial. And as we continue in his paper, he gives more and more examples of why it's crucial. And I think it fits very well with the way I've seen work actually happen. The code is almost never the interesting thing. It's the ways in which people know how to make it respond to all these changes. And when people stop knowing how to make it respond to these changes,

we get all sorts of breakdowns in our ways of programming. So the next section that I think gets interesting is when it starts talking about the way in which the knowledge, you know, possessed by programmers transcends documented products like the source code and documentation and that kind of thing. And he outlines three specific ways in which that happens. And I think these three specific examples are pretty good. The first one is that the programmer who has a theory can explain how the solution that the program embodies relates to the affairs of the world that it helps handle. So you've got some program. It exists because there's some real world problem you're trying to solve. And a programmer who has a theory about that program

can explain the relationship there you know if the uh the the problem in the world is mapped into the program text and in particular each part of the program text should relate to some part of the real world problem and the programmer with the theory can explain that mapping and vice versa each part of the real world problem so i'll quote the decision that a part of the world is relevant can only be made by somebody who understands the whole world um you know has a whole theory of the problem and that understanding must be contributed by the programmer so that one-to-one mapping between the source text and the real-world problem, that's one example of the theory or the way of manifesting that theory

is by doing that explanation. And if you don't have the theory, you can't do that explanation. Yeah, and I think this really accords well with my experience of things where you dive into some problem and you're trying to debug it and you have no idea

what is relevant or not, and then you go talk to somebody who's more familiar with it, and they can just immediately rule out whole classes of things you were investigating and just be like, oh yeah, this doesn't deal with that, the stuff that deals with this part of the problem is over here, and they can help you narrow down to that exact part of the code, or part of the real world that this code is related to. And that is not, there's nothing in the text that tells you

that. And even if you write documentation down and you try to explain that, there will always be that gap. Yeah. And I think the second example explains why that gap exists and it's that the programmer who has the theory can explain why each part of the program is what it is and they can do that by comparing it with alternatives like here's what we could have done instead and here's why we didn't or they can explain the principles and rules that informed the the choice of text for this program and those sorts of those sorts of considerations of like not just here's what the program does and why it does it but here's why this program and not that program require somebody to have a theory of the program. And if you don't have that theory of the program,

you won't be able to say, here's why it is this way and not that way. Yeah, and I think this is one of the reasons that if you come from an object-oriented programming background and you dive into a code base of some functional programmer, it doesn't make sense. Because there's these background assumptions of values and theories and why you would want to organize code in a certain way. And the third of three examples, just to kind of round out the trilogy, the programmer who has the theory is able to respond constructively

to any demand for modification of the program to support the affairs of the world in a new manner. So if you have a theory of a program, you are able to modify that program to adapt it to some new world situation and having that theory helps because designing that modification depends on your understanding of the similarity between the new thing that you need to enable the program to do and what's already there and so it's it's not just that you know you're looking at the source code and saying oh hey we need to handle this you know, this new contingency case or something like that. Let's just add a big, you know, if statement at this giant top level control structure or whatever, because that's a sort of a syntactic similarity if you understand the conceptual space of the program, you have a strong sense of

exactly where a change should belong within that program in a way that I think is a bit deeper, or at least that's what Naur is suggesting. Yeah, I think this is just a very important point that like, we, I think especially today, software modification is the name of the game. As a service, our software is constantly changing. And yet, if we think that what we're doing is primarily about the program, we leave off all modification. And we can't even include it in it. What would it be for, other than AI, quote unquote, what would it be for a program to know how it should respond to changes in the world? There is no way for it to. And yet, I think we all realize that's incredibly important

as part of what programming is. If we could write a program and yet it couldn't change, we would say we're missing something. Cough, cough, blockchain, smart contracts. There's a couple of leaps in what you've just said that I don't quite follow. That's fine. Go ahead. What does it mean for a program to know that it needs to change in response to the world i mean depending on what level you look at it right

like do you mean change the source text because that's you know you had like rule systems and that sort of thing like oh hey any uh anybody with domain knowledge should be able to reprogram the the program to adapt to changes in the business environment or whatever. That was a failed attempt around the time of this paper. But then there's also the other interpretation, which is like, well, a video game responds to changes in the world around it, right? Your inputs to it, sort of manipulating the state space of the game. I think you mean more the former than the latter. I mean,

there's the set of all possible states that a program could be in, given its source code as it is now, and we need to expand that set to have new states, or restrict that set to get rid of some states, which is fixing a bug, for example. It's changing those. It's changing the way in which the inputs and outputs it's going to accept, the way in which it's going to run, any of those sorts of things.

It's not responding to change that it already can make sense of. That's already a possible computational path. It's changing what those possible paths even are. And it helps to sort of, Naur does a good job of this. Like he, he doesn't get all galaxy brained about it. He stays pretty clear talking about program modification in terms of the source text versus like the execution of the program. Like he keeps

those nicely distinct and i think that's where i'm struggling a little bit with this example you you are um talking about jimmy is like um which you cleared up by saying the the set of all possible states right so when we're talking about modifying the set of all possible states those states are the execution and the thing that establishes the set of all possible states. Those states are the execution and the thing that establishes the set of all possible states is the source text, at least within this example. There's some galaxy brained interpretations where it's like, oh, but what if it's a program that generates a program that generates a program and you want to jump into the middle level or something like that? Are you changing the program? Are you changing the way that it interacts? It's just like,

no, screw off. Let's just have two levels. Let's have source text and the execution. Wow, you heard it here. Ivan thinks that programming is quintessentially tied to text. Yep. If I know anything about Ivan, that's what I know.

He hates all non-text-based programming languages. I hate Galaxy Brain to takes about what programming should be. So I think what I do like is as we continue in this, I think Naur gets more and more practical. I do kind of agree with that. He keeps it, not Galaxy Brain. And he really is trying to argue for this

for, I think, very practical reasons. And this next section is about that, is the problems and costs of program modification. Yeah, so we're getting into justifying why adopt a theory-building view. Here are some real-world cases where adopting the theory-building view will make a some real-world cases where adopting the theory-building view will make a line go up on your business. Maybe. I don't know if he thinks that it

will actually help you, but it will make you not go down the wrong paths. Sure. Right. So if you think that programming is just producing the text of a program, it seems like it should be low cost to make these changes. Because unlike demolishing a building where you have to have all this equipment, et cetera, all you need to do is have the text and type on a keyboard. And what could be hard about that? But on the theory building view, none of that follows. Because what you actually care about with that modification is the theory. Is how you can respond to these changes in the world

and make the modifications fit in with that theory. The example I like that I think kind of illustrates this sort of thing is, and maybe it only works for me, I don't know, but it's like Supreme Court decisions. It seems like it should just be easy. Like you can just declare something to be true, but that's not how Supreme Court decisions ever work. They're looking at precedent. They're looking at common law. They're trying to look at all this existing body of work and fit something in there. And sometimes they kind of change it a little bit. Sometimes they kind of move

things around. But that's the kind of work we do in programming. We can't just like willy nilly go and make changes. It has to fit with everything that came before it. And there's a, I guess you're right to say that it's not just about hey if you adopt the theory building view it's going to help the line go up it's almost like if you adopt the theory building view it might make it more expensive in the short term for reasons that we'll get into but you are avoiding long-term pain that comes about as the result of your program rotting because you had the wrong theory about modifying it and instead of cherishing the programmers who have the theory you're instead cherishing the program text which will gradually disintegrate as people who don't have

the right theory of how it works make changes to it and one example or a couple of examples that I thought of that sort of stem from this are like outsourcing or contracting is something that's often done as a cost saving measure. And that is something that kind of depends on the idea that programmers are sort of interchangeable, that the skill is producing the text and so if you can find somebody to produce the text less at less cost you should just go and do that um as opposed to the programmer and their intimate relationship with the real world problem to be solved is the thing that you need to cherish it's um i've always felt sort of uncomfortable with the idea of outsourcing and i think this in some way it might explain that discomfort for me yeah and the other thing that this made me realize was like this might be how a small startup can out compete an enterprise with thousands of programmers because an enterprise with thousands of programmers has to maintain the theory of their software across many different people's minds

however you know philosophically you want to interpret that right but there's so many people that have to sustain the theory whereas a small team with just a few people the theory can be concentrated into individuals more directly and so there's going to be less loss as those people have to kind of communicate bits of the theory to one another. Like theory transmission is lossy, and so the less of it you have to do, the better off you are.

Yeah, and just think about how many theories in their source code have been lost. Yeah. Somebody works on this part and stays there for a year and leaves. They never build up the theory. In fact, I think it's very wonderful. It's called the Generationship Model of Software Building or something like that. It's a short story that someone wrote that I definitely think is worth reading. The the idea kind of is, we come in

and we never end up getting that theory. And I've been at companies like this where I've worked on software that I felt like right as I wanted to leave the company, I had just finally grasped what this software did. And now I could be so much more productive than I ever was, but for various reasons, that it wasn't a place I wanted to stay.

And now I know that the next programmer is going to be in the same predicament I was in. Joining in, no one's there to teach them the ropes, and they're going to spend a year or two finally getting to the point where they build up this theory and then leave. It gets into this even more later in the paper, talking about the way that as teams change, as there's turnover in the team over time, that leads to a kind of a rot of the program text.

And I feel like that's what we're seeing right now with Windows and macOS, which each had their heydays, right? Like Windows, I would argue, had a heyday around the advent of XP and Windows 2000. And macOS had a heyday kind of, at least in the macOS 10 era, sort of around the time of Leopard, Snow Leopard. And what I know from my looking into how those companies ran and what those software teams looked like at the time was they were led by people who would have had a really strong theory about much of the os and those people are gone now and so we're seeing and i know this very

intimately with mac os like we're seeing a lot of attempts to fix long-standing issues that fail and end up having to be rolled back or because they were tied to marketing objectives end up being glommed on and are just this new sort of appendage hanging off the side of the os that doesn't really help it is just extra baggage now that slows things down even further and you look at a you look at an app like you know apple's music app on the mac used to be itunes right it feels sort of like that app has been passed around from person to person to person to person and it never works it's always broken but it breaks in a different way every year and it feels like the people who are trying to fix it are always new people who come

into this legacy code base and are forbidden to just throw it away and make it over again and they you know situate themselves in there and learn what they can and try to fix the things that they can, but then introduce more and more breakage. And it just is heartbreaking because, to me, I've always imagined that the solution to this is the sort of the, what's the name of that, like suckless or something like that? Like there's these people who have this movement of, you know, focusing on quality first in software. This gets back to worse is better, right? Like they're trying to do a the right thing approach to software where, you know, they very much care that the internal implementation is clean and simple and maintainable. And, you know, or I guess that's the worst is better right worse is better is the one that cares about the internal implementation being clean and simple right

the one that cares about clean internal implementations there's people out there doing that and i kind of had had hope that that would be a solution to the problem of like mac os rotting and so maybe it's like okay some team will come along and and pick up apple music and they will they will adopt that philosophy that like you know hey all the people who came before us were approaching it the wrong way they thought the implementation could be a mess and that's why it was always buggy let's just clean it up let's live here for a while and clean it up and this theory building view gives me a little bit of less hope about that because it suggests that once the people who have the theory are gone

really your best bet is to just throw it away and and start over again and rebuild the thing from scratch because you're not going to rebuild the theory it's and and we'll get into that a little bit later as to why you're not going to rebuild the theory but it just you know it kind of breaks my heart to think oh okay if the theory is the thing that must be cherished if the theory is the thing that you value once the theory's gone that program text is sort of, hope is lost for it. Yeah, I love the way he puts these ideas. There's a heading here of program life, death, and revival. Oh yeah, that's the next section. Uh-huh. And I just love this idea, just in general, metaphor of a functional programming the metaphor of program

life right like i just think that this is i i think that's beautiful i love that that certain programs are living and he gives us criteria for when they die um which also i don't know, that's kind of neat. So he gives us actual, like, when can we see if a program's dead? And he says this, the actual state of death becomes visible when demands for modification of the program cannot be intelligently answered.

Oh, have I been in that room so many times where somebody asks, how can we make this change? And nobody knows. Nobody can answer intelligently how we would even begin to go about it. And I just love that because it puts to words an experience I felt. And I felt so awful, honestly, that I couldn't give an answer intelligently to these questions of how to change this legacy program. And now maybe I have some sort of excuse, or at least I have a way of understanding

what happened there. I completely agree. And I have some notes that I've written here in the PDF that I've annotated in preview on macOS to share about this but unfortunately only one of those notes now opens when I click on it and the other

ones are somehow broken because software so I can't actually get at my notes that I wrote for this section so there we go yeah uh i i i'm sure i had some lovely thoughts about life death and revival but unfortunately software killed them so so your notes are now dead yeah um and i have no theory as to why. Well, no, I have a theory and it's computers. It's because

the program itself died a long time ago. But there's just a bunch of passages that I highlighted. I can read some of those because they're lovely. One of them is, the building of the program is the same as the building of the theory of it by and in the team of programmers.

We've been saying that all along, but that's a really nice, succinct way of saying it. Another one I highlighted. A dead program may continue to be used for execution in a computer and to produce useful results. It's like, you know, zombification, right? You can continue to run a dead program, but it's dead not because of any corruption

of the bits of the source text, but because the theory is lost. And I have next to that, stop writing dead programs. Gets a whole new meaning in this light. Revival of a program is the rebuilding of its theory by a new programmer team. And then for a new programmer to come to possess an existing theory of a program it's insufficient that he or she has the opportunity to become familiar with the program text and other documentation what's required is that the new programmer has the opportunity to work in close

contact with the programmers who already possess the theory and that is an interesting thought to me, that really the only way to transfer the theory of the program is from person to person contact. And you can't use documentation or the source text as the means of transmission of the theory. I'm assuming it's because the theory is the thing that enables you to do the act of creating the program. And so if you want to learn the theory, you have to be with other people who are performing that act. You can't just take the result of that act and learn the theory from it. And I thought of an exception to this, just one example, and I'm curious if you can analyze this and tell me, with the tools that we're playing with for this discussion, how am I to understand this example? And so the example is, there's the video game Super Mario 64, came out on the Nintendo 64 in the mid-90s, and it was the first 3d mario game was a breakthrough in platforming but it ran at a pretty low frame rate and something like let's say you know 15 or 20

frames per second right and recently somebody took the i think the compiled assembly of that game i don't think they had access to the actual source text. I don't know for sure, but even if they did, they didn't have any contact with the actual people who initially implemented it. But he re-implemented parts of it and fixed bugs in their implementation and over the course of, I think i think a couple years of working on it got the game to run at 60 frames per second on the original hardware without breaking any of the special characteristics let's say of the physics of that game which are kind of quirky and that to me feels like something where this this person who made these modifications

would have needed to have possessed some of the theory of the original game in order to so deftly make these changes that the original development team could have made but didn't right like this person got the game to run at 60 frames per second on original hardware so at the time in the 90s the original team could have done that and so this person is demonstrating a a mastery over some theories that can produce an even better source text with an even better fit to the problem posed by the real world, ignoring factors maybe like deadlines and that sort of thing. But it makes me wonder, like, is it that the theory that this new programmer possessed is so informed by background knowledge

of game development from the culture of game developers broadly and the things we've learned about game physics since the 90s? Is it that, you know, they just spent enough time with the source text that they were able to sort of piece together what it does and, if not develop the full theory of it, develop a working theory? How do you kind of read this example? What do you think happened here in light of the theory building view? I think there's a few things going on.

I'm tempted just to read three paragraphs, but I'm not going to. Naur does address this sort of thing in that he tries to use maybe a little too strong of language in some parts, and then backs maybe a little too strong of language in some parts and then backs out of that strong use of language so he says like we can't revive programs but then he's

like lest this consequence may seem unreasonable uh so he tries to like now soften it a little bit so he's going to say first off yes, yes, they have some notion of the theory of the program, however little, right? So what was passed down through an oral tradition, through other programmers that they interact with, who interact with other programmers, etc., who learned from these original programmers, there's some chain there that brings them together, right? Even if indirectly. And so they have some small part of the theory, but also he wants to say that what theory, the revived theory is going to differ from the original one. And they might have come up with a theory and you totally can have a theory, but it's going to differ from the original one,

and therefore it might contain discrepancies with the actual program text. And in this case, for the better. Yeah, in this case, for the better. I do think that that's true. But what he ultimately wants to say, and I will read a little bit of this passage about like, what is it? Like, why? Why does he put such a negative point on program revival? It's because he's thinking in the business context, rather than someone's hobby project,

right? So he says, the point is that building a theory to fit and support an existing program tech is a difficult, frustrating, and time-consuming activity. The new programmer is likely to feel torn between the loyalty to the existing programming text with whatever obscurities and weaknesses it may contain, and the new theory that he or she has to build up, and which, for better or worse, most likely will differ from the original theory behind the program text. So what Naur's saying is that if you're trying to get work done, if you're trying to get a program that's working, if you're trying to make these modifications, it might not be a good idea to try to go get programmers to have to resurrect this theory and instead to let them make a new program. And he says that it will be at no higher and possibly lower cost to do that.

And so I think, you know, he wants to say, yeah, you can totally, with a lot of work and frustration and et cetera, go and, you know, resurrect and make a new theory. And you could even be really good at doing so, but it's going to differ. And it's probably not as easy as you think it's going to be. And if it, you know, if this person did all of this work and, you know, you mentioned years, I don't know if it was, but if it was years of work doing this, it sounds about right. Yeah. And, and definitely definitely the circumstances of the world in this case aren't just that the game runs on original hardware. It's also this person was doing it as a hobby and not doing it

to ship the game in time for the launch of the console. Exactly. I think we've gotten Naur's big point here, and it goes against some traditional wisdom that I think we've gotten Naur's big point here, and it kind of goes against some traditional wisdom that I think we have in industry, which is rewrites are always bad. And Naur wants to say, no, they might not be. That there's actually criteria for when a rewrite is bad. A rewrite is bad if there's anybody who still has the theory.

Yeah, or if you have enough of the theory to enable the three kinds of things earlier, explanations of why the text is the way it is, explanations of what the alternatives were, and explanations of, you know, or the ability to make modifications. If you can do that, then make that third one, make those modifications.

If you can't make those modifications, then consider a rewrite. Yeah, but he also kind of gives us some, I guess, management advice where he says similar problems to revival can happen if there's just this revolving door of different programmers coming in and out. What's up, startups? 18-month turnover. Right? And so we have this problem because he thinks it's mandatory for quality software, that it's deeply rooted in this theory,

and there just isn't a way with this constant churn to really deeply root yourself and have that theory. Because theories are so tricky to transmit. We don't have a good way to transmit a theory from one person to another you have to go through the theory building process of in the case of software living deeply in the real world problem space that leads one to build the theory that will produce this program text and so if you're coming into an existing program text, you have to live in that real-world problem space long enough that you can understand why the program text is the way it is.

And that is a slow process, especially if the problem space is something that is particularly foreign to you. And then he kind of, I think, I do think this last section is is not as there's not as much packed in here um that i want to pull out i actually have like highlights of parts of it that i think are bad we've gone from like you know um earlier sections where i'm like yeah no this is a bad paragraph to the middle that is like i have you know every second sentence i have something

highlighted that i like about it back to you know and i second sentence, I have something highlighted that I like about it. Back to, you know, and I'll read a quote. A theory held by a person has no inherent division into parts and no inherent ordering. Why not? It's not explained. Well, because it's a know-how. Can you divide your parts and ordering for riding your bicycle?

Sure. And you couldn't present it any other way? It's inherent in there that it has to be in that order? It's like looking at a painting. Paintings are not linear things. We can look at the painting and focus in on any part of it and start to explain the whole from that perspective. Give me one second.

I have visitors. Easter egg for Ivan editing later. Easter egg for Jimmy listening to the released episode. Did you tell the podcast any secrets while I was gone? Maybe. Nice. But yeah, so I think theories don't have any particular order because they're a know-how, and none of our know-how has any particular order

that we have to adhere to. I can explain to you a program starting from any place, just like I can explain to you a painting starting from any place. But you can't tell a story starting from any place without... Uh-huh. Like, there... That's why stories are this linear media in a way that programs and paintings aren't. Programs are linear media. No, definitely not. No? There's no...

Well, first off... Not insertion pointer. What's the name of the freaking thing? instruction pointer? Okay, well, a single threaded program, but that's not the program. The program is the text. It's the all the ideas around it, right? The program is the symbol manipulation that something something. But no programs aren't linear, right? If you if starting from main isn't actually a good way to explain a program,

almost ever, unless the program is trivial. In the same way, explaining a painting, what do you do? Start in the top left corner? No, you start from the subject, if it has a subject. And if it doesn't have a subject, you start from the fact that it doesn't have a subject. I don't think so. Often, if you read art criticism or art historical people explaining paintings,

they'll focus on a detail, they'll move out, they'll jump between levels of abstraction the same way we do when we explain programs. Whereas you don't do this for a story, but you might do it for, you know, fine literature like blues clues oh that's the sound of me dying a little bit you get my point right like that i i think this

actually is really this is really important that if like this is why the theory is not linear because it's a know-how and know-hows don't have an order okay but the division into parts right this is my point earlier about singularization versus some continuous mind soup here i am arguing the other side of that. That no inherent division into parts. Uh-huh. Okay, fine. It's a wholism, right? Like in order to understand this, you must understand that.

And you have to kind of have this whole working together. What I will say is that at the time that I read this, I didn't understand it. And now, thanks to us talking through it, I do. This is the service that we provide as a podcast is to is to help exactly people develop a theory of theories this is now the theory building podcast and well no this is now that we actually this is the part where we get into the thing where i think we can start tying it to what the hell does this have to do with the future of coding? As to the use of particular kinds of notation or formalization, again, this can only be a secondary issue since the primary item, the theory, is not and cannot be expressed, and so no question

of the form or its expression arises. And just to get it out of the way we've already talked about the fact that now we're kind of maybe states things too strongly sometimes and and then backs off and earlier i i questioned whether theories can be expressed or not and this is the like you know the the stricter kind of expression where it's like the full theory comes out and you can pick it up in another mind that's the thing that's not possible but you can produce things that are a result of having the theory like you know riding a bike is an expression of the theory of how to ride a bike so i think i get what he means here even if the literal wording of it is not the best um but this is something that i think this this paragraph that the the mention of um particular

kinds of notation or formalization like i i think this is a good hook to tie it into the future of coding space which is the question of like what about the effects of notation on the activity of theory building and i i feel like this is something where for instance the choice of programming language can make a big difference right if you are um joining a you know a team where the program is written in assembly it may be harder to develop a theory of what the program does than if the program were written in Ruby or something like that and this is especially true in the like Super Mario 64 case where it's like if you only have access to You know compiled assembly or some, you know compiled form where you're looking at, you know

move jump branch that kind of thing that's gonna be harder to rebuild a theory of what the program does than if you have access to the source text in a high level language. And so even though there's this claim, I think reasonable claim that it's impossible to build the theory just by exposure to the texts that result from the activity of programming. I think it's, maybe one could argue that there's at least some role that notation and choice of tools could play in this theory building view. I don't know. What do you think? Yeah, I think the kind of goal here that I think Ryle's trying to get rid of

is as if there's one true method. You mean Naur. Sorry, yeah, Naur. Yep. I messed up the name instead of you. Yay. Yay. I messed it up earlier?

No, Peter Gabriel is what I was trying to say. Oh, yeah. No, of course, yes. Yes, yes, yes. But anyways, yeah, so Naur is trying to get rid of there being, there can be no right method, like singular, this is the way we ought to do things, which I still think, it's not as popular of a view today,

but I think it definitely was at the time. And I think it still kind of comes up in waves as if we could just be so scientific and rigorous Then we could solve all the problems of programming and that's what now is really against I agree with you that Different methods different techniques different notation I think all of these things can play into our ability to build theories or not And I think some of them are generalizable and then some of them are personal. For me, there's things that help me build a theory

because they help me do those activities, embody those activities that really reinforce things for me, make things come together. And I think a lot of this is like, how does this program respond to these inputs? How does it change when I do these things? For me, that's really critical, which is why I like more like interactive programming. Because I find that I get a theory of a program much faster when I can see it responding, see it in real time, and I can mess with it and stop it at any point

and move things around. Now, maybe not everyone does that, but I would say it's probably pretty darn useful. As to assembly versus Ruby, I don't know. My world is so boggled in low-level things now. You're doing Ruby assembly. Yeah, exactly. Where the theories I have to build are about

how the low-level stuff works. It's become harder for me. I don't know. At one point, I would have just said, the whole point of programming is to become higher level, higher level, higher level forever. And I'm just of two

minds on that now, because there is something that understanding that lower level underlying thing does actually help me with the high level things. But you're working on a compiler. You're not working on a compiler you're not working on you know like a scheduling system for um you know broadcast television or something like that right so it

is important that you have that theory of lower level execution whereas somebody who's making like a bart widget or something like that may not need that lower level understanding because it's outside the domain that is relevant to the real world problem that they're creating a program to address. Yeah, and I do agree. There's lots of problems that I would not want to tackle using the tool set I currently use.

I would not want to have to think about the difference between ARM machine code and x86-64 machine code when parsing JSON. No, I don't want to do that. I can agree. That's why I guess I want to just say I think it has to be person specific but also domain specific. I think that, but I do

think these are important things that we have to pay attention to when we think about the kinds of programs we want people to be building and the kinds of theories we want to help people have. And the kinds of tools we want them to have to do that work.

Yes. So something that I want to do just for a minute is go back to that earlier section of the Naur paper where he outlines those three things that people who have a theory are able to do. The first one being explain how the program that they're going to write or that they have written relates to the real world problem. What's the mapping between the program and the problem? Then the second one is explaining why this program and not some other program. And then the third one is the ability to modify that program. I feel like that is an interesting framing to approach the evaluation of creating the original program or the act of bringing somebody new into the team to help them understand how the program works, or whether it's the program just standing as an artifact unto itself discovered by some person who's come into it as a legacy system and who you know has to rebuild a theory of it

how might visual programming or whatever help somebody map the nature of the program to the real world as opposed to assembly and i think there it's very easy to see because that's the whole argument in favor of high-level language a high-level language the point of it the point of an apl or whatever is that you can more succinctly express what the program does and so if you have to draw a mapping between an aspect of the program text or you know visual noodle spaghetti or whatever it happens to be and some part of the program text or, you know, visual noodle spaghetti or whatever it happens to be, and some part of the real world problem, well, the smaller the text is, the easier it is to, in theory, maybe see APL as a counter example, the easier it may be to relate what the program

is the parts of the program to the parts of the real world problem. Whereas if you have, you know uh assembly or something like that there's going to be a whole bunch of it that is attending to the needs of the machine and not attending to the needs of the problem this is essential versus um inadvertent complexity accidental so that's the thing right somebody was like maybe it was hickey was like don't call it accidental because that implies that it's not your fault well that's the thing, right? Somebody was like, maybe it was Hickey, was like, don't call it accidental because that implies that it's not your fault. Well, that's to misunderstand where that word comes from. Yeah, no, exactly, right?

But it's like- Incidental is another one people like, but accidental is the Aristotelian term. Yeah, or it's like my driving instructor was like, we don't call it an accident, we call it a collision because an accident implies that there was no way to avoid it it's like anyways yeah so uh so the um the incommensurable complexity versus the essential complexity so it almost works you can't measure the complexity i know right yeah so then the second part, which is the explaining why, why this and not that, how does a future

of coding tool hypothetically play in that space? I'll let you, do you have any thoughts about that? I think this is the hardest one for tools to address. And maybe the most important. Yeah. I think thinking about these aspects is really, I think, very useful for thinking about tools.

Because so many times, we think what we're trying to do is explain the code. But what we actually want to do is help somebody else build a theory. Right? And so this explaining why, I think that often the most important whys are completely external to the program altogether.

They're the business situation I'm in, right? Yeah, we had to ship this game before the console launched. That's why it's not 60 frames per second. Yes, exactly. Like, why did we do this? Well, you know, business person X does not like this technique, and if they found out we were using it, they would have been mad, so we avoided it.

Or that programmer's a jerk to work with, and so we shouldn't want to use their library, even though their library might be better than ours. There's so many human factors that go into the why of code. And I actually think that those matter yeah and and that's like that is a an important challenge that a future of coding tool could rise to it's like there are many times we've talked about addressing human factors in our tools uh both on the podcast and also within the community right in the community

there have been some great discussions about like how do um programming tools and how does the design of programming tools relate to economic systems and i'm not talking about crypto i'm talking about like you know the the pains of capitalism or the pains of socialism or whatever how might how might there be some system of economy that uh the way that we think about software in the computing world might um nurture or or hinder and vice versa but also you know cultural factors like how does sexism and racism and other terrible things that we have to still confront and deal with how do those negatively impact the kind of programming tools that we have which there's those human factor angles and so this is an interesting one because it's the human factor in question is something

that people often talk about as learnability or they saying that people use is, you know, you want to write the code clearly so that a programmer, another programmer might be able to understand it because that other programmer is going to be you in six months. And so you don't want to write clever code that's hard to understand because you're just shooting your future self in the foot or wisdom around writing comments, right? You don't want to write a comment that says like here is what this line of code does and then the code is written in a way that makes it clear that yes that is in fact what it does because you know maybe that's redundant or maybe you that defeats attempts to change what that line of code does or you make a change and then the line of code and the comment disagree with one another right so there's all this thought about how do we make commenting smarter and i

think all of those things can be wrapped up as and viewed through this theory building lands where it's like what might you do to design the syntax of a language or the semantics of a language or even the concept of a programming system such that it supports the building of an initial theory about something or the encoding of the theory or the communication of the theory to another person and specifically like that that ability to explain why something does what it does you know comments aren't good enough for that maybe maybe like a natural language like syntax like apple script or ruby um is one of those things that we've tried in order to to make this you know this dimension a little bit better maybe visual programming is something we've tried in order to make this dimension a little bit better. Maybe visual programming is

something we've tried. But yeah, I haven't seen anybody make up a programming tool where it's like part of writing the program is also writing, here's what the code could have done instead, right? Like I'm going to implement a function that adds two vectors and returns, you know, a new vector that is the, the addition of the two input vectors. And I'm also going to write an implementation of a, like a different version that is less efficient or something like that. As an example of here's not what, you know, I'm doing here. And I guess I've done that, right? Like I've had a comment where it's like i have this line of code and then above it is a commented out alternative line of code and i say here's why i'm not doing that this way like here's

the way you would think to do it i'm not actually doing this because it had this bug i kept the original line of code here and then here's the new much more gnarly line of code that you would think you could simplify into the thing I commented out, but here's why I'm not doing that. One of the things I loved about the things you touched on here is that some of them were tools, but some of them were practices. Kind of cultural norms and practices that we could cultivate.

I think that's equally as important as our tools that we create, and our tools can foster or hinder those practices, but I think future of coding practice also matters. And so one of the things I'd love to see along these lines of the why is actually people writing the histories of code bases, the whys of these things, not just as comments,

but as a cultural norm and practice that we do. Think about artworks. We know we can write histories of the... Why was impressionism a movement? It was a reaction against these sorts of things. Why did expressionism occur? It was these political events and people were thinking about these ideas. We don't have the same sort of thing for programming. We have these trends, and yet I don't think we ever think about these macro trends in these lights. But we also don't see the trends in our own particular codebases and give histories of them and why they came about and what they were reactions to. And I think those things almost always for me in a code base, they unlock so much understanding because I can now assign intention to bits and parts of this code. We have Git and GitHub, and GitHub in particular has some features that kind of feel like they're

intended to support this. Like you can reference an issue from a commit message and get a bi-directional link going there same with pull requests you can comment on individual lines of code or individual parts of a change set i should say when you're doing a commit as part of a pull request or just a regular old commit you you have like bisect in git and you have you know your commit messages and you can go back through and kind of explore old versions of the code base. And, you know, I'm assuming that everybody here has done that or it can at least, you know, understand those tools and is familiar with them. But I don't think they're it.

Like, I think they are what you get if you kind of incrementally cobble your way towards an attempt to address this need but it doesn't feel to me like it was something that was designed from the outset with this sort of like uh code base as evolving historical communal artifact um sort of embraced from the outset like if you have that idea from the outset i think you'd come up with the notion of version history quite differently if you were focused on the culture of a team and their, you know, the theory that they hold and the theory that they want to bring other people into. Yeah, I think these sorts of considerations are really important. And I think it really, one of the things I think it also shows, this sort of theory building view, and now it does get into this a little bit

the end, but I think it's relevant here, is that the answer is not going to be a set of rules. The answer is not going to be, if we just follow these rules we will be able to have programming work properly. I think this is actually incredibly important because it really goes against our propensities. We're so used to working with programs that are these sets of rules. I think we feel like we can apply the same techniques of the programs to the writing, to the languages, to the cultural practices. And I think that's actually the wrong approach. We have to realize that even if our programs aren't super fuzzy, we are.

And the process of creating those programs are always going to be this fuzzy process. It might be impossible to create a version of programming where the artifact that you produce is actually as full of an encoding of the theory as you know a programmer on the team would have had like it's that that idea that if you want to have the the program survive through the ages you're going to need to bring new people in and old people are going to leave ages you're going to need to bring new people in and old people are going to leave and they're going to need to spend time together so that the new people can develop the right theory about the program it may be impossible to make a programming where that person-to-person link can be fully broken and it can take place entirely via the

source text or whatever you know know, not text assuredly. Assuredly not be text, whatever it is. You know, like maybe the source code of the program is a chatbot, and through conversations with the chatbot, you know, that produces the right symbol manipulation in the execution or whatever, right? But even then, a new programmer who's going to learn okay how did you program the chatbot they could talk to the chatbot but like maybe that's as as close as we can get right because that's like okay now the program is another person right the source code

is a person it's no longer a a static document it is now a living being of a sort. Short of that, yeah, maybe this is an impossibility. Yeah, I mean, just because it's of the moment, you know, this chat GPT thing, people might say it can meet these three criteria that we laid out, right? It can explain how the solutions relate to the world and what it handles. It can tell you why this text is there, and it can give you modifications. But it actually can't. And it's not because I don't think those things are cool. I do think they're cool, and I think they are really interesting. But number two, the why, does require us to have knowledge about the world and circumstances

and history, and those aren't going to be captured in text that can be scrubbed by chat GPT. These are real facts that actually have to be answered about the real world that is not all captured on internet archives. Now maybe Neuralink makes it so that we upload all our states of consciousness, but no, come on. We have to realize that we can't tool our way out of this problem. That's one of the things I think that this paper really reinforces for me. Maybe that seems defeatist, but I think that's interesting.

Because if we try to solve, this goes back to his point, if we misdiagnose the difficulties, we're going to be frustrated in our solutions. I think that this is really important to consider. We can't tool our way out of this. But what we can do is, if I have a program and you have just joined my team and I want to help you develop the right theory so that you can work on this program, I would almost certainly rather do that with a whiteboard than with just sitting across from each other at a table and not having a whiteboard. There exist tools that make that person-to-person transmission richer and more efficient, if not more effective. And there are practices. If you have a new developer on your team, you probably should be talking to them one-on-one more often about these sorts of things and helping them and giving them exercises that help them go explore parts of the code base they

might not have exposure to. Yes, I think that all of these things are super important. And I think what this paper has done for me, it's not so much that it's given me a brand new actual concrete tools, it's changed all of my practices and reoriented them around a different goal than what I had before. And I can start seeing how I can help those goals be accomplished better. But it's also helped me see the way in which the way we do programming, the business of software engineering, it kind of falls short, and it doesn't need to. We don't need necessarily radical change in order for it to be better. We kind of just need a reorientation around a different focal point.

And I do think we can improve a lot. And what I love about this and why I said this was so positive to me is all of these are local changes. They don't require us to like fix the whole system. They don't require us to throw away all the existing things. They require us to re-envision what we've been doing and to change those practices. And they have, i think they have real benefits immediately yeah like this is one of the strongest statements that i've read in in recent memory at least in favor of the idea of like human centricity in the act of programming like it's something that i kind of just use as a throwaway line like hey you need to think about people and use that in so many

different contexts but this is a great articulation of why you need to think about the the human element of programming and not just the you know the thing that sits kind of the the the source text right the thing that sits in the computer that's sort of in between the person and the the execution right i talk a lot about the you know the the tool has a borrowing from victor who's boring from other people tool has a side that faces the problem and a side that faces the wielder and you know there's the handle and there's the the hard end of the hammer right this is a wonderful argument in favor of really making sure that you square the things you're doing against the person who's doing them. Like, think of what it is to be a person doing programming, and here's a way of thinking

about it that really helps you make good on that, right? Like, it's easy to say, oh yeah, we need to think about people but what does that mean what does it mean to be conscious of the programmer as you're designing a thing and this is a great um a great explanation of what that could mean like here's one way to do that realize that the people who are doing the programming are developing this theory that lives in their minds and that it lives in their human essence and that you can't really take that out of the person and put it into another person and you can't expect the code to be something that a new person can just read through and pick up that theory that you know this the fact that the theory is something

that you have to express it's something that comes out by doing and the way to get somebody else to pick up that theory is by doing it with them doing it together um reminds me of like like like dancing right this idea of like entraining to music that there's this you know this rhythm and when you dance to music you are kind of entrained to it. Entrainment is the big word, right? And dancing with a partner is such a wonderful thing because it kind of, you're entraining together to the music. This is sort of like two programmers can entrain together to the theory. And that's how you learn to hear the theories, by doing it with someone else. I love that as a concrete example of what is meant by human factors.

Yeah, I think the last thing for me that I think is a big takeaway here, and I'll kind of end with this, is that when we encounter codebases that we find to be a mess, that we think are awful, that we term legacy, I think this paper gives me a certain sense of humility about that, realizing that part of what I'm reacting to, part of that visceral reaction of, what in the world were these people doing, is my lack of a theory. When I go into these code bases, and instead of

putting on my judgment, I try to think about what theory makes sense of what I'm seeing, what were the intentions behind this, what were the circumstances, it makes me appreciate a lot more code a lot more clearly. And it makes me kind of feel a little less self-righteous. And I think that these are really important practices that we can apply. And I think it kind of wards off, I think, the tendency that people might have or the opinion people might have of us looking at the future as if we have this hubris that we are going to develop it and everyone else is wrong. And I just don't think that's the case. I think we can see what other people are doing, have this humble approach to it, and help build up new theories, new ways of doing things.

And I think that's the beauty of this paper.