Programvarevedlikehold i forskning
Python-utgave JVM-utgave Blogg … bibliotek —> Programvarevedlikehold i forskning av Konrad Hinsen, publisert 26. feb. 2014 Programvarevedlikehold er én av de utfordringene utviklere av vitenskapelig programvare møter regelmessig.
Det er en viktig aktivitet, men den kan kreve mye tid og belønnes knapt av dagens evalueringsordninger. Og hvis du styrer et stort programvareprosjekt, er det vanligvis vanskelig å få finansiering til vedlikehold. Siden programvarevedlikehold er krevende og ikke i seg selv av vitenskapelig interesse, bør vi spørre oss hvorfor det er nødvendig, og om vi kan gjøre noe for å redusere behovet for det.
Først og fremst: hva er programvarevedlikehold? Merriam-Webster definerer verbet «maintain» (å vedlikeholde) som å holde (noe) i god stand ved å utføre reparasjoner, rette problemer osv. Dette gir mening for teknisk utstyr som forringes over tid på grunn av mekanisk slitasje osv. Programvare forringes ikke, så «vedlikehold» må bety noe annet når det gjelder programvare. Jeg kjenner ikke til noen konsensusdefinisjon, så det jeg presenterer her er min egen:
Programvarevedlikehold består i å endre programvare av én av to årsaker:
- Å fikse feil (bugs).
- Å holde programvaren brukbar i et stadig evoluerende datamaskinmiljø.
Noen vil legge til funksjonelle utvidelser på denne listen, men det er egentlig ikke vedlikehold i noen forstand, melainkan forbedringer. Spesielt når det gjelder vitenskapelig programvare, betyr ny funksjonalitet ofte ny vitenskap.
La oss først se på feil. Som med all programvare ønsker vi at feil i vitenskapelig programvare blir rettet for å oppnå bedre resultater i fremtiden. Samtidig ønsker vi å beholde den feilbehiftede versjonen hvis noen publiserte vitenskapelige studier har brukt den.
Relatert: — Interaktive Python- og datavitenskap-kurs koder du direkte i nettleseren.
Dette er rett og slett et spørsmål om ærlighet og bevaring av det vitenskapelige grunnlaget: hvis det er en mulighet for at resultatet av en studie er påvirket av en feil i programvaren, bør de som gransker studien kunne finne dette ut. De bør ha tilgang til nøyaktig samme programvare som ble brukt opprinnelig, ikke bare til dagens forbedrede etterfølger. Av denne grunnen er det faktisk viktigere å bevare koden som ble brukt i en studie, enn å fikse feil.
ActivePapers ble designet med dette målet for øye: ethvert beregnet dataelement i et ActivePaper er koblet til programvaren som produserte det. Dessuten er denne koblingen strengt uforanderlig etter publisering, siden ActivePapers publiseres akkurat som elektroniske kopier av artikler og refereres via DOI-er.
Du kan jukse før publisering ved å endre et ActivePaper med den spesifikke hensikt å begå svindel. ActivePapers støtter ikke slike handlinger, men gjør heller ingen forsøk på å forhindre svindel. Slike funksjoner kunne legges til ved å beskytte proveniensinformasjon med hash-verdier, men jeg håper dette ikke blir nødvendig.
Leserfavoritt: — Prosjektbaserte datavitenskapelige stier med en guidet terminal og ekte datasett.
Det andre problemet, evoluerende datamaskinmiljøer, er mer subtilt. Det er et faktum at alt i dataverdenen (datamaskiner, operativsystemer, kompilatorer, språkdefinisjoner, biblioteker, …) endrer seg raskt, med det resultat at en gitt kildekode sannsynligvis ikke vil fungere som den er noen år senere.
Dette skjer av to grunner: (1) teknologisk fremgang muliggjør stadig bedre maskinvare og programvare, hvilket er det folk ønsker, og (2) ingen har en egeninteresse i stabiliteten til databaserte plattformer og makten til å sikre den. For leverandører av maskinvare og kommersiell programvare er raske endringer den beste måten å sikre at kunder kjøper nye maskiner og oppdaterer lisensene sine jevnlig.
Det finnes selvsagt minst ett fellesskap som har en egeninteresse i stabiliteten til databaserte plattformer: miljøet for beregningsvitenskap. Hvis vi kunne kjøre programvaren vår om 20 år uten endringer og få de samme resultatene, ville vi vært fornøyde.
Vi ønsker ikke å drive med programvarevedlikehold, og de fleste av oss kan ikke på rimelig vis vedlikeholde programvaren vi utvikler for egen forskning utover våre umiddelbare personlige behov. Det er enda mindre rimelig å forvente at noen skal vedlikeholde andres programvare, for eksempel programvaren som er etterlatt av en doktorgradsstipendiat som nå jobber i industrien. I praksis er det kun mye brukt fellesprogramvare som blir vedlikeholdt over tilstrekkelig lange perioder. Men selv forskningsprosjekter som bruker mye brukte og vedlikeholdte pakker, krever vanligvis også litt prosjektspesifikk programvare, i det minste noen få skript.
Og det er én av grunnene til at reproduserbarheten av beregningsstudier er så dårlig.
Kan det vitenskapelige miljøet gjøre noe med dette? Jeg tror det er mulig, men jeg er ikke optimistisk med tanke på at det vil iverksettes tiltak i nær fremtid.
Det er sannsynlig at forskere fortsatt vil bruke standard maskinvare for vitenskapelige beregninger, noe som betyr at de må akseptere utviklingen av maskinvare og tilhørende systemprogramvare, som de ikke har kontroll over. De kan imidlertid bygge en stabil plattform oppå disse stadig evoluerende løsningene, i hvert fall for den rent beregningsmessige delen av arbeidet sitt. På et fundamentalt nivå er alle Turing-komplette notasjoner for programvare ekvivalente og kan konverteres til hverandre. I praksis setter ytelseshensyn en grense for kodekonvertering, men det er likevel mulig å definere koderepresentasjoner som kan oversettes effektivt til alle typer underliggende maskinvare og systemprogramvare, og dermed forbli stabile.
To virkelige eksempler er JVM-bytecode og LLVMs mellomform. JVM-bytecode har eksistert i 20 år og har vist seg å være ekstremt stabil. LLVMs mellomform er ikke ment å være stabil, men det skyldes at LLVM-utviklerne ikke ønsker å begrense sine fremtidige muligheter ved å binde seg til en stabil representasjon.
Googles PNaCl-prosjekt forsøker å ignorere denne advarselen og bruke LLVM-kode på en måte som kun gir mening hvis den forblir stabil. Tiden vil vise hvordan dette vil gå.
Det vitenskapelige miljøet kunne definere sin egen mellomliggende koderepresentasjon, bygd på erfaringer med eksisterende tilnærminger, og optimalisert plattformen for vitenskapelige applikasjoner. Men, som jeg sa ovenfor, er jeg ikke optimistisk med tanke på at dette vil skje.
To krav ville være en langsiktig forpliktelse fra flere store forsknings- og finansieringsorganisasjoner til å vedlikeholde denne plattformen over mange tiår. Jeg er overbevist om at dette ville være økonomisk fornuftig, fordi jeg er sikker på at det er billigere å vedlikeholde én plattform enn å vedlikeholde mange vitenskapelige programvarepakker, og stadig omskrive de som ikke ble vedlikeholdt. Men det ville kreve en grad av enighet og forpliktelse som er sjelden i vitenskapen; det har kun skjedd for noen få enorme installasjoner som CERN.
Den viktige fordelen som en stabil plattform tilbyr, er grunnen til at den første ActivePapers-utgaven ble designet rundt JVM. Dessverre er JVM ikke særlig populær innen vitenskapelige beregninger.
Dette forklares ofte med manglende ytelse, selv om det argumentet ikke lenger er like gyldig som før. Det finnes også noen designproblemer, spesielt knyttet til flyttallsoperasjoner, men det samme kan sies om populære språk som C eller C++, noe som ikke har hindret forskere i å bruke dem. Den praktisk sett mer nyttige Python-utgaven av ActivePapers er bygd på en plattform definert av Scientific Python-økosystemet (spesielt Python, NumPy og h5py). Denne plattformen har vist seg å være moderat stabil tidligere, hvor overgangen til Python 3 var den største hendelsen som skapte ustabilitet. Tidsskalaen som vitenskapelig
Videre lesning
- SciPy — Wikipedia
Referansehyllen for arbeidende forskere
Et dypt teknisk bibliotek med vitenskapelige databøker, videoer og live-trening