PROGRAMme Final Workshop

I have already published some notes on the HaPoP-5 conference, here are more notes from the accompanying PROGRAMme workshop. Tomas Petricek and Liesbeth de Mol kindly asked me to take part in the workshop as a respondent for one of the presentations, of which I am most grateful to them! Note the goal of the PROGRAMme program (!) is to publish a - possibly constantly evolving - book to answer the question "What is a computer program?" This book currently lives in a private wiki as it's still a work-in-progress, with lot of unfinished chapters.

Day 1 - PROGRAMme

What is a computer program? An anti-disciplinary view

presented by Liesbeth De Mol

This is the introduction to the whole book, reminding it's an ANR funded project

anti-disciplinary vs. trans-disciplinary: The intent is not to let each discipline (logic, CS, philosophy, linguistics...) undisturbed but rather to

The goal is to question the object that lies at the foundation, as programs have become transparent while software is "eating the world", to approach the problem with ontological glasses on

Problems are also opportunities:

Programs evolve and their use, study, and make should be on equal footing. A program is like a pharmakon, being both a cure and a poison depending.

There's a risk of alienation which has been identified, among others, by Simondon, when the use of a technological artefact becomes disconnected from its make

Programs are historical and their invisibilisation is a process that increases the alienation they induce, yet we think about them with decades or even centuries old ideas

In his response, Paul Edwards highlights there are 2 genres of computing history:

One concerned with logic, the evolution of concepts and the intellectual history of programming or calculability

Another one concerned with machines, taking an engineering and economic perspective

Computer Science is the discipline that connects notations and machines, seeking (or producing) semiotic closure of the questions it delves with

Scientific disciplines are a construct from the XIXth century (see Foucault, Les mots et les choses)

Within a discipline there's no place for some questions and that's how boundaries between disciplines are erected

The tension between notations and machines is captured by the following Greimas square:

I wholeheartedly support the intention of breaking the barriers disciplines erect around them, a process leading to the over-specialisation which has dire consequences on the whole of humanity. I think it's Gunther Anders who introduced the moral imperative that one should fullly understand the consequences of his or her actions as part of a system, or refrain from undertaking them. That software is both a boon and bane is now quite obvious and rethinking our, and others', relationship to programs, programming, and software is an important task to carry out.

Classifying programs

presented by Baptiste Mélès

The unicity of the concept of program contrasts with the diversity of concrete programs. The goal of classification is also to not forget "minorities".

Bottom-up classification approach, using comparative analysis and unifying existing classifications

Not that there aren't that many classifications, presenter highlights Brooks' (System/Product) and Lehman's (S/P/E)

Top-down (a priori) classification seeks to escape "real-life mess"

Like most of the chapters, this is a work-in-progress about which I don't have much to say.

Logic – a declaration of independence?

presented by Giuseppe Primiero

Logic representation comes before the implementation of any program

Draw on the analogy of "Logic as Motherland" and "Languages as colonies"

Flow diagrams from Von Neumann was a first step

Logic is used as a specification, using mathematical and possibly recursive definitions naturally

This leads to the Correctness problem: Is an implementation correct w.r.t. its specificaiton? This involves proving invariants by going through a flowchart and checking the state each transition leads to

Floyd, 1967: Properties are independent of their physical realisations in a language

Hoard, 1969: Programming is an exact science and we can apply deductive reasoning from the program

Then come various policies of control (Curry-Howard, logic programming, operational semantics...): How does Motherland enforces rules on colonies

Types were initially very different from logic

To what extent do colonies depend on Motherland?

Adopt a pragmatic view: The nature of programs depend on the user or agent

Do programs have habitus?

Is there something like a "Sociology of programs"?

The Order of Concepts opposes the Order of Things

A new role for Formal Methods: Not imposing regulations on what can or cannot be programmed, but hlping in constructing systems

More verifications leads to more fine-grained ontologies

It seems there are many Motherlands: Logic, business needs, military

Are we not entering a post-colonial phase of programming?

I enjoyed how far we can get applying the Motherland/colonies pattern to CS and programming history. There is still this "provincial" feeling within CS w.r.t. Mathematics and Logic. It's not uncommon for programmers with strong math background to grow some form of superiority complex regarding their inferior brethens, the "mere" programmers and this attitude is especially rife in the FP circles. Putting the bonds between logic and programming in perspective, realising that type theory or formal methodes are just one aspect of programs, is an important work to carry out.

Notations. There is no escape

presented by Tomas Petricek

Note: These notes are a mix of things from the chapter presented by Tomas and my own response to it. See the slides.

The ever growing proliferation of notations seems like a curse, as if they have escaped some Pandora's box

They are the result of a negotiation between humans and machines

We need a notation to be close to the way we think and express ourselves

But it must also be close to how machines actually work

Having different notations for humans and machines is a way to enforce division of labor & maintain hierarchy of thinkers and doers

LISP and Smalltalk provides higher notational programmability

Machines – Hide and seek

presented by Maarten Bullynck

Brown & Carr, 1954 develops the idea of "Automatic Programming" into a general translation system, whereby the computer itself is used to translate high-level language into low-level instructions, something which was novel and actively resisted by some people at the time

Computers become digital because we tame the waves from analog signal

Cloud computing and virtual machines seems to mark the triumph of software vs. hardware

There is a need to open the machines

Systems – the system if dead! Long live the system.

Understand programs from a systems perspective

A system is a stabilised heterogeneous situation containing members, see McIlroy, 1969

A program:

contains programs

interact with other programs (it's never alone)

Programs:

are programmed

programming happens within programs

States of the system are opening, exchanging, closing

Maintaining invariants:

enabling multiple purposes, generality vs. applicability

managing compatibility: convenience vs. dependence

Example of RUNCOM evolving to /etc/rc.d then systemd

systemd provides unity, separation of responsibilities of the system vs. applications