Softwarevedligeholdelse inden for forskning

Python-udgave JVM-udgave Blog … bibliotek —> Softwarevedligeholdelse i forskning af Konrad Hinsen, offentliggjort den 26. feb. 2014 Softwarevedligeholdelse er en af de udfordringer, som udviklere af videnskabelig software står over for regelmæssigt.

Det er en vigtig aktivitet, men den kan tage meget tid, og den belønnes næppe af nutidens evalueringsprocedurer. Og hvis du styrer et stort softwareprojekt, er det typisk svært at skaffe finansiering til vedligeholdelse. Da softwarevedligeholdelse er vanskelig og ikke i sig selv af videnskabelig interesse, bør vi stille os selv spørgsmålet om, hvorfor det er nødvendigt, og om vi kan gøre noget for at reducere behovet for vedligeholdelse. Først og fremmest: Hvad er softwarevedligeholdelse?

Merriam-Webster definerer verbet “maintain” (vedligeholde) som at holde (noget) i god stand ved at foretage reparationer, rette problemer osv. Det giver mening for teknisk udstyr, der forringes over tid på grund af mekanisk slid osv. Software forringes ikke, så vedligeholdelse må betyde noget andet, når det anvendes på software.

Jeg kender ikke til nogen konsensusdefinition, så det, jeg giver her, er min egen: Softwarevedligeholdelse består i at modificere software af en af to årsager: Rettelse af fejl. Sikring af, at softwaren forbliver brugbar i et evolving computermiljø. Nogle ville tilføje funktionelle udvidelser til denne liste, men disse er ikke rigtig vedligeholdelse i nogen forstand, men snarere forbedringer.

Især i tilfælde af videnskabelig software, hvor ny funktionalitet ofte betyder ny videnskab. Først og fremmest: fejl. Som med al anden software ønsker vi, at fejl i videnskabelig software bliver rettet for at opnå bedre resultater i fremtiden.

Vi ønsker dog også at beholde den fejlbehæftede version, hvis nogen publiceret videnskabelig undersøgelse har brugt den. Dette er simpelthen et spørgsmål om ærlighed og bevarelse af det videnskabelige rekordmateriale: Hvis der er en chance for, at resultatet af en undersøgelse er påvirket af en fejl i softwaren, bør folk, der ser på undersøgelsen, kunne finde ud af dette. De bør have adgang til præcis den samme software, som blev brugt oprindeligt, ikke kun til dagens forbedrede efterfølger. Af denne grund er det faktisk vigtigere at bevare den kode, der blev brugt i en undersøgelse, end at rette fejl.

Relateret: DataCamp — Interaktive Python- og datavidenskabskurser koder du direkte i browseren.

ActivePapers blev designet med dette mål for øje: ethvert beregnet dataelement i et ActivePaper er linket til den software, der producerede det. Desuden er dette link strengt umodificerbart efter publicering, da ActivePapers publiceres ligesom elektroniske kopier af artikler og refereres via DOI’er.

Man kan snyde før publicering ved at modificere et ActivePaper med det specifikke formål at begå svindel. ActivePapers understøtter ikke sådanne handlinger, men gør heller ingen indsats for at forhindre svindel. Sådanne funktioner kunne tilføjes ved at beskytte proveniensinformation med hashes, men jeg håber, dette ikke bliver nødvendigt. Det andet problem, evolving computermiljøer, er mere subtilt.

Det er et faktum, at alt i computerverdenen (computere, operativsystemer, compilere, sprogdefinitioner, biblioteker, …) ændrer sig i et hurtigt tempo, med det resultat at en given kildekode usandsynligt vil fungere uændret få år senere. Dette sker af to årsager: (1) tekniske fremskridt muliggør stadig bedre computere og software, hvilket er det, folk ønsker, og (2) ingen har en egentlig interesse i stabiliteten af computerplatforme og magten til at gøre det til virkelighed. For hardwareproducenter og leverandører af kommerciel software er hurtig ændring den bedste måde at sikre, at kunder køber nye maskiner og opdaterer deres licenser regelmæssigt.

Læsernes favorit: Dataquest — Projektbaserede datavidenskabelige stier med en guidet terminal og rigtige datasæt.

