Cet atelier est le résultat d'un groupe de travail volontairement inter-disciplinaire sur la question des Notebooks.
Il a été joué pour la première fois dans le cadre d'une journée d'études normande sur les données de la recherche le 3 décembre 2021 à Caen. Cet atelier a été conçu avec pour objectif, à terme, d'être reproductible dans d'autres contextes.
Cet atelier du 6 décembre constitue un premier jalon opérationnel du groupe de travail.
Avec le site et le portail, cela ne s'arrête pas là, et nous prévoyons d'autre réunions en 2022.
Nous sommes déjà plus d'une dizaine dans le cadre du GT à vouloir élargir ces questions à différents métiers, différentes disciplines.
Le groupe de travail, composé d'autre membres que ceux présent aujourd'hui, ne s'arrête pas à la création de cet atelier.
Nous avons mis en place :
Nous avons fait un choix d'outils pour répondre à l'objectif suivant :
Cet atelier est séparé en deux parties, théorique et pratiques. Dans la partie théorique, qui ne dépassera pas une heure, nous allons parler de l'historique et de la nature même de l'objet. Cela permettra de faire le lien avec la question de la reproductibilité, pregnante depuis quelque temps dans l'actualité scientifique.
Nous questionnerons aussi les pratiques, les termes autour d'un objet technique qui questionne nos modes de construction de connaissances en général, et plus particulièrement en inter-disciplinaire. Ce qui nous amènera à un débat intéressant, celui de la place de cet objet dans le cadre des questionnements actuels autour du cycle de vie des données de la recherche.
Enfin, nous essaierons de donner quelques pistes/pointeurs vers des initiatives existantes en France et en Europe.
Une partie pratique, plus longue, permettra de prendre mesure des possibilités offertes, dans différentes disciplines (Biologie/Epidémiologie et SHS), par cet objet.
Présentation d'un notebook et du résultat de ce notebook au format org-mode.
Le notebook est présent à la racine du
répertoire, il se nomme examples.org
Quelques remarques :
l'execution du notebook permet de produire des documents sous différents formats : pdf, odt, etc.
Le concept, comme souvent, de "Notebooks" apparait après l'existence d'outils préfigurant ce type d'objet.
C'est à la jonction des mathématiques et de l'informatique, et plus précisément autour des Computer Algebra Systems (CAS) permettant la Symbolic Computation, ou en français système de calcul formel (ie "do mathematics by computer" (Stephen Wolfram)) que sont apparu en premier cette possibilité d'exprimer et de solver des équations de façon interactive au sein d'un document mélant textes et formules.
La plupart des systèmes développés dans ce cadre évoque la vision théorique d'un "Mathscope System" proposé par Minski’s en 1965.
La volonté de manipuler plus facilement les expressions mathématiques dans des documents poussent les développeurs à explorer différents concepts du Notebook encore présent actuellement : le mélange texte-graphique-math (MathCad-1985), l'interactivité (Mathlab-68-1971, MathScribe-1986, GI/S-1987, CaminoReal-1988, Theorist-1990, Milo-1988, etc.), la documentation hypertexte (Axiom-1990) la portabilité et la publication du notebook (ex Tioga/CaminoReal-1988), la séparation interface & solveur (ex : Axiom-1992, Maple-1980, Mathematica-1988, CaminoReal-1988), etc.
On trouvera plus de détail sur cet historique complexe dans les travaux de [Kajler1998] et la thèse de [Soiffer1991]
Au coeur du concept des Notebooks actuels, on trouve le concept de "Literate Programing", formalisé en 1984 par Donald Knuth.
Une des inspirations majeures pour le premier prototype développé par Knuth [Board1996] est en lien avec le concept de Holon Programming développé par Pierre Arnoul de Marneffe [Marneffe1974]
Avant d'être instancié dans des outils, le LP constitue avant tout un paradigme, une façon de penser différemment la conception et l'écriture des programmes informatiques.
Les deux définitions reprisent dans ce slide définissent un peu l'idée générale, il s'agit d'écrire des programmes avant tout pour des humains avant d'écrire pour des machines. Cela suppose d'associer une narration parallèle à la construction/constitution d'un programme informatique, donc un ordre et un style adapté pour un lecteur humain, mais pour lui raconter quoi au juste ? Et dans quels buts ?
Nous allons donner quelques pistes ici, mais vous pouvez consulter plus de témoignages ici : http://www.literateprogramming.com/
A tort souvent le LP est perçu comme une façon d'écrire de la documentation pour un programme.
Tim Daly l'explique bien, on s'intéresse non pas au comment?, mais au pourquoi ?. Ce qui nous intéresse c'est de comprendre pourquoi le programmeur a choisi d'écrire son programme ainsi, c'est pour ainsi dire, une explicitation.
Pour cela il faut comprendre que la programmation est une activité d'écriture un peu particulière, résultat d'une réflexion complexe mobilisant tout à la fois des concepts, des symboles, des données, des objectifs, des contraintes.
La lecture du code source ne permet pas à elle seule de dérouler toute cette compréhension.
Cette information est traditionnellement perdu ou dilué. C'est pour cela souvent qu'un programme est si difficile à transmettre, même avec de la documentation, car il faut réifier toute cette compréhension préalable/implicite à la présence de CE code source à CET instant.
Une autre notion entre en jeu avec le LP, c'est l'idée d'une reproductibilité augmentée ici par l'auto- description, pour des humains, du pourquoi derrière ce programme.
Par exemple pour Axiom (1990), un solveur mathématique complexe, hérité de Scratchpad 2 (1980), ayant accumulé des années de recherche en mathématiques, Tim Daly a fait le choix de le réécrire en LP en 2001 lors de son passage en Open Source. Ainsi même dans 70 ans, il sera possible de comprendre comment mais surtout pourquoi ce programme est écrit ainsi : hypothèses, algorithmes, abstractions, etc.
Pour mieux illustrer le LP, le mieux c'est d'imaginer le monde sans.
Imaginons un projet en Quantum Computing
questionnant cette possibilité très concrête de la réalisation de l'expérience du chat de Shrodinger au sein du
métaverse, nous avons donc deux documents :
Le code source fait généralement office de preuve en informatique, lorsqu'on l'exécute et on le re-execute, à condition expérimentale égale (graine aléatoire, etc.) celui-ci génère (en théorie c'est plus complexe) les mêmes données et les mêmes graphiques (éléments 1,2,3). Le développeur a produit des commentaires (A,B,C) pour expliquer sa méthode de calcul et les algorithmes de représentation.
Le document publié, dont la taille est souvent limité en nombre de pages, reprend principalement les résultats graphiques, les données (1,2,3) et la méthode de calcul sous une forme résumée (A,B,C). Celui-ci apporte l'interprétation, qui n'est pas présente dans le programme.
Plusieurs remarques/problématiques sur ces deux documents et leur usages :
a) les deux documents ne sont pas forcément lié, la modification de l’un est indépendante de la modification de l’autre,
b) le fonctionnement du programme est à peine décrit dans la publication principale (bloc jaune). Si il y a bien quelques commentaires dans le code source, ils n’expliquent pas forcément dans le détail le fonctionnement du programme.
Si on va un peu vite, cela peut finalement paraitre assez logique, les objectifs poursuivis par chaque documents sont en apparence différents. D’un côté il s’agit de décrire le résultat d’un travail scientifique, et de l’autre il s’agit d’écrire un programme efficace compréhensible par l’ordinateur d’abord, l’humain ensuite.
Seulement voilà, ces dernières années on s’est rendu compte que les deux derniers points pouvaient poser problème , comme l’a montré l’étude de [Collberg2016] :
a) il peut y avoir un différentiel important entre les deux documents, jusqu’à parfois remettre en cause la valeur des résultats scientifiques.
b) le code source n’est pas forcément exploitable, pour diverses raisons : absence du contexte d’execution, des données, erreurs/bugs, codes et/ou commentaires partiels, etc.)
Le LP introduit deux opérations importantes : tangle et weave
Dans ce nouveau document LP, forcément plus long, les explications et le code source sont liés de façon cohérente car ils existent dans le même document.
On s'appuie sur un programme afin d'extraire et de regénérer les deux documents de départ à partir de ce document LP unique. L'opération tangle produit un document à destination de la machine et l'opération weave produit un document à destination de l'humain.
Si le document LP suit un schéma narratif, alors il est logique que le code source ne soit pas imposé, et c’est bien l’argumentation qui prime sur le code tel qu’il va être lu par la machine. Dans l’exemple, on voit que B peut être présenté avant A si l’argumentation l’impose.
Le LP repose sur la notion de chunk.
Un Chun est composé d'un entête, d'un corps, produisant éventuellement un résultat.
Chaque Chunk peut être encapsulé, hierarchisé, réutilisé et paramétrisé à loisir, ce qui en fait un objet relativement complexe lorsqu'on regarde la combinatoire d'organisation de document/code que sa flexibilité permet.
Ce concept de chunk a été repris et opérationnalisé dans le cadre de différents outils, de différents languages.
a) Knuth a assez logiquement écrit les premiers outils pour le LP, aussi afin de démontrer la faisabilité de sa démarche : WEB (Pascal), puis CWEB (C). NoWeb est une version plus récente de Web, elle est multilangages et surtout plus simple.
b) Org-mode et org-babel permettent de faire du LP via le logiciel Emacs c) Jupyter, RMarkdown sont les outsiders les plus récents. Si RMarkdown reprend la plupart des principes du LP, ce n'est le cas des chunk proposées par Jupyter.
Dans cet exemple, nous utilisons un des concepts intéressants du LP et des Chunks en s'appuyant sur leur réutilisabilité, et cela quelque soit l'ordonnancement du texte.
Lors des opérations de transformation tangle ou weave les blocs traitement_1 et traitement_2 vont être copiés dans le bloc chaine_traitements
Cette possibilité de faire varier l'ordonnancement au service de la narration nous permet de casser l'ordre habituellement imposé pour une lecture par la machine.
Autre fonctionnalité, les Chunk peuvent également être paramétré au moment de leur execution.
Dans cet exemple, le Chunk somme prend un paramètre a et un paramètre b, les deux sont initialisés avec des valeurs par défaut à 0.
Le bloc calcul_complexe fait appel au bloc somme en passant des valeurs pour a = 3 et b = 5.
De la même façon que les fonctions en informatique ou en mathématique, la possibilité de paramétrer les Chunk permet une grande modularité dans la composition des documents.
Le Chunk est un objet plus ou moins complexe selon comment ce concept est opérationnalisé :
a) Les entêtes sont fait d'un certain nombre d'options et de paramètres. Les paramètres peuvent être simple (numérique, caractère, etc.) ou complexe (tables, function, etc.)
b) Le corps contient un code source qui peut être executé, celui-ci peut apeller ou produire des données en se basant sur les valeurs de paramètres qui lui sont passés.
c) Le corps peut également inclure le corps ou le résultat de l'exécution d'autre Chunk avec la syntaxe <<...>>, comme on l'a vu précédemment.
Il y a donc des différences fondamentales entre le LP et les Notebooks.
Le LP est un concept, qui va jusqu'à inclure un style de programmation.
Si les "Notebooks" s'appuient effectivement sur tout ou partie des outils créés pour le LP, les objectifs peuvent diverger, notamment sur cette question fondamentale de la reproductibilité.
L'application du LP tel que pensé par Knuth, Daly, implique automatiquement cette question de la reproductibilité et lui ajoute une dimension autre, le Pourquoi, qui dépasse la seule reproduction technique du document.
Les Notebooks n'implique ni l'obligation de style, ni l'obligation de reproductibilité, plusieurs études récentes ont justement fait un état des lieux très concrets de ce problème en partant des Notebooks déposés sur les forges logicielles type Github/Gitlab.
L'autre différence majeure se trouve probablement dans l'objectif même guidant la production de Notebook versus la production de programme en LP. Le phénomène est en cours d'analyse, mais il semblerait que les Notebooks soient principalement utilisés pour de l'analyse et de l'exploration de données, donc des bases de codes sources finalement assez limitées. Or le LP a montré qu'il pouvait être mobilisé sur des programmes de plusieurs milliers, voir millions de lignes, comme Tex/Latex, Axiom, et plus récemment Inform.
De nombreux clusters de calcul haute performance proposent désormais un accès à leur puissance de calcul via une interface du type Jupyter qui permet d'éditer et d'exécuter des notebooks. Même si les usages sont différents, ce type d'interface est beaucoup plus conviviale que le traditionnel terminal Unix et sa ligne de commande.
La citation vient de Rollin Thomas, Big Data Architect au NERSC, et est tirée de l'article « Project Jupyter: A Computer Code that Transformed Science » (2021).
L'Institut Français de Bioinformatique propose un accès à son cluster de calcul NNCR via Jupyter Lab (pour des notebooks Jupyter) et RStudio (pour des notebooks Rmarkdown).
Le projet Plasma est une plateforme d'enseignement créée à l'Université de Paris afin de former les étudiants à l'analyse de données en biologie. Plasma propose des interfaces Jupyter Lab et RStudio qui permettent l'édition et l'exécution de notebooks.
L'Université de Rouen est en train de déployer Plasma sur sa propre infrastructure afin de le rendre disponible aux étudiants et enseignants de l'UFR de Santé puis éventuellement à ceux de l'UFR de Sciences.
