ActivePapers Pharo-udgaven

I modsætning til Python- og JVM-udgaverne, som primært implementerer de samme idéer og koncepter på to forskellige platforme, forfølger Pharo-udgaven et andet mål: at udforske menneske-maskine-grænsefladen til reproducerbar, forståelig og verificerbar computerstøttet forskning. Et af de hyppigste spørgsmål, jeg har modtaget vedrørende Python-udgaven af ActivePapers, var: “Fungerer dette med Jupyter notebooks?” Oprindeligt var mit svar: “Ikke endnu, men jeg arbejder på det.” Og det gjorde jeg.

Dette arbejde førte dog aldrig til et tilfredsstillende resultat. En årsag var tekniske forhindringer. Jeg havde forsøgt at inkludere Jupyter notebooks i en ActivePaper, men det viste sig at være umuligt, fordi Jupiters design med to processer (kernen og notebook-editoren er separate processer forbundet via en kommunikationsprotokol) ikke var kompatibel med HDF5-bibliotekets begrænsning om, at kun én proces ad gangen kan skrive til en fil. Det betyder, at man ikke kan gemme både en notebook og de resultater, den beregner, i samme HDF5-fil.

Men jo mere jeg tænkte over at integrere ActivePapers og Jupyter, desto mere gik det op for mig, at deres lineære notebooks (en sekvens af celler med kode, dokumentation og resultater) ikke er rigtigt egnet til opgaven med at dokumentere en videnskabelig beregning, bortset fra i simple tilfælde. Hvis man ser på de forskellige publicerede ActivePapers, indeholder de uden undtagelse flere scripts plus nogle få biblioteksmoduler. Overfladisk set kan det virke, som om notebooks kan erstatte scriptene og dermed levere dokumentation.

En god dokumentation skal imidlertid dokumentere helheden, ikke blot enkelte dele. Den skal binde flere scripts og kode fra biblioteksmodulerne sammen. Beregningsmetoder implementeres sædvanligvis i biblioteksmodulerne, mens scriptene anvender dem på datasæt.

Hvis dokumentationen udføres script for script, hvordan dokumenterer man så metoderne? I dag findes der masser af publicerede Jupyter notebooks; hvordan håndterer de så dette?

Jeg har naturligvis ikke kigget på dem alle, men hidtil er mit indtryk, at der er to tilfælde. Det hyppigste tilfælde er notebooks, der dokumenterer dataanalyser baseret på standard, velkendte metoder implementeret i velkendte biblioteker. Læsere af notebook’en forventes at være fortrolige med metoderne eller at lære om dem andre steder. Det andet tilfælde er notebooks, der inkluderer selve implementeringen af metoden.

Relateret: DataCamp — Interaktive Python- og datavidenskabskurser koder du direkte i browseren.

Udover at være begrænset til simple metoder, har denne tilgang den store ulempe, at metodeimplementeringen ikke er genanvendelig. Da min egen forskning primært fokuserer på at udvikle og evaluere nye beregningsmetoder, konkluderede jeg, at notebooks ikke er velegnede til mit arbejde.

Faktisk var jeg nået frem til samme konklusion gennem praktisk erfaring. Hver gang jeg startede et nyt projekt som en notebook, skiftede jeg hurtigt tilbage til moduler og scripts af den gamle type med dokumentation i separate tekstfiler. Jeg fandt denne teknik fuldt ud tilstrækkelig til personlig brug, men en bunke filer – selv velorganiserede – gør det ikke fristende for en anden forsker, endda en samarbejdspartner, at dykke ned i materialet. Da jeg for nogle måneder siden begyndte at kigge nærmere på Pharo, stort set ved et tilfælde (jeg tilmeldte mig Pharo MOOC for at få lidt MOOC-erfaring fra lærerens perspektiv, før jeg skulle indtage rollen som underviser i MOOC’en om Reproducerbar Forskning ), opdagede jeg en helt anden slags interaktivt beregningsmiljø.

Smalltalk-familien, hvoraf Pharo er et af de yngre medlemmer, har en lang historie med at værdsætte udforskbarhed og forståelighed (se dette blogindlæg for flere detaljer). Derefter opdagede jeg hurtigt Glamorous Toolkit , et nyt interaktivt miljø bygget oven på Pharo, der sigter mod et endnu højere niveau af udforskbarhed gennem formbare udviklingsværktøjer. Ideen er, at udviklere bør kunne udvide miljøet med domænespecifikke inspektionsværktøjer.

Læsernes favorit: Dataquest — Projektbaserede datavidenskabelige stier med en guidet terminal og rigtige datasæt.

Den intellektuelle baggrund for disse idéer er pænt opsummeret i et blogindlæg af Rafael Luque. Sammenlignet med nuværende og fremtidige miljøer i Pharo-universet føles beregningsnotebooks meget begrænsede og hæmmende. Hvilket ikke er overraskende, når man betænker deres oprindelse.

Dagens Jupyter og RMarkdown er mindre variationer over notebook-idéen, der blev introduceret i begyndelsen af 1980’erne af Mathematica . Mathematica byggede ligesom de fleste andre computer-algebra-systemer videre på arven fra Lisp, som i 1950’erne introducerede mange revolutionerende funktioner inden for databehandling, heriblandt interaktivitet via Read-Eval-Print Loop (REPL).

Dette var en naturlig måde at implementere interaktion på inden for rammerne af datidens brugergrænsefladehardware: et linjeorienteret terminal. Smalltalk derimod startede allerede i 1970’erne med grafiske skærme og pegeenheder lige fra begyndelsen, dog til prisen af at være afhængig af hardware, som meget få mennesker havde adgang til på det tidspunkt. Som Marshall McLuhan lærte os: Før former vi vores værktøjer, og derefter former vores værktøjer os. De linjeorienterede terminaler fra 1950’erne har præget en tænkmåde hos computerbrugere, som selv dagens beregningsnotebooks har beholdt, på trods af at overlegne tilgange har eksisteret i årtier.

Og denne overlegne teknologi er ikke blot Smalltalk, som altid har været et nichesystem. Ikke-lineære GUI’er er det, vi alle bruger til at arbejde med billeder eller lydfiler.

Disse opgaver er næsten umulige at udføre linje for linje, så de fandt reelt ikke sted før GUI’ernes komme. Til beregninger kom GUI’er sandsynligvis for sent: lineær tænkning var allerede blevet en kulturel norm. Pharo-udgaven af ActivePapers sigter mod at forme GToolkit-miljøet til et miljø for computerstøttet forskning snarere end softwareudvikling. Disse to aktiviteter er forskellige, men deler mange fælles træk.

Den væsentligste forskel er, at videnskab fokuserer på data og modeller, hvor software kun er et middel til et mål. Det er dog et så vigtigt middel, at alt andet struktureres omkring det. Desuden beskæftiger softwareudvikling sig også med data (om software) og modeller (som specifikationer).

Relateret: O'Reilly Learning Platform — Et dybt teknisk bibliotek med videnskabelige bøger, videoer og livetræning.

I sidste ende er forskellene gradvise snarere end fundamentale. Denne rejse er lige begyndt, og jeg ved ikke rigtig, hvor den vil føre hen. Hold øje med opdateringer!

I mellemtiden kan du se denne demo-video . kommentarer drevet af Disqus