Édition Pharo d'ActivePapers

Édition Python Édition JVM Édition Pharo Blog … bibliothèque —> L’édition Pharo d’ActivePapers par Konrad Hinsen, publiée le 10 mai 2019 La famille ActivePapers s’enrichit d’un nouveau membre : l’édition Pharo d’ActivePaper . Contrairement aux éditions Python et JVM, qui mettent en œuvre essentiellement les mêmes idées et concepts sur deux plateformes différentes, l’édition Pharo poursuit un objectif distinct : explorer l’interface homme-machine pour une recherche assistée par ordinateur reproductible, compréhensible et vérifiable.

L’une des questions les plus fréquentes que l’on m’a posées concernant l’édition Python d’ActivePapers était : « Cela fonctionne-t-il avec les notebooks Jupyter ? » Initialement, ma réponse était : « Pas encore, mais j’y travaille. » Et c’est ce que j’ai fait. Cependant, ce travail n’a jamais abouti à un résultat satisfaisant. Une raison tenait à des obstacles techniques. J’avais tenté d’intégrer des notebooks Jupyter au sein d’un ActivePaper, mais cela s’est révélé impossible car la conception de Jupyter en deux processus (le noyau et l’éditeur de notebook sont des processus distincts connectés par un protocole de communication) n’était pas compatible avec la restriction de la bibliothèque HDF5, qui stipule qu’un seul processus à la fois peut écrire dans un fichier.

Cela signifie donc qu’il est impossible de stocker un notebook et les résultats qu’il calcule dans le même fichier HDF5. Toutefois, plus je réfléchissais à l’intégration d’ActivePapers et de Jupyter, plus je réalisais que leurs notebooks linéaires (une séquence de cellules de code, de documentation et de résultats) ne sont pas vraiment adaptés à la tâche de documenter un calcul scientifique, sauf dans des cas simples. Si l’on examine les différents ActivePapers publiés, ils contiennent invariablement plusieurs scripts ainsi que quelques modules de bibliothèque.

Superficiellement, il peut sembler que les notebooks puissent remplacer les scripts et ainsi fournir une documentation. Cependant, une bonne documentation doit documenter l’ensemble, et non certaines de ses parties. Elle doit relier plusieurs scripts et du code issu des modules de bibliothèque.

Habituellement, les méthodes de calcul sont implémentées dans les modules de bibliothèque, et les scripts les appliquent à des jeux de données. Si la documentation se fait script par script, comment documenter les méthodes ?

Aujourd’hui, de nombreux notebooks Jupyter sont publiés ; comment gèrent-ils cette problématique ? Je ne les ai évidemment pas tous examinés, mais jusqu’à présent, mon impression est qu’il existe deux cas de figure. Le cas le plus fréquent concerne des notebooks documentant des analyses de données basées sur des méthodes standard bien connues, implémentées dans des bibliothèques répandues. Les lecteurs du notebook sont supposés connaître ces méthodes ou les apprendre ailleurs.

Connexes : DataCamp — Cours interactifs Python et science des données que vous codez directement dans le navigateur.

L’autre cas concerne des notebooks incluant l’implémentation complète de la méthode. En plus d’être limité à des méthodes simples, cette approche présente le gros inconvénient que l’implémentation de la méthode n’est pas réutilisable. Étant donné que mes propres recherches se concentrent principalement sur le développement et l’évaluation de nouvelles méthodes de calcul, j’ai conclu que les notebooks ne convenaient pas à mon travail.

En fait, j’étais déjà parvenu à cette même conclusion par l’expérience. Chaque fois que je démarrais un nouveau projet sous forme de notebook, je passais rapidement aux modules et scripts traditionnels, avec une documentation dans des fichiers texte séparés. J’ai trouvé que c’était une technique parfaitement suffisante pour mon usage personnel, mais un ensemble de fichiers, même bien organisés, ne constitue pas quelque chose qu’un autre scientifique, même un collaborateur, aurait hâte d’explorer en profondeur.

