ActivePapers Pharo-utgåvan
Python-utgåva JVM-utgåva Pharo-utgåva Blogg … bibliotek —> ActivePapers Pharo-utgåva av Konrad Hinsen, publicerad den 10 maj 2019 ActivePapers-familjen har fått en ny medlem: ActivePaper Pharo-utgåvan. Till skillnad från Python- och JVM-utgåvorna, som i huvudsak implementerar samma idéer och koncept på två olika plattformar, förföljer Pharo-utgåvan ett annat mål: att utforska gränssnittet mellan människa och dator för reproducerbar, begriplig och verifierbar datorstödd forskning.
En av de vanligaste frågorna jag fick om Python-utgåvan av ActivePapers var: “Fungerar detta med Jupyter notebooks?” Ursprungligen var mitt svar “Inte än, men jag arbetar på det.” Och det gjorde jag. Det arbetet ledde dock aldrig till ett tillfredsställande resultat. En anledning var tekniska hinder. Jag hade försökt inkludera Jupyter notebooks inuti en ActivePaper, men det visade sig vara omöjligt eftersom Jupyters design med två processer (kärnan och notebook-redigeraren är separata processer kopplade via ett kommunikationsprotokoll) inte var kompatibel med HDF5-bibliotekets begränsning att endast en process kan skriva till en fil vid varje givet tillfälle.
Det innebär att du inte kan lagra både en notebook och de resultat den beräknar i samma HDF5-fil. Ju mer jag funderade på att integrera ActivePapers och Jupyter, desto mer insåg jag dock att dess linjära notebooks (en sekvens av kod-, dokumentations- och resultatrutor) egentligen inte är anpassade för uppgiften att dokumentera en vetenskaplig beräkning, utom i enkla fall. Om man tittar på de olika publicerade ActivePapers innehåller de alltid flera skript plus några biblioteksmoduler.
Vid en första anblick kan det verka som att notebooks kan ersätta skripten och därmed tillhandahålla dokumentation. En god dokumentation måste dock dokumentera helheten, inte bara vissa delar. Den måste knyta samman flera skript och kod från biblioteksmodulerna.
Vanligtvis implementeras beräkningsmetoder i biblioteksmodulerna, och skripten tillämpar dem på datamängder. Om dokumentationen görs skript för skript, hur dokumenterar man då metoderna?
Idag finns det massor av publicerade Jupyter notebooks, så hur hanterar de detta? Jag har naturligtvis inte tittat på alla, men hittills är mitt intryck att det finns två fall. Det vanligaste fallet är notebooks som dokumenterar dataanalyser baserade på standardiserade, väletablerade metoder implementerade i välkända bibliotek. Läsarna av notebooken förväntas vara bekanta med metoderna, eller att de lär sig om dem någon annanstans.
Relaterat: — Projektbaserade datavetenskapliga vägar med en guidad terminal och riktiga datamängder.
Det andra fallet är notebooks som inkluderar hela metodimplementeringen. Förutom att vara begränsad till enkla metoder har detta tillvägagångssätt den stora nackdelen att metodimplementeringen inte går att återanvända.
Eftersom min egen forskning främst fokuserar på att utveckla och utvärdera nya beräkningsmetoder, drog jag slutsatsen att notebooks inte passar särskilt bra för mitt arbete. Faktum är att jag hade kommit fram till samma slutsats genom att prova. Varje gång jag startade ett nytt projekt som en notebook, bytte jag snabbt till moduler och skript av gammalt slag, med dokumentation i separata textfiler. Jag ansåg att detta var en helt tillräckligt bra teknik för mitt personliga bruk, men en samling filer, även välordnade, gör det inte lockande för en annan forskare, ens en samarbetspartner, att fördjupa sig i materialet.
När jag började titta närmare på Pharo för några månader sedan, till stor del av en slump (jag anmälde mig till Pharo MOOC för att få lite MOOC-erfarenhet från en lärandes perspektiv, innan jag tog rollen som instruktör i MOOC-kursen Reproducible Research), upptäckte jag en helt annan typ av interaktiv datormiljö. Smalltalk-familjen, där Pharo är en av de yngre medlemmarna, har en lång historia av att värdera utforskbarhet och begriplighet (se detta blogginlägg för fler detaljer). Sedan upptäckte jag snabbt Glamorous Toolkit, en ny interaktiv miljö byggd på Pharo som siktar på en ännu högre nivå av utforskbarhet genom formbara utvecklingsverktyg.
Värt att titta på: — En prenumeration för universitetsstödda Python- och datavetenskapliga certifikat.
Idén är att utvecklare ska kunna utöka miljön med domänspecifika inspiceringsverktyg. Den intellektuella bakgrunden till dessa idéer har sammanfattats på ett bra sätt i ett blogginlägg av Rafael Luque. Jämfört med nuvarande och framtida miljöer i Pharo-universumet känns beräkningsnotebooks mycket begränsade och hämmande.
Vilket egentligen inte är överraskande med tanke på deras ursprung. Dagens Jupyter och RMarkdown är mindre variationer av notebook-idén som introducerades i början av 1980-talet av Mathematica.
Mathematica i sin tur, liksom de flesta andra system för symbolisk matematik, byggde på arvet från Lisp, som på 1950-talet introducerade många revolutionerande funktioner inom datavetenskapen, bland annat interaktivitet via Read-Eval-Print Loop (REPL). Detta var ett naturligt sätt att implementera interaktion inom ramarna för den tidens användargränssnittshårdvara: en radorienterad terminal. Smalltalk å andra sidan startade på 1970-talet med grafiska skärmar och pekdon direkt från början, till priset av att vara beroende av hårdvara som vid den tiden väldigt få människor hade tillgång till.
Som Marshall McLuhan lärde oss: först formar vi våra verktyg, och sedan formar våra verktyg oss. De radorienterade terminalerna från 1950-talet har präglat ett tänkesätt hos datoranvändare som dagens beräkningsnotebooks fortfarande behållit, trots att överlägsna tillvägagångssätt funnits i decennier.
Och den överlägsna tekniken är inte bara Smalltalk, som alltid har förblivit ett nischsystem. Icke-linjära grafiska användargränssnitt (GUI) är vad vi alla använder för att arbeta med bild- eller ljudfiler. Dessa uppgifter är nästan omöjliga att utföra rad för rad, så de blev inte riktigt möjliga förrän GUI:n kom. För beräkningar kom GUI:n sannolikt för sent: det linjära tänkandet hade redan blivit en kulturell norm.
Pharo-utgåvan av ActivePapers syftar till att forma GToolkit-miljön till en miljö för datorstödd forskning, snarare än mjukvaruutveckling. Dessa två aktiviteter är distinkta men delar många gemensamma drag. Den största skillnaden är att vetenskapen fokuserar på data och modeller, där mjukvara endast är ett medel för att nå ett mål.
Det är dock ett så viktigt medel att allt annat struktureras runt det. Dessutom handlar även mjukvaruutveckling om data (om mjukvara) och modeller (som specifikationer). I slutändan är skillnaderna gradvisa snarare än fundamentala.
Denna resa har precis börjat, och jag vet inte riktigt vart den kommer att leda. Håll utkik efter uppdateringar! Under tiden kan du titta på denna demovideo. kommentarer drivs av Disqus
Lär dig Python genom att koda i din webbläsare
Interaktiva Python- och datavetenskapskurser kodar du direkt i webbläsaren