Talk in seminar of IRILL
I had been invited by Emmanuel Chailloux to talk about Guix in the seminar of IRILL. The experience was interesting because the audience was researchers in computer science, specifically compilation. On a sad note, it was winter holidays, so the audience was about quality and not quantity; to put it mildly.
The sildes of the presentation are there (PDF) and the source here. Thanks Ludovic Courtès and Ricardo Wurmus for their courtesy; slides p.36 and slides p.34-35, 37, respectively. Video recording is available (French).
This talk was a nice opportunity to read again Eelco Dolstra's PhD thesis. Especially, "Figure 3.1.: Deployment / memory management analogies" p.55 (PDF page 63).
| programming | deployment | |
|---|---|---|
| memory | \(\leftrightarrow\) | disk |
| object (value) | \(\leftrightarrow\) | component |
| address | \(\leftrightarrow\) | path name |
| pointer dereference | \(\leftrightarrow\) | IO |
| pointer arithmetic | \(\leftrightarrow\) | S-exp / G-exp / string operations |
| dangling pointer | \(\leftrightarrow\) | reference to absent component |
| object graph | \(\leftrightarrow\) | dependency graph |
And from my point of view, it resonates with Inria Days: session « Les défis de la compilation » – S. Blazy, X. Leroy, X. Rival, M. Serrano. The very last question/answer is summarised (traduttore, traditore) by:
Question: Concern as programmer, not really core compilation or research: how to compile?
build system is an issue!
- Answers:
- build system is well-known: walk the graph of dependencies, done
- xkcd Standards: every 2-3 years, something is considered wrong with the 122 already existing ones so, another 123th is created, maybe better, maybe not
- Haskell, none but libraries allowing to build your own: elegant and declarative
- complete supply is also a concern
- as researcher, we are distraught!
Well, for what it is worth, I retain in order to mitigate as researcher, we are distraught,
none but libraries allowing to build your own: elegant and declarative
and maybe, or well let say from my point of view:
- Dolstra's PhD thesis paves the way by applying functional programming to package management,
- Guix paves the way being that library which rules them all.
And similarly as the paper Build Systems à la Carte by A. Mokhov, N. Mitchell and S. Peyton Jones, which reviews the various build systems and then organize them using some functional programming framework, we could imagine extend the work pionnered by Dolstra's PhD thesis – if not already done. :-)
That’s all.
Join the fun, join Guix for Science!
Here the transcript (my bad if I misunderstood) from the video sequence:
Question: Je voudrais parler d'un truc qui nous touche en tant que programmeur même si ce n'est pas vraiment de la compilation, c'est la facon dont on compile. Cette horrible chose que sont les systèmes de build, où on a en bas niveau des langages cibles qui sont du shell, du m4, ou toute autre sorte d'horreur, du Makefile, du BSD Makefile, j'en passe et des meilleures, avec des descriptions de haut niveau où on espère que le programmeur a correctement spécifié ses intentions mais à la fin quand on parle d'édifice logiciel qui comporte des milliers, voire dizaine de milliers de fichier source, finalement on a un problème de sûreté derrière de savoir si est-ce que la personne qui a modifiée son truc, est-ce que ca a bien affecté toute la chaine de compilation derrière. Est-ce qu'il y a des choses qui sont faites qui pourrraient être faites dans ce domaine ?
Answer: Les principes généraux d'un système de build sont bien compris, il s'agit de construire un graphe de dépendences et ensuite de le parcourir dans un ordre topologique. Bon, point. Après oui tous les 2-3 ans, quelqu'un dit, ca va pas du tout les 122 systèmes de build que nous avons déjà, ca va pas du tout, je vais faire le 123 ième et généralement il n'est pas tellement mieux. Récemment Bazel avec Google, avant Ant avec Java, dans le monde Caml, il y en a eu au moins 3, dans le monde Haskell, il n'y a pas vraiment de système de build mais il y a plein de bibliothèques qui permet d'écrire soi-même son système de build, donc problème résolu. Très élégant, très déclaratif. Ah oui, tu n'as pas mentioné les systèmes de paquets qui sont la deuxième plaie après les systèmes de build. Donc oui oui, c'est des problèmes. Et comme tu dis, c'est des problèmes de sécurité aussi, de source d'approvisionnement, d'où viennent les morceaux qui composent le logiciel à la fin. J'avoue qu'en tant que chercheur je me sens désemparé devant ca, voilà.