Lorsque j’ai commencé à m’intéresser à Pharo il y a quelques mois, largement par accident (je me suis inscrit au MOOC Pharo pour acquérir une expérience du point de vue de l’apprenant, avant d’endosser le rôle d’instructeur dans le MOOC sur la Recherche Reproductible ), j’ai découvert un type d’environnement de calcul interactif très différent. La famille Smalltalk, dont Pharo est l’un des membres les plus jeunes, a une longue histoire de valorisation de l’explorabilité et de la compréhensibilité (consultez cet article de blog pour plus de détails).

Coup de cœur des lecteurs : Dataquest — Parcours de science des données basés sur des projets avec un terminal guidé et des ensembles de données réels.

J’ai ensuite rapidement découvert le Glamorous Toolkit , un nouvel environnement interactif construit sur Pharo et visant un niveau d’explorabilité encore supérieur grâce à des outils de développement malléables, l’idée étant que les développeurs devraient pouvoir étendre l’environnement avec des outils d’inspection spécifiques à leur domaine. Le contexte intellectuel de ces idées a été admirablement résumé dans un article de blog par Rafael Luque. Comparés aux environnements actuels et futurs de l’univers Pharo, les notebooks de calcul semblent très limités et contraignants.

Ce qui n’est guère surprenant compte tenu de leurs origines. Les actuels Jupyter et RMarkdown ne sont que de légères variations sur l’idée de notebook introduite au début des années 1980 par Mathematica .

Mathematica à son tour, comme la plupart des autres systèmes de calcul formel, s’est appuyé sur l’héritage de Lisp, qui dans les années 1950 a introduit de nombreuses fonctionnalités révolutionnaires dans l’informatique, parmi lesquelles l’interactivité via la boucle Lecture-Évaluation-Affichage (REPL), qui constituait un moyen naturel d’implémenter l’interaction dans les contraintes du matériel d’interface utilisateur de l’époque : un terminal orienté ligne. Smalltalk, en revanche, a démarré dans les années 1970 avec des affichages graphiques et des dispositifs de pointage dès le départ, au prix d’une dépendance envers un matériel auquel très peu de personnes avaient accès à l’époque.

Comme Marshall McLuhan nous l’a enseigné, nous façonnons d’abord nos outils, puis nos outils nous façonnent. Les terminaux orientés ligne des années 1950 ont imprimé une façon de penser aux utilisateurs d’ordinateurs que même les notebooks de calcul actuels ont conservée, malgré l’existence depuis des décennies d’approches supérieures.

Et cette technologie supérieure n’est pas seulement Smalltalk, qui est toujours resté un système de niche. Les interfaces graphiques non linéaires sont ce que nous utilisons tous pour travailler avec des images ou des fichiers audio. Ces tâches sont presque impossibles à réaliser ligne par ligne, elles n’ont donc pas vraiment eu lieu avant les interfaces graphiques. Pour les calculs, les interfaces graphiques sont probablement arrivées trop tard : la pensée linéaire était déjà devenue une norme culturelle.

L’édition Pharo d’ActivePapers vise à modeler l’environnement GToolkit pour en faire un environnement dédié à la recherche assistée par ordinateur, plutôt qu’au développement logiciel. Ces deux activités sont distinctes mais partagent de nombreuses caractéristiques communes. La principale différence est que la science se concentre sur les données et les modèles, le logiciel n’étant qu’un moyen pour atteindre une fin.

Connexes : Udemy — Achetez des cours individuels de Python scientifique, souvent avec des remises importantes.

Cependant, c’est un moyen si important que tout le reste est structuré autour de lui. De plus, le développement logiciel traite également de données (sur le logiciel) et de modèles (en tant que spécifications). En fin de compte, les différences sont graduelles plutôt que fondamentales.

Ce voyage ne fait que commencer, et je ne sais pas vraiment où il mènera. Restez à l’écoute pour les mises à jour ! En attendant, vous pouvez regarder cette vidéo de démonstration . commentaires propulsés par Disqus