L'edizione ActivePapers per Pharo

Edizione Python Edizione JVM Edizione Pharo Blog … libreria —> L’edizione Pharo di ActivePapers di Konrad Hinsen, pubblicata il 10 maggio 2019 La famiglia ActivePapers ha un nuovo membro: l’edizione Pharo di ActivePaper . A differenza delle edizioni Python e JVM, che implementano prevalentemente le stesse idee e concetti su due piattaforme diverse, l’edizione Pharo persegue un obiettivo differente: esplorare l’interfaccia uomo-computer per una ricerca assistita dal calcolatore che sia riproducibile, comprensibile e verificabile.

Una delle domande più frequenti che ho ricevuto riguardo all’edizione Python di ActivePapers è stata: “Funziona con i notebook di Jupyter?” Inizialmente la mia risposta era: “Non ancora, ma ci sto lavorando.” E così ho fatto. Tuttavia, quel lavoro non ha mai portato a un risultato soddisfacente. Una ragione riguardava ostacoli tecnici. Avevo provato a includere i notebook di Jupyter all’interno di un ActivePaper, ma si è rivelato impossibile perché l’architettura a due processi di Jupyter (il kernel e l’editor del notebook sono processi separati collegati da un protocollo di comunicazione) non era compatibile con la restrizione della libreria HDF5, che consente a un solo processo alla volta di scrivere su un file.

Questo significa che non è possibile archiviare un notebook e i risultati da esso calcolati nello stesso file HDF5. Tuttavia, più riflettevo sull’integrazione tra ActivePapers e Jupyter, più mi rendevo conto che i loro notebook lineari (una sequenza di celle di codice, documentazione e risultati) non sono realmente adatti al compito di documentare un calcolo scientifico, se non in casi semplici. Se si osservano i vari ActivePapers pubblicati, essi contengono invariabilmente più script oltre ad alcuni moduli libreria.

Superficialmente, potrebbe sembrare che i notebook possano sostituire gli script fornendo al contempo documentazione. Tuttavia, una buona documentazione deve descrivere l’insieme, non alcune sue parti. Deve tenere insieme più script e codice proveniente dai moduli libreria.

Di solito i metodi computazionali sono implementati nei moduli libreria, mentre gli script li applicano ai dataset. Se la documentazione viene fatta script per script, come si documentano i metodi?

Oggi esistono numerosi notebook Jupyter pubblicati; come gestiscono questo aspetto? Non li ho esaminati tutti, ovviamente, ma finora la mia impressione è che vi siano due casi. Il caso più frequente riguarda notebook che documentano analisi dati basate su metodi standard ben noti, implementati in librerie altrettanto note. Ci si aspetta che i lettori del notebook conoscano già tali metodi o che li apprendano altrove.

Correlato: Dataquest — Percorsi di data science a progetto con terminale guidato e dataset reali.

L’altro caso concerne notebook che includono l’implementazione completa del metodo. Oltre a essere limitato a metodi semplici, questo approccio presenta il grande svantaggio che l’implementazione del metodo non è riutilizzabile.

Poiché la mia ricerca si concentra principalmente sullo sviluppo e sulla valutazione di nuovi metodi computazionali, ho concluso che i notebook non sono adatti al mio lavoro. Anzi, ero giunto alla stessa conclusione proprio attraverso la pratica. Ogni volta che avviavo un nuovo progetto come notebook, passavo rapidamente a moduli e script in stile tradizionale, con la documentazione in file di testo separati. Ho trovato questa tecnica perfettamente adeguata per il mio uso personale, ma un insieme di file, per quanto ben organizzati, non costituisce qualcosa in cui un altro scienziato, persino un collaboratore, abbia voglia di addentrarsi.

Quando ho iniziato a esplorare Pharo alcuni mesi fa, quasi per caso (mi sono iscritto al MOOC su Pharo per acquisire esperienza dal punto di vista dello studente, prima di assumere il ruolo di istruttore nel MOOC sulla Ricerca Riproducibile ), ho scoperto un tipo di ambiente di calcolo interattivo molto diverso. La famiglia Smalltalk, di cui Pharo è uno dei membri più giovani, vanta una lunga storia di valorizzazione dell’esplorabilità e della comprensibilità (vedi questo post del blog per maggiori dettagli).

Vale la pena dare un'occhiata: Coursera Plus — Un abbonamento per certificati Python e di scienza dei dati supportati dall'università.

Successivamente ho scoperto rapidamente il Glamorous Toolkit , un nuovo ambiente interattivo basato su Pharo che mira a un livello ancora superiore di esplorabilità tramite strumenti di sviluppo modellabili; l’idea è che gli sviluppatori dovrebbero poter estendere l’ambiente con strumenti di ispezione specifici per il dominio. Il background intellettuale di queste idee è stato sintetizzato efficacemente in un post del blog di Rafael Luque. Rispetto agli ambienti attuali e futuri dell’universo Pharo, i notebook computazionali appaiono molto limitati e vincolanti.

Il che non è sorprendente, considerando le loro origini. Gli attuali Jupyter e RMarkdown sono varianti minori dell’idea di notebook introdotta nei primi anni ‘80 da Mathematica .

Mathematica a sua volta, come la maggior parte degli altri sistemi di algebra computazionale, si fondava sull’eredità di Lisp, che negli anni ‘50 introdusse molte funzionalità rivoluzionarie nell’informatica, tra cui l’interattività tramite il ciclo Read-Eval-Print (REPL), un modo naturale per implementare l’interazione entro i vincoli dell’hardware delle interfacce utente dell’epoca: un terminale orientato alle righe. Smalltalk, d’altra parte, nacque negli anni ‘70 con display grafici e dispositivi di puntamento fin dall’inizio, al prezzo di dipendere da hardware a cui allora pochissime persone avevano accesso.

Come ci ha insegnato Marshall McLuhan, prima noi diamo forma ai nostri strumenti e poi i nostri strumenti danno forma a noi. I terminali orientati alle righe degli anni ‘50 hanno impresso negli utenti informatici un modo di pensare che anche i notebook computazionali odierni hanno conservato, nonostante approcci superiori esistano da decenni.

E quella tecnologia superiore non è soltanto Smalltalk, che è sempre rimasto un sistema di nicchia. Le interfacce grafiche non lineari sono ciò che tutti utilizziamo per lavorare con immagini o file audio. Quei compiti sono quasi impossibili da eseguire riga per riga, quindi non si realizzavano realmente prima delle GUI. Per i calcoli, le GUI sono probabilmente arrivate troppo tardi: il pensiero lineare era già diventato una norma culturale.

L’edizione Pharo di ActivePapers mira a plasmare l’ambiente GToolkit in un ambiente dedicato alla ricerca assistita dal calcolatore, piuttosto che allo sviluppo software. Queste due attività sono distinte ma condividono molte caratteristiche comuni. La differenza principale è che la scienza si concentra sui dati e sui modelli, essendo il software solo un mezzo per raggiungere un fine.

Correlato: O'Reilly Learning Platform — Una ricca biblioteca tecnica di libri, video e corsi di informatica scientifica.

Tuttavia, è un mezzo così importante che tutto il resto è strutturato attorno ad esso. Inoltre, anche lo sviluppo software tratta dati (riguardo al software) e modelli (come specifiche). Alla fine, le differenze sono graduali piuttosto che fondamentali.

Questo viaggio è appena iniziato e non so davvero dove porterà. Restate sintonizzati per gli aggiornamenti! Nel frattempo, potete guardare questo video dimostrativo . commenti offerti da Disqus