2 ms·

I understand that your objection is that Naur is using the term "theory" for something different than you think it should be used for. Let's replace Naur's use

I understand that your objection is that Naur is using the term "theory" for something different than you think it should be used for. Let's replace Naur's use of the word "theory" (which he borrows from Ryle, a behaviourist) with "knowhow". Naur argues that the activity of programming is about building knowhow in a particular context. The knowhow consists of 3 behaviours: 1. The programmer having the knowhow of the program can explain how the solution relates to the affairs of the world that it helps to handle. 2. The programmer having the knowhow of the program can explain why each part of the program is what it is, in other words is able to support the actual program text with a justification of some sort. 3. The programmer having the knowhow of the program is able to respond constructively to any demand for a modification of the program so as to support the affairs of the world in a new manner. I think this is a very succinct and sensible way of viewing programming, because it explains a lot of observations about what happens when people try to make, modify, and manage software. I don't think the word "theory" itself is important to the paper, and I really don't care about "legitimating" anything to do with programming. My customers do that. I'm interested in Naur's arguments because they largely agree with the reality I observe, and provide a useful mental model.

corethree 3y ago
>I think this is a very succinct and sensible way of viewing programming I think it's a quite obvious way. To program a program you must know the program. To know the program you must know how to explain it. I mean you just formalized in a list of 3 points what's obvious to everyone: To build something you must understand that thing. Duh. It's a bit of snobbery and elusive language to package this stuff up under the word "theory". Do we call construction workers masters of building and and construction theory? No. >I don't think the word "theory" itself is important to the paper It's the title of the paper. It's important. > I really don't care about "legitimating" anything to do with programming. Everybody cares about this. If everyone in the world thought programming was akin to doing crack cocaine you likely wouldn't be programming. Nobody admits this, everybody thinks they're above it, but the reality is nobody can be completely above it and the people who spend the most time thinking that they aren't influenced by "legitimacy" are the ones most influenced by it. Naurs use of the word "theory" and trying to use at as an analogy to programming is an obvious attempt to raise programming to the level of "theory" as in "quantum theory" or "the theory of general relativity" because that's what people generally associate the word with. His paper failed to raise programming to that level because Naur failed to even completely understand what a "theory" is and the difference between something like "color theory" vs. "Number theory". Instead Naur took a flawed definition that he felt would fit his purposes and used that. At best Naur basically described programming in a way where it's just another "color theory". Why not just call the paper, "Programming is learning about the subject of the application you are programming."? Same thing right? No that title is to self evident and obvious. He needed to add some spice to the title and call it a theory. I don't think the "spice" was misplaced. His explanation was the thing that was lacking here. I'm saying programming is a step above that. Programming can be theory building akin to building things like "Electromagnetic Theory".

corethree 3y ago

>I think this is a very succinct and sensible way of viewing programming I think it's a quite obvious way. To program a program you must know the program. To know the program you must know how to explain it. I mean you just formalized in a list of 3 points what's obvious to everyone: To build something you must understand that thing. Duh. It's a bit of snobbery and elusive language to package this stuff up under the word "theory". Do we call construction workers masters of building and and construction theory? No. >I don't think the word "theory" itself is important to the paper It's the title of the paper. It's important. > I really don't care about "legitimating" anything to do with programming. Everybody cares about this. If everyone in the world thought programming was akin to doing crack cocaine you likely wouldn't be programming. Nobody admits this, everybody thinks they're above it, but the reality is nobody can be completely above it and the people who spend the most time thinking that they aren't influenced by "legitimacy" are the ones most influenced by it. Naurs use of the word "theory" and trying to use at as an analogy to programming is an obvious attempt to raise programming to the level of "theory" as in "quantum theory" or "the theory of general relativity" because that's what people generally associate the word with. His paper failed to raise programming to that level because Naur failed to even completely understand what a "theory" is and the difference between something like "color theory" vs. "Number theory". Instead Naur took a flawed definition that he felt would fit his purposes and used that. At best Naur basically described programming in a way where it's just another "color theory". Why not just call the paper, "Programming is learning about the subject of the application you are programming."? Same thing right? No that title is to self evident and obvious. He needed to add some spice to the title and call it a theory. I don't think the "spice" was misplaced. His explanation was the thing that was lacking here. I'm saying programming is a step above that. Programming can be theory building akin to building things like "Electromagnetic Theory".