ActivePapers Pharo -versio

Python-versio JVM-versio Pharo-versio Blogi … kirjasto —> ActivePapersin Pharo-versio, kirjoittanut Konrad Hinsen, julkaistu 10. toukokuuta 2019 ActivePapers-perheeseen on liittynyt uusi jäsen: ActivePaperin Pharo-versio. Toisin kuin Python- ja JVM-versiot, jotka toteuttavat pääosin samoja ideoita ja käsitteitä kahdella eri alustalla, Pharo-versio seuraa erilaista tavoitetta: tutkia ihmisen ja tietokoneen välistä käyttöliittymää toistettavassa, ymmärrettävässä ja varmennettavassa tietokoneavusteisessa tutkimuksessa.

Yksi yleisimmistä kysymyksistä, joita olen saanut ActivePapersin Python-versiosta, oli: “Toimiiko tämä Jupyter-notebookien kanssa?” Alun perin vastaukseni oli: “Ei vielä, mutta työskentelen asian parissa.” Ja niin teinkin. Tämä työ ei kuitenkaan koskaan johtanut tyydyttävään lopputulokseen. Yenä syynä olivat tekniset esteet. Yritin sisällyttää Jupyter-notebookeja ActivePaperiin, mutta se osoittautui mahdottomaksi, koska Jupyterin kahden prosessin arkkitehtuuri (ydin ja notebook-editori ovat erillisiä prosesseja, jotka on yhdistetty viestintäprotokollalla) ei ollut yhteensopiva HDF5-kirjaston rajoituksen kanssa, jonka mukaan vain yksi prosessi voi kirjoittaa tiedostoon kerrallaan.

Tämä tarkoittaa, että et voi tallentaa notebookia ja sen laskemia tuloksia samaan HDF5-tiedostoon. Mitä enemmän kuitenkin pohdin ActivePapersin ja Jupyterin integroimista, sitä enemmän ymmärsin, että niiden lineaariset notebookit (koodin, dokumentaation ja tulosolujen muodostama sarja) eivät todellakaan sovellu tieteellisen laskennan dokumentointiin, lukuun ottamatta yksinkertaisia tapauksia. Jos tarkastelee erilaisia julkaistuja ActivePapereita, ne sisältävät invariably useita skriptejä sekä muutaman kirjastomoduulin.

Pintapuolisesti voi vaikuttaa siltä, että notebookit voivat korvata skriptit ja tarjota samalla dokumentaation. Hyvän dokumentaation on kuitenkin dokumentoitava kokonaisuus, ei vain osia siitä. Sen on sidottava yhteen useita skriptejä ja kirjastomoduuleista peräisin olevaa koodia.

Yleensä laskennalliset menetelmät on toteutettu kirjastomoduuleihin, ja skriptit soveltavat niitä aineistoihin. Jos dokumentaatio tehdään skripti kerrallaan, miten menetelmät dokumentoidaan?

Nykyään julkaistuja Jupyter-notebookeja on runsaasti, joten miten ne käsittelevät tämän ongelman? En tietenkään tarkastellut kaikkia niitä, mutta tähän mennessä vaikutelmani on, että tilanteita on kaksi. Yleisin tapaus on notebookit, jotka dokumentoivat data-analyysejä, jotka perustuvat vakiintuneisiin, tunnettuihin menetelmiin ja tunnetuissa kirjastoissa toteutettuihin ratkaisuihin. Notebookin lukijoiden odotetaan tuntevan nämä menetelmät tai oppivan niistä muualta.

Aiheeseen liittyvä: DataCamp — Interaktiiviset Python- ja datatieteen kurssit, jotka koodaat suoraan selaimessa.

Toinen tapaus on notebookit, jotka sisältävät koko menetelmän toteutuksen. Sen lisäksi, että tämä lähestymistapa rajoittuu yksinkertaisiin menetelmiin, sillä on suuri haittapuoli: menetelmän toteutus ei ole uudelleenkäytettävissä.

Koska oma tutkimukseni keskittyy pääasiassa uusien laskennallisten menetelmien kehittämiseen ja arviointiin, päätin, että notebookit eivät sovellu työhöni. Itse asiassa olin päätynyt samaan johtopäätökseen kokeilemalla. Aina kun aloitin uuden projektin notebookina, siirryin nopeasti takaisin vanhan tyylisiin moduuleihin ja skripteihin, joiden dokumentaatio oli erillisissä tekstitiedostoissa. Pidän tätä täysin riittävänä tekniikkana omaan henkilökohtaiseen käyttööni, mutta tiedostojen kokoelma, vaikka kuinka hyvin järjestetty, ei innosta toista tutkijaa – edes yhteistyökumppania – perehtymään siihen syvällisesti.

