Talk prepared and presented with Marco Benini at HaPoC2, ENS, Paris.

1. The epistemology of programming language paradigms
HaPoC 2013
F. Gobbo & M. Benini
Univ. of Torino & Univ. of Insubria
federico.gobbo@unito.it
marco.benini@uninsubria.it
$
BY:
C
CC
28-31 Oct, 2013
(1 of 23)

2. Modern computing in terms of information hiding
The whole history of modern computing can be seen in terms of
information hiding (Gobbo and Benini, 2013):
in the early days, there was only a machine-tailored assembler
letting programmers write one-to-one machine-readable
instructions;
(2 of 23)

3. Modern computing in terms of information hiding
The whole history of modern computing can be seen in terms of
information hiding (Gobbo and Benini, 2013):
in the early days, there was only a machine-tailored assembler
letting programmers write one-to-one machine-readable
instructions;
then, a fundamental LoA was introduced by Backus (1978) during
the design of Fortran and its implementation via a compiler, i.e.,
the computer program that translates the source code into
machine code: the Backus-Naur Form (BNF) abstracts over the
language, allowing to compute on its structures;
(2 of 23)

4. Modern computing in terms of information hiding
The whole history of modern computing can be seen in terms of
information hiding (Gobbo and Benini, 2013):
in the early days, there was only a machine-tailored assembler
letting programmers write one-to-one machine-readable
instructions;
then, a fundamental LoA was introduced by Backus (1978) during
the design of Fortran and its implementation via a compiler, i.e.,
the computer program that translates the source code into
machine code: the Backus-Naur Form (BNF) abstracts over the
language, allowing to compute on its structures;
the next LoA in programming has been introduced after Böhm and
Jacopini (1966), a result that permitted to hide the way the
machine interprets the flow of control, and to change it to
something which can be easily analysed mathematically.
(2 of 23)

5. The early days of Structured Programming
In the end of the 1960s it became evident that computer
programming ought to be more solid, both theoretically and
practically. In particular:
the structured program theorem by Böhm and Jacopini (1966)
the j’accuse against the goto statement by Dijkstra (1968)
in 1968 the NATO Science Committee introduced the concept of
‘software engineering’;
in 1968 an IFIP Working Group on ‘Programming Methodology’
was established.
(3 of 23)

6. Why Structured Programming
Software projects were becoming more complex, involving an
increasing number of programmers, as for instance the IBM
System/360 family and in particular the OS/360 (Brooks, 1995)
[IBM] did not like the popularity of my text; it stole the term
“Structured Programming” and under its auspices Harlan D.
Mills trivialized the original concept to the abolishment of the
goto statement. — Dijkstra (2001)
Structured Programming permitted to cope with this complexity,
essentially through best practices and new ad-hoc programming
languages (Ceruzzi, 2003). Here, we will analyse the latter.
(4 of 23)

7. Programmers and their view of the machine
From the point of view of a programmer, a program is the result of a
work whose aim is to instruct a (given) machine to solve a given
problem.
Usually, the machine is not just a piece of hardware, but is also
considered as an abstract machine, possibly equipped with an
operative system and a number of services, like a database, graphical
user interface, networking, etc.
(5 of 23)

8. How programmers choose a programming language
To simplify terminology, we will use the term solution to identify the
result of executing a program, and we will reserve the term algorithm
to identify what has to be coded as a program in a programming
language.
The choice of the programming language defines how the way to
achieve the solution is described to the machine. In this respect, the
many different programming languages have been justified because of
their ability to express the various problems and the ways to solve
them.
(6 of 23)

9. The Method of Levels of Abstraction
The method of LoAs (Floridi, 2008) can be used to describe
programming in terms of informational organisms (inforgs):
1. the programmer is the informational agent;
2. the machine is the artificial artifact — where the Levels of
Organisation (LoOs), i.e., the apparatuses, can be identified.
A software project is an infosphere, including processes and mutual
relations among the inforgs directed to the same goal.
(7 of 23)

