De ActivePapers Pharo-editie

Python-editie JVM-editie Pharo-editie Blog … bibliotheek —> De ActivePapers Pharo-editie door Konrad Hinsen, geplaatst op 10 mei 2019 De ActivePapers-familie heeft een nieuw lid: de ActivePaper Pharo-editie. In tegenstelling tot de Python- en JVM-editie, die grotendeels dezelfde ideeën en concepten op twee verschillende platformen implementeren, streeft de Pharo-editie een ander doel na: het verkennen van de mens-computerinterface voor reproduceerbaar, begrijpelijk en verifiebaar computerondersteund onderzoek.

Een van de vragen die ik het vaakst kreeg over de Python-editie van ActivePapers was: “Werkt dit met Jupyter-notebooks?” Aanvankelijk was mijn antwoord: “Nog niet, maar ik werk eraan.” En dat heb ik ook gedaan. Dat werk leidde echter nooit tot een bevredigend resultaat. Een reden daarvoor waren technische obstakels. Ik had geprobeerd Jupyter-notebooks in een ActivePaper op te nemen, maar dat bleek onmogelijk omdat het twee-procesontwerp van Jupyter (de kernel en de notebook-editor zijn aparte processen die via een communicatieprotocol met elkaar verbonden zijn) niet compatibel was met de beperking van de HDF5-bibliotheek dat slechts één proces tegelijkertijd naar een bestand kan schrijven.

Dat betekent dat je een notebook en de daarmee berekende resultaten niet in hetzelfde HDF5-bestand kunt opslaan. Hoe meer ik echter nadacht over het integreren van ActivePapers en Jupyter, hoe meer ik me realiseerde dat lineaire notebooks (een opeenvolging van code-, documentatie- en resultatencellen) niet echt geschikt zijn voor het documenteren van een wetenschappelijke berekening, behalve in eenvoudige gevallen. Als je kijkt naar de diverse gepubliceerde ActivePapers, bevatten deze steevast meerdere scripts plus enkele bibliothecaire modules.

Oppervlakkig gezien lijkt het alsof notebooks de scripts kunnen vervangen en zodoende documentatie kunnen bieden. Goede documentatie moet echter het geheel documenteren, niet slechts enkele onderdelen ervan. Ze moet meerdere scripts en code uit de bibliothecaire modules aan elkaar koppelen.

Gewoonlijk worden rekenmethoden geïmplementeerd in de bibliothecaire modules, en passen de scripts deze toe op datasets. Als de documentatie script per script gebeurt, hoe documenteer je dan de methoden?

Tegenwoordig zijn er talloze gepubliceerde Jupyter-notebooks; hoe gaan zij hiermee om? Ik heb ze natuurlijk niet allemaal bekeken, maar tot nu toe is mijn indruk dat er twee gevallen zijn. Het meest voorkomende geval zijn notebooks die data-analyses documenteren op basis van standaard, welbekende methoden die zijn geïmplementeerd in bekende bibliotheken. Van lezers van de notebook wordt verwacht dat ze vertrouwd zijn met de methoden, of dat ze er elders over leren.

Gerelateerd: Dataquest — Projectgebaseerde datawetenschapspaden met een begeleide terminal en echte datasets.

Het andere geval zijn notebooks die de volledige implementatie van de methode bevatten. Afgezien van het feit dat dit beperkt blijft tot eenvoudige methoden, heeft deze aanpak het grote nadeel dat de implementatie van de methode niet herbruikbaar is.

Omdat mijn eigen onderzoek zich voornamelijk richt op het ontwikkelen en evalueren van nieuwe rekenmethoden, concludeerde ik dat notebooks niet goed bij mijn werk passen. Sterker nog, ik was al tot diezelfde conclusie gekomen door het gewoon te proberen. Zodra ik een nieuw project als notebook begon, schakelde ik snel over op modules en scripts in de oude stijl, met documentatie in aparte tekstbestanden. Ik vond dit een prima techniek voor persoonlijk gebruik, maar een verzameling bestanden, hoe goed georganiseerd ook, nodigt een andere wetenschapper, zelfs een samenwerker, niet uit om erin te duiken.

