Manutenzione del software nella ricerca
Edizione Python Edizione JVM Blog … libreria —> Manutenzione del software nella ricerca di Konrad Hinsen, pubblicato il 26 febbraio 2014 La manutenzione del software è una delle difficoltà che gli sviluppatori di software scientifico affrontano regolarmente. Si tratta di un’attività importante, ma che può richiedere molto tempo ed è scarsamente premiata dagli attuali sistemi di valutazione.
Inoltre, se si gestisce un grande progetto software, ottenere finanziamenti per la manutenzione è solitamente difficile. Dato che la manutenzione del software è complessa e non intrinsecamente di interesse scientifico, dovremmo chiederci perché sia necessaria e se possiamo fare qualcosa per ridurne la necessità. Innanzitutto, cos’è la manutenzione del software? Il Merriam-Webster definisce il verbo “maintain” (mantenere) come mantenere (qualcosa) in buone condizioni effettuando riparazioni, correggendo problemi, ecc.
Questo ha senso per le apparecchiature tecniche che si deteriorano nel tempo a causa dell’usura meccanica, ecc. Il software non si deteriora, quindi la manutenzione deve significare qualcosa di diverso quando applicata al software. Non sono a conoscenza di alcuna definizione condivisa, quindi quella che propongo qui è la mia: La manutenzione del software consiste nel modificare il software per uno dei due seguenti motivi: Correggere i bug.
Mantenere il software utilizzabile in ambienti informatici in evoluzione. Alcuni aggiungerebbero a questo elenco anche i miglioramenti funzionali, ma questi non sono propriamente manutenzione in alcun senso, bensì miglioramenti. In particolare nel caso del software scientifico, dove nuove funzionalità spesso significano nuova scienza.
Primo punto: i bug. Come per qualsiasi software, vogliamo che i bug nel software scientifico vengano corretti per ottenere risultati migliori in futuro. Tuttavia, vogliamo anche conservare la versione buggata se uno studio scientifico pubblicato l’ha utilizzata.
Si tratta semplicemente di una questione di onestà e di preservazione del record scientifico: se c’è la possibilità che l’esito di uno studio sia stato influenzato da un bug nel software, chi esamina lo studio dovrebbe poterlo scoprire. Dovrebbe avere accesso esattamente allo stesso software utilizzato originariamente, non solo al suo successore migliorato di oggi. Per questo motivo, è effettivamente più importante preservare il codice utilizzato in uno studio piuttosto che correggere i bug. ActivePapers è stato progettato con questo obiettivo: ogni elemento di dato calcolato in un ActivePaper è collegato al software che lo ha prodotto.
Correlato: — Percorsi di data science a progetto con terminale guidato e dataset reali.
Inoltre, questo collegamento è rigorosamente immodificabile dopo la pubblicazione, poiché gli ActivePapers vengono pubblicati proprio come copie elettroniche di articoli e referenziati tramite DOI. Si può barare prima della pubblicazione, modificando un ActivePaper con la specifica intenzione di commettere una frode.
ActivePapers non supporta tali azioni, ma non fa nemmeno alcuno sforzo per prevenire le frodi. Tali funzionalità potrebbero essere aggiunte proteggendo le informazioni sulla provenienza con hash, ma spero che non sarà necessario. Il secondo problema, quello degli ambienti informatici in evoluzione, è più sottile. È un dato di fatto che tutto nel mondo dell’informatica (computer, sistemi operativi, compilatori, definizioni dei linguaggi, librerie, …) cambi a ritmo veloce, con il risultato che un determinato pezzo di codice sorgente difficilmente funzionerà così com’è dopo alcuni anni.
Questo accade per due ragioni: (1) il progresso tecnico consente computer e software sempre migliori, cosa che le persone desiderano, e (2) nessuno ha un interesse diretto nella stabilità delle piattaforme informatiche né il potere di garantirla. Per i produttori di hardware e i fornitori di software commerciale, il cambiamento rapido è il modo migliore per assicurarsi che i clienti acquistino nuove macchine e aggiornino regolarmente le loro licenze. Esiste, naturalmente, almeno una comunità che ha un interesse diretto nella stabilità delle piattaforme informatiche: la comunità della scienza computazionale.
Vale la pena dare un'occhiata: — Un abbonamento per certificati Python e di scienza dei dati supportati dall'università.
Se potessimo eseguire il nostro software tra 20 anni, senza modifiche, e ottenere gli stessi risultati, saremmo felici. Non vogliamo fare manutenzione del software e la maggior parte di noi non può ragionevolmente mantenere il software sviluppato per la propria ricerca oltre le proprie esigenze personali immediate. È ancora meno ragionevole aspettarsi che qualcuno mantenga il software di altri, ad esempio il software lasciato da uno studente laureato che ora lavora nell’industria. In pratica, solo il software di comunità ampiamente utilizzato viene mantenuto per periodi sufficiently lunghi.
Ma anche i progetti di ricerca che utilizzano pacchetti ampiamente usati e mantenuti richiedono solitamente anche del software specifico per il progetto, quanto meno un paio di script di shell. Ed ecco una delle ragioni per cui la riproducibilità degli studi computazionali è così scarsa.
La comunità scientifica potrebbe fare qualcosa al riguardo? Credo di sì, ma non sono ottimista sul fatto che agirà nel prossimo futuro. È probabile che gli scienziati continuino a utilizzare hardware commerciale per il calcolo scientifico, il che significa che dovranno accettare l’evoluzione dell’hardware e del software di sistema associato, che sfugge al loro controllo. Tuttavia, possono costruire una piattaforma stabile sopra queste basi in continua evoluzione, almeno per la parte puramente computazionale del loro lavoro.
A livello fondamentale, tutte le notazioni software Turing-complete sono equivalenti e possono essere convertite l’una nell’altra. In pratica, considerazioni sulle prestazioni impongono un limite alla conversione del codice, ma è comunque possibile definire rappresentazioni di codice che possano essere tradotte efficientemente su tutti i tipi di hardware e software di sistema sottostanti, rimanendo così stabili.
Due esempi reali sono il bytecode JVM e la forma intermedia di LLVM . Il bytecode JVM esiste da 20 anni e si è dimostrato estremamente stabile. La forma intermedia di LLVM non è destinata a essere stabile, ma questo perché gli sviluppatori di LLVM non vogliono limitare le loro opzioni future impegnandosi in una rappresentazione stabile. Il progetto PNaCl di Google cerca di ignorare questo avvertimento e di utilizzare il codice LLVM in un modo che abbia senso solo se rimane stabile.
Il tempo dirà come andrà a finire. La comunità scientifica potrebbe definire la propria rappresentazione di codice intermedio, basandosi sull’esperienza con gli approcci esistenti e ottimizzando la propria piattaforma per le applicazioni scientifiche. Ma, come ho detto sopra, non sono ottimista che ciò accada.
Due requisiti sarebbero un impegno a lungo termine da parte di diverse grandi organizzazioni di ricerca e finanziamento per mantenere questa piattaforma per molti decenni. Sono convinto che ciò sarebbe economicamente ragionevole, perché sono certo che mantenere una piattaforma sia più economico che mantenere molti pacchetti software scientifici e riscrivere costantemente quelli non mantenuti. Ma richiederebbe un livello di accordo e impegno raro nella scienza; si è verificato solo per poche installazioni enormi come il CERN .
Il vantaggio importante fornito da una piattaforma stabile è la ragione per cui la prima edizione di ActivePapers è stata progettata attorno alla JVM. Purtroppo, la JVM non è molto popolare nel calcolo scientifico.
Questo viene spesso spiegato con una mancanza di prestazioni, sebbene quell’argomento non sia più valido come un tempo. Ci sono anche alcuni problemi di progettazione, in particolare riguardanti le operazioni in virgola mobile, ma lo stesso si può dire di linguaggi popolari come C o C++, il che non ha impedito agli scienziati di utilizzarli. L’edizione Python di ActivePapers, praticamente più utile, è costruita su una piattaforma definita dall’ecosistema Scientific Python (in particolare Python, NumPy e h5py).
Questa piattaforma si è dimostrata moderatamente stabile in passato, con la transizione a Python 3 come principale evento di instabilità. La scala temporale su cui la scienza
Approfondimenti
- SciPy — Wikipedia
Impara Python codificando nel tuo browser
Corsi interattivi di Python e scienza dei dati codificati direttamente nel browser