Moreover, that one is now marked as "dupe", which I think is especially strange, since they were not only the first, but their version is more accessible than the PDF which I submitted.
Naur argues that this view is contrary to the mainstream approach to software development, is that true? Does Google, Facebook, etc... view software development as: "similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily"?
nothing changes. I read some time ago Dijkstra article from 1972(!) called "The Humble Programmer" and what he wrote describes perfectly programming in 2015 as well (maybe he had Time Machine? Who knows...).
I'm not sure whether his mainstream is similar to today's mainstream, but I think he talks about this distinction between TheoryBuilding and "industrial production" specifically in the "Method and Theory Building" section.
If I understood correctly, TheoryBuilding is rather independent of method — TheoryBuilding is what a programmer would ultimately have to do to succeed, regardless of the exact steps they are asked to take. The exact method they follow is irrelevant in comparison.
I'm not sure mainstream still means the same thing he's talking about, but even in your example of "industrial production", I don't think it's that clear that that contradicts him. He seems to be just saying that whatever that means, it's not enough to fully describe software development. But perhaps competent engineers would end up doing so anyway — in fact, if they follow a similar set of ideas that they carry with them from project to project, they would then have a theory of other people's software that they didn't build themselves, just from being in the same environment.
On the other hand, he does directly say that under the TheoryBuildingView, when the theory of a program is lost, from people being replaced too much, it is really lost, and it is very expensive to reconstruct it. So it really depends on the details of how exactly that "component-based production" works out in practice.
[Note: maybe I misunderstood the paper or something, don't trust me.]
I don't know what happens in Google, Facebook etc. but one thing I know - there are not mainstream companies. They are just big and successful. Mainstream companies are rather all these small and medium IT firms that make Wordpress based sites (for example).
I think many IT firms nowadays have exactly this kind of approach: programmer has to deliver code according to specifications created by designers and stakeholders. Nobody cares what programmer knows and what theory programmer is building - the most important thing is to bring hot new features and to do it quickly.
Off course one can argue that "features", "stories" or "backlog" are needed from business point of view. Okay. But how to construct theory if there is no time for thinking?
The idea that a Theory of the Program cannot be conveyed from one programmer to another but other means that apprenticeship seems to fit quite well with the experience of most programmers. While "program text and documentation" might not be enough, it would be interesting to understand what kind of documentation best supports Theory Building for new programmers coming into an existing project. It is my understanding the Literate Programming is thought by its proponents to be superior to traditional code/documentation in this regard.
It's good essay, but there are some theses which I don't know if I can agree with them.
He claims that theory cannot be expressed.
"(...)the knowledge held by someone who has the theory could not, in principle, be expressed in terms of rules"
Imagine that he is right and programming theory can't be expressed in words. Imagine if this was true.
Imagine there is no GoF book, no established design patterns (design patterns imo are just programming theories expressed in terms of rules...),
Imagine there is no Knuth books (if trees couldn't be expressed in terms of rules, then it would be pointless to write books about it).
Imagine there is no conferences about e.g. AngularJS or React architecture etc.
Because theory is in programmer head and "can't be expressed"
Maybe my thinking is flawed. Maybe Naur meant by "theory" something like "inner insight". If so I would agree with him. I see this quite often. People read books about design patterns and still don't understand underlying principles behind them. They just use them without deeper thinking (and they overengineer code often).
Although Naur wrote this article in context of one program but I think that programmer is building theory not only for current project but also for whole programming field. Programming skills are often independent of technology/project/language).
Naur's way of formulating that very closely resembles an argument presented by Hubert Dreyfus in his book Being-in-the-World.
It's an interpretation of Heidegger, but it's very clear and "analytical." He's even got interesting stuff in there about artificial intelligence, and he influenced several AI researchers. There was even a brief surge of interest in explicitly "Heideggerian AI" which seems to be an origin of the focus now on deep learning and emergent concepts and stuff (though I don't really know the history).
Anyway, Dreyfus says Heidegger means that most human knowledge can't be expressed in terms of rules.
That's most obviously true if you're talking about something like juggling three balls: you can write a guide, but the guide isn't possibly "exhaustive" enough to explain it so well that a person could simply follow the instructions.
And the more detailed instructions you write, the more the learner is just going to be confused. You will need meta-rules for deciding which rule to choose to apply.
To actually learn juggling, you just need a very primitive mental description, plus a little bit of coaching from someone who already knows, and a bunch of practice.
I'm just getting into Naur's writings a little bit now, and I notice one of his major interests was "programming as a human activity," so I think it makes sense to apply this same "Heideggerian" notion to programming.
Naur wants to describe the real knowledge, or let's call it skill, that actually functions in the programmer to understand and modify the program. Rules can only ever be a partial and abstracted "handbook" for aiding the learning of that skill.
It's not that rules are useless; it's more that the skill itself does not have the form of a collection of rules.
Skimming through Naur's "Antiphilosophical Dictionary," [1] it's obvious that Naur was interested in this tradition of critical philosophy [2] that wants to dethrone the "cognitivist" view of thought. He cites Gilbert Ryle, another analytic postcognitivist philosopher who appreciated Heidegger:
According to the legend, whenever an agent does anything intelligently, his act is preceded and steered by another internal act of considering a regulative proposition appropriate to his practical problem. But what makes him consider the one maxim which is appropriate rather than any of the thousands which are not? Why does the hero not find himself calling to mind a cooking-recipe, or a rule of Formal Logic? Perhaps he does, but then his intellectual process is silly and not sensible.
So I think this clarifies what Naur meant by a kind of "theory" not reducible to rules. And in the article itself, he explains that he uses the word "theory" with reference to Ryle.
Maybe Naur meant by "theory" something like "inner insight".
I'm pretty sure he means exactly that. A programmery "theory" about the subject is something that goes beyond blindly following documentation or rules. It is something that is taught (or self-taught) over time, rather than executed by following instructions.
The author even spent a whole section "Ryle's Notion of Theory" in the article to described precisely what he means by "theory". (More exactly, he describes Ryle's definition, which he is borrowing.)
Other thing I don't know if can agree is that program's author has complete theory about his program.
I think that is oversimplification. I think that often program authors don't know what they are doing. Quite often somebody new who comes to the project has more insights about the project than original authors. Because:
1. the author can be biased (that's why we need code reviews)
2. the author can be less experienced has less programming skills, than a new person on the board.
3. the author simply lost his fresh eye for the program
etc.
HTML version: http://www.dc.uba.ar/materias/plp/cursos/material/programmin...
Here's a .txt version[1] which is mobile-friendly, unlike that website.
[1]: http://pastebin.com/raw/WwXKAGnW
Interestingly, that one one was submitted about 1 hour before my submission, but didn't receive any attention:
https://news.ycombinator.com/item?id=10832964
Moreover, that one is now marked as "dupe", which I think is especially strange, since they were not only the first, but their version is more accessible than the PDF which I submitted.
This is an amazing insight into the nature of programming. It feels right to me, and will help me explain what I do to others.
I feel privileged to live in an era where many pioneers of our field are still with us. I feel the passing of that era, and their loss, keenly.
Naur argues that this view is contrary to the mainstream approach to software development, is that true? Does Google, Facebook, etc... view software development as: "similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily"?
This is from 1985. Things have certainly changed.
nothing changes. I read some time ago Dijkstra article from 1972(!) called "The Humble Programmer" and what he wrote describes perfectly programming in 2015 as well (maybe he had Time Machine? Who knows...).
And here it is (for the lazy ;)
https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
I'm not sure whether his mainstream is similar to today's mainstream, but I think he talks about this distinction between TheoryBuilding and "industrial production" specifically in the "Method and Theory Building" section.
If I understood correctly, TheoryBuilding is rather independent of method — TheoryBuilding is what a programmer would ultimately have to do to succeed, regardless of the exact steps they are asked to take. The exact method they follow is irrelevant in comparison.
I'm not sure mainstream still means the same thing he's talking about, but even in your example of "industrial production", I don't think it's that clear that that contradicts him. He seems to be just saying that whatever that means, it's not enough to fully describe software development. But perhaps competent engineers would end up doing so anyway — in fact, if they follow a similar set of ideas that they carry with them from project to project, they would then have a theory of other people's software that they didn't build themselves, just from being in the same environment.
On the other hand, he does directly say that under the TheoryBuildingView, when the theory of a program is lost, from people being replaced too much, it is really lost, and it is very expensive to reconstruct it. So it really depends on the details of how exactly that "component-based production" works out in practice.
[Note: maybe I misunderstood the paper or something, don't trust me.]
I don't know what happens in Google, Facebook etc. but one thing I know - there are not mainstream companies. They are just big and successful. Mainstream companies are rather all these small and medium IT firms that make Wordpress based sites (for example).
I think many IT firms nowadays have exactly this kind of approach: programmer has to deliver code according to specifications created by designers and stakeholders. Nobody cares what programmer knows and what theory programmer is building - the most important thing is to bring hot new features and to do it quickly.
Off course one can argue that "features", "stories" or "backlog" are needed from business point of view. Okay. But how to construct theory if there is no time for thinking?
The idea that a Theory of the Program cannot be conveyed from one programmer to another but other means that apprenticeship seems to fit quite well with the experience of most programmers. While "program text and documentation" might not be enough, it would be interesting to understand what kind of documentation best supports Theory Building for new programmers coming into an existing project. It is my understanding the Literate Programming is thought by its proponents to be superior to traditional code/documentation in this regard.
It's good essay, but there are some theses which I don't know if I can agree with them.
He claims that theory cannot be expressed. "(...)the knowledge held by someone who has the theory could not, in principle, be expressed in terms of rules"
Imagine that he is right and programming theory can't be expressed in words. Imagine if this was true.
Imagine there is no GoF book, no established design patterns (design patterns imo are just programming theories expressed in terms of rules...),
Imagine there is no Knuth books (if trees couldn't be expressed in terms of rules, then it would be pointless to write books about it).
Imagine there is no conferences about e.g. AngularJS or React architecture etc.
Because theory is in programmer head and "can't be expressed"
Maybe my thinking is flawed. Maybe Naur meant by "theory" something like "inner insight". If so I would agree with him. I see this quite often. People read books about design patterns and still don't understand underlying principles behind them. They just use them without deeper thinking (and they overengineer code often).
Although Naur wrote this article in context of one program but I think that programmer is building theory not only for current project but also for whole programming field. Programming skills are often independent of technology/project/language).
Naur's way of formulating that very closely resembles an argument presented by Hubert Dreyfus in his book Being-in-the-World.
It's an interpretation of Heidegger, but it's very clear and "analytical." He's even got interesting stuff in there about artificial intelligence, and he influenced several AI researchers. There was even a brief surge of interest in explicitly "Heideggerian AI" which seems to be an origin of the focus now on deep learning and emergent concepts and stuff (though I don't really know the history).
Anyway, Dreyfus says Heidegger means that most human knowledge can't be expressed in terms of rules.
That's most obviously true if you're talking about something like juggling three balls: you can write a guide, but the guide isn't possibly "exhaustive" enough to explain it so well that a person could simply follow the instructions.
And the more detailed instructions you write, the more the learner is just going to be confused. You will need meta-rules for deciding which rule to choose to apply.
To actually learn juggling, you just need a very primitive mental description, plus a little bit of coaching from someone who already knows, and a bunch of practice.
I'm just getting into Naur's writings a little bit now, and I notice one of his major interests was "programming as a human activity," so I think it makes sense to apply this same "Heideggerian" notion to programming.
Naur wants to describe the real knowledge, or let's call it skill, that actually functions in the programmer to understand and modify the program. Rules can only ever be a partial and abstracted "handbook" for aiding the learning of that skill.
It's not that rules are useless; it's more that the skill itself does not have the form of a collection of rules.
Skimming through Naur's "Antiphilosophical Dictionary," [1] it's obvious that Naur was interested in this tradition of critical philosophy [2] that wants to dethrone the "cognitivist" view of thought. He cites Gilbert Ryle, another analytic postcognitivist philosopher who appreciated Heidegger:
So I think this clarifies what Naur meant by a kind of "theory" not reducible to rules. And in the article itself, he explains that he uses the word "theory" with reference to Ryle.
[1]: http://www.naur.com/AntiphilDict.pdf
[2]: https://en.wikipedia.org/wiki/Postcognitivism
I'm pretty sure he means exactly that. A programmery "theory" about the subject is something that goes beyond blindly following documentation or rules. It is something that is taught (or self-taught) over time, rather than executed by following instructions.
The author even spent a whole section "Ryle's Notion of Theory" in the article to described precisely what he means by "theory". (More exactly, he describes Ryle's definition, which he is borrowing.)
Other thing I don't know if can agree is that program's author has complete theory about his program.
I think that is oversimplification. I think that often program authors don't know what they are doing. Quite often somebody new who comes to the project has more insights about the project than original authors. Because:
1. the author can be biased (that's why we need code reviews)
2. the author can be less experienced has less programming skills, than a new person on the board.
3. the author simply lost his fresh eye for the program etc.