ActivePapers Pharo-utgaven

I motsetning til Python- og JVM-utgavene, som i hovedsak implementerer de samme ideene og konseptene på to ulike plattformer, forfølger Pharo-utgaven et annet mål: å utforske grensesnittet mellom menneske og datamaskin for reproduserbar, forståelig og verifiserbar datastøttet forskning. Ett av de hyppigste spørsmålene jeg har fått om Python-utgaven av ActivePapers, var: «Fungerer dette med Jupyter-notatbøker?» Innledningsvis var svaret mitt: «Ikke ennå, men jeg jobber med det.» Og det gjorde jeg.

Likevel førte aldri dette arbeidet til et tilfredsstillende resultat. Én årsak var tekniske hindre. Jeg hadde prøvd å inkludere Jupyter-notatbøker inne i en ActivePaper, men det viste seg å være umulig fordi Jupyters to-prosess-design (kjernen og notatbok-redigereren er separate prosesser koblet sammen via en kommunikasjonsprotokoll) ikke var kompatibelt med HDF5-bibliotekets begrensning om at bare én prosess kan skrive til en fil om gangen. Det betyr at du ikke kan lagre både en notatbok og resultatene den beregner i samme HDF5-fil.

Men jo mer jeg tenkte på å integrere ActivePapers og Jupyter, desto klarere innså jeg at deres lineære notatbøker (en sekvens av kode-, dokumentasjons- og resultatceller) egentlig ikke er egnet for oppgaven med å dokumentere en vitenskapelig beregning, bortsett fra i enkle tilfeller. Ser man på de ulike publiserte ActivePapers-ne, inneholder de uten unntak flere skript samt noen få bibliotekmoduler. Overflatisk sett kan det virke som om notatbøker kan erstatte skriptene og dermed tilby dokumentasjon.

En god dokumentasjon må imidlertid dokumentere helheten, ikke enkelte deler av den. Den må binde sammen flere skript og kode fra bibliotekmodulene. Vanligvis implementeres beregningsmetoder i bibliotekmodulene, mens skriptene anvender dem på datasett.

Hvis dokumentasjonen gjøres skript for skript, hvordan dokumenterer man da metodene? I dag finnes det mange publiserte Jupyter-notatbøker; hvordan håndterer de dette?

Jeg har selvsagt ikke sett på alle sammen, men så langt er mitt inntrykk at det finnes to tilfeller. Det hyppigste tilfellet er notatbøker som dokumenterer dataanalyser basert på standardiserte, velkjente metoder implementert i kjente biblioteker. Leserne av notatboken forventes å være kjent med metodene, eller å lære om dem andre steder. Det andre tilfellet er notatbøker som inkluderer hele metodeimplementeringen.

Relatert: DataCamp — Interaktive Python- og datavitenskap-kurs koder du direkte i nettleseren.

I tillegg til å være begrenset til enkle metoder, har denne tilnærmingen den store ulempen at metodeimplementeringen ikke er gjenbrukbar. Siden min egen forskning hovedsakelig fokuserer på utvikling og evaluering av nye beregningsmetoder, konkluderte jeg med at notatbøker ikke passer godt til mitt arbeid.

Faktisk hadde jeg kommet til samme konklusjon allerede gjennom forsøk. Hver gang jeg startet et nytt prosjekt som en notatbok, byttet jeg raskt tilbake til gammelstil-moduler og skript, med dokumentasjon i separate tekstfiler. Jeg fant dette til å være en helt grei teknikk for personlig bruk, men en samling filer – selv godt organisert – gjør ikke inntrykket av noe en annen forsker, selv en samarbeidspartner, ivrer etter å dykke ned i. Da jeg for noen måneder siden begynte å se nærmere på Pharo, stort sett ved en tilfeldighet (jeg meldte meg på Pharo MOOC for å få litt MOOC-erfaring fra learnerens perspektiv, før jeg tok på meg rollen som instruktør i Reproducible Research MOOC ), oppdaget jeg en helt annen type interaktivt databehandlingsmiljø.

Smalltalk-familien, hvorav Pharo er ett av de yngre medlemmene, har en lang historie med å verdsette utforskbarhet og forståelighet (se dette blogginnlegget for flere detaljer). Deretter oppdaget jeg raskt Glamorous Toolkit , et nytt interaktivt miljø bygget på Pharo som sikter mot et enda høyere nivå av utforskbarhet gjennom formbare utviklingsverktøy. Ideen er at utviklere skal kunne utvide miljøet med domenespesifikke inspeksjonsverktøy.

Leserfavoritt: Dataquest — Prosjektbaserte datavitenskapelige stier med en guidet terminal og ekte datasett.

Den intellektuelle bakgrunnen for disse ideene er fint oppsummert i et blogginnlegg av Rafael Luque. Sammenlignet med nåværende og fremtidige miljøer i Pharo-universet, føles beregningsnotatbøker svært begrensede og hemmende. Hvilket egentlig ikke er overraskende tatt deres opprinnelse i betraktning.

Dagens Jupyter og RMarkdown er mindre variasjoner over notatbok-ideen som ble introdusert tidlig på 1980-tallet av Mathematica . Mathematica bygde igjen, slik de fleste andre computer algebra-systemer, på arven fra Lisp, som på 1950-tallet introduserte mange revolusjonerende funksjoner innen databehandling, blant annet interaktivitet via Read-Eval-Print Loop (REPL).

Dette var en naturlig måte å implementere interaksjon innenfor begrensningene i brukerinterface-maskinvaren på den tiden: et linjeorientert terminal. Smalltalk derimot, startet på 1970-tallet med grafiske skjermer og pekeenheter helt fra begynnelsen, til prisen av å være avhengig av maskinvare som svært få mennesker hadde tilgang til på den tiden. Som Marshall McLuhan lærte oss: først former vi våre verktøy, og deretter former våre verktøy oss. De linjeorienterte terminalene fra 1950-tallet har preget en tenkemåte hos databrukere som selv dagens beregningsnotatbøker har beholdt, til tross for at overlegne tilnærminger har eksistert i tiår.

Og denne overlegne teknologien er ikke bare Smalltalk, som alltid har vært et nisjesystem. Ikke-lineære GUI-er er det vi alle bruker når vi arbeider med bilde- eller lydfiler.

Disse oppgavene er nesten umulige å gjøre linje for linje, så de skjedde egentlig ikke før GUI-er kom til. For beregninger kom GUI-er sannsynligvis for sent: lineær tenkning hadde allerede blitt en kulturell norm. Pharo-utgaven av ActivePapers har som mål å forme GToolkit-miljøet til et miljø for datastøttet forskning, snarere enn programvareutvikling. Disse to aktivitetene er distinkte, men deler mange felles trekk.

Hovedforskjellen er at vitenskap fokuserer på data og modeller, hvor programvare kun er et middel til et mål. Likevel er det et så viktig middel at alt annet struktureres rundt det. Dessuten handler også programvareutvikling om data (om programvare) og modeller (som spesifikasjoner).

Relatert: O'Reilly Learning Platform — Et dypt teknisk bibliotek med vitenskapelige databøker, videoer og live-trening.

Til syvende og sist er forskjellene gradvise heller enn fundamentale. Denne reisen har så vidt begynt, og jeg vet egentlig ikke hvor den vil ende. Følg med for oppdateringer!

I mellomtiden kan du se denne demo-videoen . kommentarer drevet av Disqus