10. Machine, solution, program
From the point of view of the programmer, the machine is described
by MO , a LoO which specifies what can be inspected of the machine,
and MA , a LoA that provides the description of how observables in
MO are organised and what instructions can be used to manipulate
them.
Similarly, the solution of the problem is ultimately specified by a pair
SA , SO , a (partial) LoA and the corresponding (partial) LoO which
should become (part of) PA and PO , the LoA and the LoO of the
program to be constructed.
(8 of 23)

11. The program in terms of Levels of abstraction
When the program will be completed, the pair formed by PO and PA
will be a new abstract machine that can be used to calculate the
solution of the original problem — the purpose of the programming
activity.
The algorithm the programmer has to devise is the mapping between
the level of abstraction P and the level M, which must become an
observable of M, in the form of an executable program.
The presence of a mapping is what distiguishes
computational-inforgs: in these inforgs, it is essential that the
artifact is computational, i.e., it is able to execute a coded algorithm.
(9 of 23)

12. Programming as the creation of a c-inforg
It is worth remarking that, in a sense, the act of programming creates
a new computational inforg from an existing one: from the pair
machine + programmer, the pair abstract machine + user arises
thanks to the programmer’s activity.
If the above cited mapping would be absent, the user would be unable
to use the machine to solve the problem, thus failing to fulfill the
purpose of programming!
(10 of 23)

13. Why levels of explanations
The choice of the programming language determines the
epistemological approach sustaining the programmers’ goals, which
is identified as a Level of Explanation (LoE) by Floridi (2008).
Unlike LoAs and LoOs, LoEs do not really pertain to the system,
rather they are an epistemological lens through which the
informational agent(s) approaches the goal of programming.
(11 of 23)

14. The epistemological priority of LoEs
As an example, modular arithmetic is a LoE a machine-level
programmer adopts to explain what some instructions of the central
processing unit.
It is worth noticing how some LoE of the would-be program are
known in advance to the programmer: in fact, the purpose the
program is written for is well-known to the programmer, and this
forms a LoE for the program, even before it exists as a LoA/LoO pair.
Thus, the LoE adopted by the programmer has an epistemological
priority on the LoA/LoO pair.
(12 of 23)

15. A taxonomy of programming languages
Paraphrasing the three-layered description of programming by
Hofstadter (1979):
the source code is the novel;
the programmer is the novelist;
the programming language is the literary genre of the novel.
To these levels we can add
the executable code is the book;
the machine is the narrator.
We can classify programming languages in various way; applying the
method of LoAs, we can find only three major paradigms, according
to the kind of information got hidden.
(13 of 23)

16. 1. The procedural paradigm
Mainly because of the historical development of computational
machineries, current computers can be seen as structures of von
Neumann machines (Gobbo and Benini, 2013).
This class of languages abstracts over the structure of von Neumann
machines by allowing more data types than just computational
numbers and by allowing more or different instructions than those by
the bare machine.
(14 of 23)

17. The machine in the procedural paradigm
The essential structure of the von Neumann machine is retained: an
engine operating on a memory via a set of instructions from a fixed
set; the code is organised as a sequence of elementary instructions
each one modifying the state of the machine — the next instruction
to execute chosen according to the state:
most programming languages allow programs to perform actions
that change the values of variables, or which have other
irreversible effects (input or output, for example); we say that
these actions have side-effect — White (2004) in Floridi (2004)
(15 of 23)

18. 2. The declarative paradigm
Historically, the von Neumann machine was nothing but one of the
possible models of computation introduced in the beginning of the
last century. Other models, like Church’s λ-calculus, Herbrand
universes, stable models, etc., where proposed and studied. To some
extent, the actual evolutions of these systems are much closer to
interesting problems, i.e., they allow to describe the problem almost
directly in the terms of their language.
Moreover, these systems have an instrinsic computational meaning,
which amounts to say that the very description of the problem hides
in itself the algorithm to solve it. The programming languages based
on these systems are called declarative.
(16 of 23)