Der er naturligvis mindst ét fællesskab, der har en egentlig interesse i stabiliteten af computerplatforme: fællesskabet inden for beregningsvidenskab. Hvis vi kunne køre vores software 20 år senere uden modifikation og få de samme resultater, ville vi være glade. Vi ønsker ikke at udføre softwarevedligeholdelse, og de fleste af os kan ikke rimeligt vedligeholde den software, vi udvikler til vores egen forskning, ud over vores umiddelbare personlige behov.

Det er endnu mindre rimeligt at forvente, at nogen vedligeholder andres software, for eksempel den software, der er efterladt af en ph.d.-studerende, der nu arbejder i industrien. I praksis er det kun bredt anvendt fællesskabssoftware, der bliver vedligeholdt over tilstrækkeligt lange perioder.

Men selv forskningsprojekter, der bruger bredt anvendte og vedligeholdte pakker, kræver normalt også noget projektspecifik software, som minimum et par shell-scripts. Og det er en af grundene til, at reproducerbarheden af beregningsmæssige undersøgelser er så dårlig. Kunne det videnskabelige fællesskab gøre noget ved dette? Jeg tror, det kan, men jeg er ikke optimistisk med hensyn til, at det vil handle i den nærmeste fremtid.

Det er sandsynligt, at forskere fortsat vil bruge standardhardware til videnskabelig databehandling, hvilket betyder, at de må acceptere udviklingen af hardware og den tilhørende systemsoftware, som de ikke har kontrol over. De kan dog bygge en stabil platform oven på disse stadigt evolving platforme, i hvert fald for den rent beregningsmæssige del af deres arbejde.

På et fundamentalt niveau er alle Turing-komplette notationer for software ækvivalente og kan konverteres til hinanden. I praksis sætter hensyn til ydeevne en grænse for kodekonvertering, men det er stadig muligt at definere koderepræsentationer, der effektivt kan oversættes til alle slags underliggende hardware og systemsoftware og dermed forblive stabile. To eksempler fra virkeligheden er JVM-bytecode og LLVM’s mellemform. JVM-bytecode har eksisteret i 20 år og har vist sig at være ekstremt stabil.

LLVM’s mellemform er ikke beregnet til at være stabil, men det skyldes, at LLVM’s udviklere ikke ønsker at begrænse deres fremtidige muligheder ved at binde sig til en stabil repræsentation. Googles PNaCl-projekt forsøger at ignorere denne advarsel og bruge LLVM-kode på en måde, der kun giver mening, hvis den forbliver stabil. Tiden vil vise, hvordan dette vil udvikle sig.

Relateret: Udemy — Køb individuelle videnskabelige Python-kurser direkte, ofte med store rabatter.

Det videnskabelige fællesskab kunne definere sin egen mellemste koderepræsentation, bygge på erfaringerne med eksisterende tilgange og optimere deres platform til videnskabelige applikationer. Men som jeg sagde ovenfor, er jeg ikke optimistisk med hensyn til, at dette vil ske. To krav ville være en langsigtet forpligtelse fra flere store forsknings- og finansieringsorganisationer til at vedligeholde denne platform over mange årtier.

Jeg er overbevist om, at dette ville være økonomisk fornuftigt, fordi jeg er sikker på, at vedligeholdelse af én platform er billigere end vedligeholdelse af masser af videnskabelige softwarepakker og konstant omskrivning af dem, der ikke blev vedligeholdt. Men det ville kræve en grad af enighed og forpligtelse, der er sjælden i videnskaben; det er kun sket for nogle få kæmpestore installationer såsom CERN.

Den vigtige fordel, som en stabil platform giver, er grunden til, at den første ActivePapers-udgave blev designet omkring JVM. Desværre er JVM ikke særlig populær inden for videnskabelig databehandling. Dette forklares ofte med manglende ydeevne, selvom dette argument ikke længere er så gyldigt, som det plejede at være. Der er også nogle få designproblemer, især vedrørende flydende-komma-operationer, men det samme kan siges om populære sprog som C eller C++, hvilket ikke har holdt forskere fra at bruge dem.

Vores valg: O'Reilly Learning Platform — Et dybt teknisk bibliotek med videnskabelige bøger, videoer og livetræning.

Den praktisk mere nyttige Python-udgave af ActivePapers er bygget på en platform defineret af Scientific Python-økosystemet (især Python, NumPy og h5py). Denne platform har vist sig at være moderat stabil tidligere, hvor overgangen til Python 3 var den største begivenhed af ustabilitet. Tidsrammen, hvori videnskabelig

Yderligere læsning

• SciPy — Wikipedia