Each tool shapes its users, and each programming language reflects, in its capacity as a tool, a picture of the programmer and his task. A rather intuitive, not very explicitly described but commonly accepted picture of the programmer and his task had given rise to FORTRAN and ALGOL 60. The failure to achieve striking improvements upon them was a direct consequence of the fact that our view of the programmer and his task had insufficiently evolved.

… for instance, the paralyzing stress on the requirement that the new language should be “easy to learn”; in practice this meant that the new language should not be too unfamiliar, and too often “convenient” was confused with “conventional”. More and more people began to feel that tuning those designs to the supposed needs of the nonprofessional programmer was ….. for lack of any idea how a truly professional programmer would look like!

We knew how the nonprofessional programmer could write in an afternoon a three-page program that was supposed to satisfy his needs, but how would the professional programmer design a thirty-page program in such a way that he could really justify his design? What intellectual discipline would be needed? What properties could such a professional programmer demand with justification from his programming language, from the formal tool he had to work with? All largely open questions. In an effort to find their answers a new field of scientific activity emerged in the very late sixties; it even got a name: it was called “Programming Methodology”.