HaPoP-5

I have a long standing interest for Philosophy, and I was thus delighted when Tomas Petricek proposed me to join the Program Committee for the HaPoP-5 conference, more than two years ago. The conference was initially supposed to take place in 2020, co-located with NCrafts, but both events were cancelled because of You Know What. Here are some notes along with personal comments about each of the conference's sessions. Another blog post will cover my notes from the PROGRAMme workshop which took place in the same location right after HaPoP-5.

Warren Sack - Miniatures, Demos and Artworks: Three Kinds of Computer Program, Their Uses and Abuses

Warren Sacks is the author of Software Arts

Those three kinds of programs look superficially close but are actually very different artefacts

Miniatures are like philosophical statements in code, the goal is to rewrite a system in a miniature form in order to clarify what's specific about it, its "essence"

Demos are rhetoric in nature, demonstration in the prime sense (proving) very often to the purpose of getting more funding

Artworks are aesthetic endeavours, of course. Software art is inscribed in the history of art esp. the emergence of modern and then conceptual art which detaches the artwork from its concrete realisation

Miniatures are pedagogical, demos persuasive, artworks pleasurable

I don't know much about software arts but this talk gave me the desire to discover more of it. I liked the attempt at classifying various artifacts which share the common theme of Programming-in-the-small but serve very different purposes. It seems to me however that this classification does not do justice to the "Demo scene" whose artifacts lie at the intersection of all three classes.
Another very interesting category of programs which would have been worthy of analysis is what I would call "Constrained Competitive programming", things like the I OCCC, or programs written in very alien languages. There is an exploratory dimension that would deserve a category of its own.

Shoshana Simons - Programming practice as a microcosmos of human labor and knowledge relations

The main thesis of this work is that technical practices are not separate from the rest of the world and are historically situated which implies the programmer embeds its worldview in their work

Starting examples are:

Technical practice is hegemonic, it's a training ground for capitalism

There are 2 main approaches to ethics esp. as it relates to programming and tech:

These 2 views keep technology as a black-box they are like the 2 sides of a same coin, the input and output of "function" whose workings are ignored

The How matters, we need to open the black-box if we really want to improve our ethical approach to tech

Practice Critical Journaling which is a daily reflection on one's own relation to tech, critiquing what is unethical in it and hopefully improving it

Another interesting and somewhat provocative talk, even though the critique of the idea that scientific theories, and even more so practices, are a-historical and independent of the social context in which they are produced is somewhat mainstream nowadays. Although this talk takes a more political stance on the question, this reminds me of early Latour's work, esp. in La science en action i n which he demonstrates how scientists are not pure minds completely detached from the mundane practicalities of this world, like money, power status, ego...
I find teaching the practice of Critical Journaling a great idea, and also the emphasis on "unpacking" the black-box relevant in a world where technology is unquestioned and appears somewhat "magical", with its impacts on the real world and real people's life being ignored (think how food delivery startups take advantage of loopholes in law to employ workers without paying the full benefits and taking the responsibilities an employer has, how AirBnB's pricing algorithms impact housing prices in metropolis...)

Lucas Bang - Program Size: A Call for Inquiry

https://mitpress.mit.edu/books/making-sense

Blum's Size theorem states that a total program equivalent to a non-total program would suffer from an exponential blow-up in size. Intuitively, non-total languages allow one to "compact" the behaviour of a program

A general program could be:

"If you want to optimise your code, you have to write more code"

We need developers to pay more attention to program size

I was completely ignorant of Blum's theorem and even though its results are somewhat obvious, the fact it talks about total programming languages is very interesting and resonates with my personal investigations on pr actical use of Dependent Types.
The "call to arms" to developers to start taking care of their program size makes of course a lot of sense, and it's well-known that program size is g ood measure for complexity or at least as good as any other measure, and taming complexity is a major problem in software engineering.
In a way, Lucas is advocating for more polyglot programming, whereby teams and projects will use the "right tool" for the job and not reach out for whatever hammer that happens to be "ready-at-hand" at one point in time for everything. Using total languages (eg. Idris), or restricted languages (D hall or G race) , for the relevant parts of a system entails significant advantages in terms of quality, testing, security (eg. reduction of attack surface). My intuition is that those advantages, in the long run, offset the drawback of having to manage several languages/toolchains.

Andre Dickson - The disturbance of death and debt

Major disturbances of programs are

In Naur's views, programs die over time because the programmers lose understanding of the underlying theory, or because there is no theory

Programs are equipments

