{"word_count": 503, "character_count": 3274}
Une série de billets visant à commenter (pas à traduire) le guide de Gentkow et Shapiro (2014). Précédemment : Ép. 1 (Introduction), Ép. 1.5 (Informatique).L'informatique utilise un principe simple : ne pas se répéter. Tout ce qui peut faire l'objet d'une automatisation doit l'être, afin d'éviter de perdre du temps à ré-implémenter quelque chose qui l'a déjà été par le passé, ou qui aurait pu être conçu de manière programmatique, c'est-à-dire automatisé.Si l'on cherche à sophistiquer un peu ce mot d'ordre, on en arrive rapidement à des distinctions comme celle entre programmation impérative et programmation fonctionnelle, mais dans le contexte de la recherche scientifique, on a surtout besoin de formuler quelques principes plus généraux :Comme pour une recette de cuisine ou une partition de musique, tout ce qui peut être automatisé, c'est-à-dire reproduit à partir d'un protocole d'enquête codifié et reproductible à l'identique, mérite de l'être, ne serait-ce qu'à des fins pédagogiques ou parce que la recherche requiert de fournir ces protocoles à des fins de publication ;Tout ce qui peut être "scripté", c'est-à-dire décrit comme l'exécution d'une suite d'étapes (les actes et les scènes au cinéma ou au théâtre), mérite aussi de l'être, afin d'en permettre la reproduction la plus simple et la plus rapide, et éventuellement, son amélioration future, dans un objectif de cumulativité.Gentzkow et Shapiro donnent des exemples avec Stata : ils décrivent l'utilisation de scripts (do-files dans le jargon Stata) mis à la chaîne les uns des autres, dont l'exécution finale est déléguée à un script Windows. L'ensemble est aussi transparent que possible et devrait rester réplicable à l'identique quelques années au moins : mission accomplie.Quand je code en R (exemple), je n'automatise quasiment jamais jusqu'à utiliser un Makefile, mais j'inclus toujours beaucoup de documentation sous la forme d'un ou plusieurs README, et laisse aussi souvent un fichier "make.r" qui remplit la fonction d'un "Makefile R" qui serait limité à l'exécution du code ((Un Makefile, de même qu'un script R plus complet, aurait aussi la possibilité d'actualiser les résultats inclus dans les articles ou les slides liées au code. En attendant, cela fait longtemps que je me dis qu'il faudrait que j'écrive des Makefiles, et ne le fais jamais.))L'autre technique d'automatisation, probablement la plus moderne et la plus appropriée, consisterait à développer le principe des notebooks (documents dynamiques : voir Jupyter, knitr et R Markdown) jusqu'à ce qu'ils puissent générer des documents collant encore plus au format des textes scientifiques ((Stata vient aussi de se mettre aux documents dynamiques avec Markdown, mais traînera toujours derrière des langages plus flexibles et entretenus par des communautés d'utilisateurs plus larges et dynamiques. À ma connaissance, SAS et SPSS sont dans les choux… Fin de partie ?)).C'est exactement ce qui est en train de se développer avec Radix for R Markdown, qui me semble extrêmement prometteur. Il faut aussi garder un oeil sur l'automatisation d'autres tâches que l'écriture, comme le peer review : la "chaîne de travail" du Journal of Open Source Software, entièrement conçue sur GitHub, est extrêmement innovante en la matière.