3 ms·

We don't really call "Culinary arts" theory, it's more of a "art" Peter is largely not thinking deeply and as a result he defines "theory" in such a way that it

We don't really call "Culinary arts" theory, it's more of a "art" Peter is largely not thinking deeply and as a result he defines "theory" in such a way that it refers to "Painting Portraits" as "theory" and lumps it with "The theory of Quantum Mechanics" Generally we don't refer to "Culinary arts" as theory while we do so with "Number theory." A subtle distinction in meaning exists in our subconscious and Naur simply didn't have the self awareness to see the distinction. That's what results in his largely informal and qualitative paper about mostly nothing. Yeah building a program about say E-commerce is Obviously building knowledge around e-commerce... call it "theory" if you want but in essence it's nothing new under the sun. You need to think in terms of the idea of "formal theory." Complex Number theory, The theory of general relativity. These things are distinctly in the same category as "knowledge" but refer to something more precise. Naur likely felt the distinction but failed to put his finger on it. Like many laymen, if you call Scientology a "theory" they think of it on the same professional level as the "theory of Gravity". It's largely what Peter is doing with programming... he's just using the word "theory" to give programming more legitimacy. He's not the only person to do this. Other bullshit like "Color theory" which chooses red, yellow and blue as primary colors is really just an arbitrary grouping that is only called "theory" to give it artificial legitimacy. The color sensors in your eyes are actually red, green and blue and color itself is actually a gradient of frequencies. What Naur failed to realize is that Programming is distinctly the perfect vehicle for formulating formal theories around any subject. Keyword: "formal" Imagine a theory of "e-commerce" as formal and rigorous as Newtonian Mechanics. But we almost never do this as programmers. Instead a program is more like "Culinary arts" a patch work of procedures and steps with no cohesion. I made a JSON parser in the link above. And that parser is built using formal algebraic theory. The entire parser is created as a formula. An equation of smaller parsers. It is literally the formation of a Formal theory of parsing. Or you can think of it as a Formal Algebra of parsing. Obviously there's a larger theory in academia on parsing. But in my program there's a little formal theory there. If programs are theory building. This is what is should be, this is what his paper should have been about. I think this was his intent, he just lacked the background to fully articulate and realize what is essentially a vague equivalence analogy between "programming" and "theory". Largely readers of the paper and people who agree with him fell for the same trope.

crabmusket 3y ago
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".

crabmusket 3y ago

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".