The epistemology of programming language paradigms
Upcoming SlideShare
Loading in...5
×
 

The epistemology of programming language paradigms

on

  • 477 views

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

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

Statistics

Views

Total Views
477
Views on SlideShare
477
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The epistemology of programming language paradigms The epistemology of programming language paradigms Presentation Transcript

  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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