This talk was one of the most philosophical of the conferences, drawing on Heidegger's phenomenology to criticize, or shed a different light on Naur's and Cunnigham's notions and how they "disturb" the "lifecycle" of a program. We have had a follow-up discussion by mail with the presenter which somehow clarified his point of view. In my words, the idea is that a program (and the whole environment in which it is taken care of by programmers) is an equipment in the sense of Heidegger.
This talk prompted me to think again about this conceptual integrity concept, and to somehow reject Peter Naur's (and Brooks') idea that a program is somehow the "embodiment" or the "realisation" of a theory. This feels a lot like classical Aristotelian shape/matter duality which in my opinion is a common plague of our industry and possibly of our civilisation as it conveys the idea that what matters most is the shape, the idea, the theory that one bestows on matter in a god-like gesture, like how antique gods modelled humanity out of clay and infused them with life.

Dan iel Kuby - Towards a linguistic conception of programming

Linguistics is concerned with human languages whereas prog languages are the realm of formal languages theory

What is a PL? We can take the machine centric view or use the formal language sense, but talking about language for PLs is a metaphor

Goal of the talk is to reframe PL as natural languages. According to studies in cognitive linguistics programming activates the same brain areas than talking and not problem solving

The fact that the design of PL is linguistic engineerings is new only in philosophy. Famous quote from Abelson and Sussman about readability of programs dates back to the 80's

There are 2 traditions that take interest in specific languages:

This leads to the notion of Restricted Languages related to applied linguistics, the study of usage of languages

| | Spontaneous | Engineered | |:-------------|:------------------|:---------------------| | Restricted | sublanguages | Controlled languages | | | (medicine) | eg. PL | | Unrestricted | Natural languages | Planned languages | | | | eg. Esperanto |

We keep talking about languages in the context of programming but outside of CS this is understood asa metaphor and linguistics usually ignores programming languages. I like the idea of applying linguistic tools and categories to PL, considering those as part of a continuum of symbolic systems. Us practitioners are always concerned with the readability and expressivity of our programs, perhaps a little too much sometimes. Perhaps this line of research will provide insights that could inform future languages development, or possibly engineering of DSLs.

Nicolas Nalpon and Alice Martin - Why semantics are not only about expressiveness - The reactive programming case

Concerned with the epistemic difference (and cost) of different semantics: How a given formal semantics represent a system and its behaviour matters for the end user

Having identical semantic expressiveness does not imply identical semantic representation

Example: Reactive programming for UI. To give a semantic to sush a system requires dealing with 2 distinct parts: An algorithmic part and a reactive part. Experiment with 2 formalisms:

Possible solution is using hybrid semantics, eg. different fwks for different parts of the system at the cost of increasing complexity in code generation

What's the quantitative impact of various formalisms wrt to length of derivation/execution steps?

Going beyond the obvious but useless Turing completeness yardstick to compare formal languages makes a lot of sense, and the example provided while simple makes a good case about how different representations can have different "epistemic" costs. I am too sure about the usability of bigraph formalism which I am unfamiliar with but if I think about something simpler like π-calculus, the classical reduction of λ-calculus to it (and vice-versa) already demonstrates how different notations for different aspects of system can be more or less painful to work with. It's another good argument for polyglot programming, this time when it comes to formal specifications.

Robin Hill - Hello World? An Interrogation

HW is about writing complete program, end-to-end

It's about helping students' relationship with code to evolve from present-at-hand_ to _ready-at-hand

Why investigate HW?

HW does nothing, it has nothing to do about programming and is born of expedience. It is stripped of all the "interesting" parts of programming (eg. algorithms, problem solving...)

It stems from the fact students need first hand experience, to learn basic things that hard to articulate and make the programming environment ready-at-hand

There are analogs from other crafts like stitching fabrics together when learning to sew

Important realisation is that coding involves code to do coding -> we use programs to write programs which is something specific to this activity

programming = materiality + computational thinking ?

The last talk of the conference proposes a phenomenological inquiry into the humble yet ubiquitous "Hellow World" program.
I found it interesting this analysis lead to the somewhat obvious but yet ignored truth that coding involves code: Even though it's possible to write programs with pencil and paper, to actual code and program requires some other program to actually do something. HW is the first artefact a wannabe developer encounters that helps to acquire that insight. It reminds me of how puzzled I was before I learnt systems programming, when I reading books about Computer hardware and CPU, that were hinting at assembly or C code and I was pretty much clueless on how to actually write and execute those. I only have ever programmed using high-level applications like Multiplan or Access and did not know there was another reality behind those applications.
Robin Hill's work, while seemingly simple, highlights this fact there is a huge amount of implicit knowledge behind even the simplest task of programming.