
Peter Naur – Programming as Theory Building (1985) [pdf] - vog
http://pages.cs.wisc.edu/~remzi/Naur.pdf
======
ColinDabritz
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.

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

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

------
robitor
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"?

~~~
quonn
This is from 1985. Things have certainly changed.

~~~
hex13
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...).

~~~
HerpDerpLerp
And here it is (for the lazy ;)

[https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...](https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)

------
hex13
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).

~~~
vog
_> 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.)

------
m52go
HTML version:
[http://www.dc.uba.ar/materias/plp/cursos/material/programmin...](http://www.dc.uba.ar/materias/plp/cursos/material/programmingAsTheoryBuilding)

~~~
chm
Here's a .txt version[1] which is mobile-friendly, unlike that website.

[1]: [http://pastebin.com/raw/WwXKAGnW](http://pastebin.com/raw/WwXKAGnW)