19. The machine in the declarative paradigm
This class of programming languages, comprising logical languages as
Prolog or Answer Set Programming, but also the functional languages
as ML or Haskell, abstracts over the very structure of the von
Neumann machine.
In fact, each language in this class provides an abstract machine
operating on a different computational model, perfectly described in
mathematical terms – sometimes before von Neumann’s. The
programming language contains some sort of simulator to enable the
execution of the code on a standard von Neumann architecture.
(17 of 23)

20. 3. The object-oriented paradigm
Another approach is by the introduction of the concept of object,
which is conceived originally on a different LoE, philosophically based
on Leibniz’s monads and the subsequent adapted notions of 20th
century physics and biology (Kay, 1993).
In fact, the object-oriented paradigm abstracts over the organisation
of memory and state of a von Neumann architecture by putting a
layered structure of abstractions over them.
(18 of 23)

21. The machine in the object-oriented paradigm
One can consider each object-oriented class as a LoA over the
memory/state of the hosting machine, which is equipped with an
internal map (its implementation) and an external interface (its
LoA/LoO pair).
These classes are, in turn, the building blocks for further levels of
abstractions whose aim is to construct the PA /PO pair, i.e., the levels
of abstraction the program has to provide to fulfill its goal.
(19 of 23)

22. The relations between the three paradigms
It should be clear that the object-oriented paradigm is orthogonal
to the declarative paradigm: in fact, nothing prevents from
introducing layers of abstractions over a basically different
organisation of memory, like the database of clauses in Prolog, or the
heap of functions in Standard ML. And, of course, this has already
been done, in many different ways.
Also, these paradigms can realised in a different degree by a language:
for example, in LISP, the grandfather of functional languages, there is
an implicit state, while in most modern functional languages, the
state is explicit and very limited.
(20 of 23)

23. Observations
Thus, the gradients of applications of the previously exposed
paradigms allow to naturally place each existing programming
language in a multi-dimensional space. The fact that these
gradients are not necessarily of a quantitative nature is the deep
reason why philosophy and not engineering is the right discipline
wherein to analyse the principles of programming.
When dealing with really complex problems, which happens in most
contemporary software design, rarely a single language has the right
features to model the whole problem.
Probably, the universal language is an unreachable dream, as
hiding/showing some features is essential to solve specific problems
— and what to hide in a problem is exactly what one wish to expose
in another one.
(21 of 23)

24. Essential References
Backus, J. (1978), ‘The history of FORTRAN I, II, and III’, SIGPLAN Not.
13(8), 165–180.
Böhm, C. and Jacopini, G. (1966), ‘Flow diagrams, turing machines and languages with
only two formation rules’, Communications of the ACM 9(5), 366–371.
Brooks, Jr., F. P. (1995), The mythical man-month (anniversary ed.), Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA.
Ceruzzi, P. (2003), A history of modern computing, History of computing, MIT Press.
Dijkstra, E. W. (1968), ‘Letters to the editor: go to statement considered harmful’,
Commun. ACM 11(3), 147–148.
Dijkstra, E. W. (2001), What led to "notes on structured programming". circulated
privately.
Floridi, L. (2008), ‘The method of levels of abstraction’, Minds Mach. 18, 303–329.
Floridi, L., ed. (2004), The Blackwell guide to the philosophy of computing and
information, Blackwell, London.
Gobbo, F. and Benini, M. (2013), ‘From ancient to modern computing: A history of
information hiding’, IEEE Annals of the History of Computing 99(PrePrints).
Hofstadter, D. R. (1979), Gödel, Escher, Bach: An Eternal Golden Braid, Basic Books,
New York.
Kay, A. C. (1993), ‘The early history of smalltalk’, SIGPLAN Not. 28(3), 69–95.
Lloyd, J. W. (1984), Foundations of logic programming, Springer-Verlag New York, Inc.,
New York, NY, USA.
White, G. (2004), The Philosophy of Computer Languages, in Floridi (2004), chapter 18.
(22 of 23)

25. Thanks for your attention!
Questions?
For proposals, ideas & comments:
federico.gobbo@unito.it & marco.benini@uninsubria.it
Download & share these slides here:
http:/federicogobbo.name/en/2013.html
(23 of 23)
$
BY:
C
CC
Federico Gobbo & Marco Benini 2013