The Paradigms of Programming

Tags: paper review

This is the Turing Lecture by Robert Floyd wherein he underlines the importance of paradigms of programming. He starts off with giving the example of Structured Programming, explaining both the topdown approach of breaking the requirements into functions and the bottom-up approach of wrapping the primitive provided by the machines into useful abstractions. The requirement of where to draw the line between the bottom-up and the top-down is a bit fuzzy and might change from project to project and might also be dependent on the thinking process of the teams and individuals.

He then describes how the software development is still broken (well, this is the fact I keep on getting in every paper/lecture that I’m reading these days, and also how Lisp is cool at the time the paper is written) and then compares programming with other sciences. So in a book called “The Structure of Scientific Revolutions” Thomas Kuhn states that mostly the science books assume that the all the knowledge is present in the pages of the book, and the science itself is divided into various other schools which have more or less fixes rules. Once an engineer/scientist belongs to a particular group, he keeps getting the feedbacks and ideas which reinforces what he already knows and the chances of getting ideas from other schools are minimal.

Floyd draws the same parallel between science and programming, and states that even the programming language books believe that they have all the knowledge, and further there are tribes in programming world divided on languages and paradigms and in each one the usage of any other paradigms is discouraged. At this point I would like to add that the situation has improved a bit over the time – while we still have tribes for programming languages, the languages themselves are nowdays taking ideas freely from each other and a lot of mainstream programming language provide at least two paradigms to work with (Java, C#, Scala for instance provide a mix of Functional and Object Oriented programming to some degrees).

Floyd observes that the improvement of programming languages requires “continuing invention, elaboration, and communication of new paradigms”. And further, the development of individual programmer also depends on extending his repertory of paradigms. So essentially, it pays to be part of more than one tribes.

Floyd gives some more insights as how he tackles the problems

After solving a challenging problem, I solve it again from scratch, retracing only the insight of the earlier solution. I repeat this until the solution is as clean and direct as I can hope for. Then I look for a general rule for attacking similar problems, that would have led me to approach the given problem in the most efficient way the first time. Often, such a rule is of permanent value.

Further down, he states the problem of teaching “form over content”, that is, the teachers are more interested in teaching a language instead of teaching a paradigm. So, for example, these days it would be teaching Java instead of Object Oriented Paradigm. While I’m not entirely sure about the curriculum these days, but teaching just the language is not the most efficient way of teaching programming. Floyd suggest that the students be taught “systematic methods for all levels of program design”. He gives the examples of using generate/filter/accumulate functions which can be called the Functional paradigm and another cursory description of state-machine paradigm.

He ends the paper by giving these recommendations:

  • Students: For each classic algorithm, try to find the underlying paradigms so that it can be used to tackle similar problems. Merge sort, for example, uses the divide-and-conquer paradigm.

  • Programmers: Spend a part of the working day to refine your methods; learning and using “methodological abstractions” is a wise long term investment.

  • Teachers: Identify the paradigms you use and teach them.

  • Programming Language Designers: I don’t need your programming language unless it either supports the paradigm I want, or provides the way of extending itself to use the paradigm I want.

I came across this wonderful paper thanks to Adrian Colyer.