Toen ik een paar maanden geleden, min of meer per ongeluk, Pharo begon te bekijken (ik schreef me in voor de Pharo-MOOC om wat MOOC-ervaring op te doen vanuit het perspectief van de lerende, voordat ik de rol van instructeur op me nam in de Reproducible Research-MOOC), ontdekte ik een heel ander soort interactieve rekenomgeving. De Smalltalk-familie, waarvan Pharo een van de jongere leden is, heeft een lange geschiedenis van waardering voor exploreerbaarheid en begrijpelijkheid (zie deze blogpost voor meer details).

Een kijkje waard: Coursera Plus — Eén abonnement voor door de universiteit ondersteunde Python- en data-science-certificaten.

Vervolgens ontdekte ik snel de Glamorous Toolkit, een nieuwe interactieve omgeving die voortbouwt op Pharo en streeft naar een nog hoger niveau van exploreerbaarheid door middel van vormbare ontwikkelingstools. Het idee hierachter is dat ontwikkelaars de omgeving moeten kunnen uitbreiden met domeinspecifieke inspectietools. De intellectuele achtergrond van deze ideeën is mooi samengevat in een blogpost door Rafael Luque.

Vergeleken met de huidige en toekomstige omgevingen binnen het Pharo-universum voelen computationele notebooks zeer beperkt en beklemmend aan. Dat is niet echt verrassend gezien hun oorsprong.

Het huidige Jupyter en RMarkdown zijn kleine variaties op het notebook-idee dat begin jaren tachtig werd geïntroduceerd door Mathematica. Mathematica bouwde op zijn beurt, net als de meeste andere computeralgebrasystemen, voort op het erfgoed van Lisp, dat in de jaren vijftig veel revolutionaire functies in de informatica introduceerde, waaronder interactiviteit via de Read-Eval-Print Loop (REPL). Dit was een natuurlijke manier om interactie te implementeren binnen de beperkingen van de userinterface-hardware van die tijd: een regelgeoriënteerde terminal.

Smalltalk daarentegen begon in de jaren zeventig direct met grafische schermen en aanwijsapparaten, ten koste van afhankelijkheid van hardware waar destijds maar weinig mensen toegang toe hadden. Zoals Marshall McLuhan ons leerde: eerst vormen wij onze gereedschappen, daarna vormen onze gereedschappen ons.

De regelgeoriënteerde terminals van de jaren vijftig hebben een denkwijze bij computergebruikers ingeprent die zelfs de computationele notebooks van vandaag nog steeds hanteren, ondanks het feit dat er al decennia lang superieure benaderingen bestaan. En die superieure technologie is niet alleen Smalltalk, dat altijd een nichesysteem is gebleven. Niet-lineaire GUI’s gebruiken we allemaal voor het werken met afbeeldingen of geluidsbestanden. Die taken zijn bijna onmogelijk regel voor regel uit te voeren, dus ze kwamen pas echt van de grond na de komst van GUI’s.

Voor berekeningen kwamen GUI’s waarschijnlijk te laat: lineair denken was al een culturele norm geworden. De Pharo-editie van ActivePapers streeft ernaar de GToolkit-omgeving vorm te geven tot een omgeving voor computerondersteund onderzoek, in plaats van voor softwareontwikkeling. Deze twee activiteiten zijn verschillend maar delen veel gemeenschappelijke kenmerken.

Gerelateerd: O'Reilly Learning Platform — Een diepgaande technische bibliotheek met wetenschappelijke computerboeken, video's en live training.

Het belangrijkste verschil is dat wetenschap zich richt op data en modellen, waarbij software slechts een middel is om een doel te bereiken. Het is echter zo’n belangrijk middel dat alles eromheen is gestructureerd. Bovendien houdt softwareontwikkeling zich ook bezig met data (over software) en modellen (als specificaties).

Uiteindelijk zijn de verschillen geleidelijk rather dan fundamenteel. Deze reis is net begonnen, en ik weet niet echt waar hij naartoe zal leiden. Blijf op de hoogte voor updates!

In de tussentijd kun je deze demovideo bekijken. comments powered by Disqus