Kun aloitin muutama kuukausi sitten Pharon tarkastelun, suurelta osin sattumalta (ilmoittauduin Pharo MOOC -kurssille saadakseni MOOC-kokemusta oppijan näkökulmasta ennen kuin ryhdyin opettajaksi Toistettava tutkimus -MOOC-kurssilla), löysin hyvin erilaisen interaktiivisen laskentaympäristön. Smalltalk-perheellä, jonka nuorempi jäsen Pharo on, on pitkä historia, jossa korostetaan tutkittavuutta ja ymmärrettävyyttä (katso tämä blogikirjoitus lisätietoja varten). Löysin nopeasti myös Glamorous Toolkitin, uuden interaktiivisen ympäristön, joka rakentuu Pharon päälle ja pyrkii entistä korkeampaan tutkittavuustasoon muokattavien kehitystyökalujen avulla.

Lukijan suosikki: Dataquest — Projektipohjaiset tietotieteen polut ohjatulla päätteellä ja todellisilla tietojoukoilla.

Ideana on, että kehittäjät voivat laajentaa ympäristöä toimialakohtaisilla tarkastelutyökaluilla. Näiden ideoiden älyllistä taustaa on tiivistetty hienosti Rafael Luquen blogikirjoituksessa. Verrattuna Pharo-universumin nykyisiin ja tuleviin ympäristöihin laskennalliset notebookit tuntuvat hyvin rajoitetuilta ja ahdistavilta.

Mikä ei ole erityisen yllättävää ottaen huomioon niiden alkuperän. Nykyiset Jupyter ja RMarkdown ovat vain pieniä variaatioita notebook-ideasta, jonka Mathematica esitteli 1980-luvun alussa.

Mathematica puolestaan, kuten useimmat muut tietokonealgebrjärjestelmät, rakentui Lispin perinnölle, joka toi 1950-luvulla laskentaan monia vallankumouksellisia ominaisuuksia, joista yksi oli interaktiivisuus Read-Eval-Print Loop (REPL) -mekanismin kautta. Tämä oli luonteva tapa toteuttaa vuorovaikutus aikakauden käyttöliittymälaitteiston rajoitteissa: rivisuuntautuneessa päätelaitteessa. Smalltalk sen sijaan aloitti 1970-luvulla graafisilla näytöillä ja osoitinlaitteilla alusta alkaen, vaikka hintana oli riippuvuus laitteistosta, johon harvoilla oli tuolloin pääsy.

Kuten Marshall McLuhan opetti meille: ensin me muokkaamme työkalujamme, ja sitten työkalumme muokkaavat meitä. 1950-luvun rivisuuntautuneet päätelaitteet ovat jättäneet jälkensä tietokoneen käyttäjien ajattelutapaan, jonka jopa nykypäivän laskennalliset notebookit ovat säilyttäneet huolimatta siitä, että parempia lähestymistapoja on ollut saatavilla vuosikymmeniä.

Tämä ylivoimainen teknologia ei ole pelkästään Smalltalk, joka on aina pysynyt markkinarakona. Epälineaariset graafiset käyttöliittymät ovat jotain, mitä me kaikki käytämme kuvatiedostojen tai äänitiedostojen käsittelyyn. Nämä tehtävät ovat lähes mahdottomia tehdä rivi riviltä -menetelmällä, joten niitä ei oikeastaan voitu tehdä ennen graafisia käyttöliittymiä. Laskennan osalta graafiset käyttöliittymät tulivat todennäköisesti liian myöhään: lineaarinen ajattelu oli jo vakiintunut kulttuuriseksi normiksi.

ActivePapersin Pharo-versio pyrkii muokkaamaan GToolkit-ympäristöstä ympäristön tietokoneavusteista tutkimusta varten eikä niinkään ohjelmistokehitystä varten. Nämä kaksi toimintaa ovat erillisiä, mutta niillä on paljon yhteisiä piirteitä. Tärkein ero on se, että tiede keskittyy dataan ja malleihin, ja ohjelmisto on vain keino päämäärän saavuttamiseksi.

Aiheeseen liittyvä: O'Reilly Learning Platform — Syvä tekninen kirjasto tieteellisten laskennan kirjoja, videoita ja live-koulutuksia.

Se on kuitenkin niin tärkeä keino, että kaikki muu rakentuu sen ympärille. Lisäksi ohjelmistokehitys käsittelee myös dataa (ohjelmistoa koskevaa dataa) ja malleja (eritelminä). Lopulta erot ovat asteittaisia eivätkä perustavanlaatuisia.

Tämä matka on vasta alkanut, enkä todellakaan tiedä, mihin se johtaa. Pysy kuulolla päivitysten varalta! Sillä välin voit katsoa tämän demonstration videon. kommentit, voimanlähteenä Disqus