Software-onderhoud in onderzoek
Python-editie JVM-editie Blog … bibliotheek —> Softwareonderhoud in de wetenschap door Konrad Hinsen, geplaatst op 26 feb. 2014 Softwareonderhoud is een van de moeilijkheden waarmee ontwikkelaars van wetenschappelijke software regelmatig worden geconfronteerd.
Het is een belangrijke activiteit, maar het kost veel tijd en wordt nauwelijks beloond door de huidige evaluatieprocedures. En als je een groot softwareproject beheert, is het doorgaans lastig om financiering voor onderhoud te verkrijgen. Gezien het feit dat softwareonderhoud moeilijk is en niet intrinsiek van wetenschappelijk belang, moeten we ons de vraag stellen waarom het noodzakelijk is en of we iets kunnen doen om de behoefte eraan te verminderen. Allereerst: wat is softwareonderhoud?
Merriam-Webster definieert het werkwoord “maintain” (onderhouden) als: iets in goede staat houden door reparaties uit te voeren, problemen op te lossen, enz. Dit heeft zin voor technische apparatuur die na verloop van tijd slijt door mechanische wear-and-tear enzovoort. Software slijt niet, dus moet “onderhoud” iets anders betekenen wanneer het op software wordt toegepast.
Ik ken geen algemeen aanvaarde definitie, dus wat ik hier geef, is mijn eigen interpretatie: Softwareonderhoud bestaat uit het wijzigen van software om een van twee redenen: Bugs verhelpen. De software bruikbaar houden in evoluerende computeromgevingen. Sommigen zouden functionele verbeteringen aan deze lijst toevoegen, maar dat zijn geen onderhoudswerkzaamheden in enige zin, maar verbeteringen.
Zeker in het geval van wetenschappelijke software, waar nieuwe functionaliteit vaak nieuw wetenschappelijk onderzoek betekent. Ten eerste: bugs. Zoals bij elke software willen we ook in wetenschappelijke software bugs laten verhelpen om in de toekomst betere resultaten te krijgen.
Tegelijkertijd willen we de buggy versie bewaren als er een gepubliceerde wetenschappelijke studie gebruik van heeft gemaakt. Dit is simpelweg een kwestie van eerlijkheid en behoud van het wetenschappelijke dossier: als er een kans bestaat dat de uitkomst van een studie beïnvloed is door een bug in de software, moeten mensen die de studie bestuderen dit kunnen achterhalen. Ze moeten toegang hebben tot exact dezelfde software die oorspronkelijk is gebruikt, niet alleen tot de verbeterde opvolger van vandaag.
Gerelateerd: — Projectgebaseerde datawetenschapspaden met een begeleide terminal en echte datasets.
Om deze reden is het eigenlijk belangrijker om de code die in een studie is gebruikt te bewaren dan om bugs te verhelpen. ActivePapers is met dit doel ontworpen: elk berekend data-item in een ActivePaper is gekoppeld aan de software die het heeft gegenereerd.
Bovendien is deze koppeling na publicatie strikt onveranderlijk, aangezien ActivePapers net als elektronische kopieën van artikelen worden gepubliceerd en via DOI’s worden gerefereerd. Je kunt vóór publicatie frauderen door een ActivePaper te wijzigen met de specifieke bedoeling om fraude te plegen. ActivePapers ondersteunt dergelijke acties niet, maar doet ook geen moeite om fraude te voorkomen. Dergelijke functies zouden kunnen worden toegevoegd door herkomstinformatie te beschermen met hashes, maar ik hoop dat dit niet nodig zal zijn.
Het tweede probleem, evoluerende computeromgevingen, is subtieler. Het is een feit dat alles in de computerwereld (computers, besturingssystemen, compilers, taaldefinities, bibliotheken, …) snel verandert, met als gevolg dat een bepaalde broncode waarschijnlijk over een paar jaar niet meer zonder meer werkt. Dit gebeurt om twee redenen: (1) technische vooruitgang maakt steeds betere computers en software mogelijk, wat mensen nu eenmaal willen, en (2) niemand heeft een vested interest in de stabiliteit van computerplatforms én de macht om die te realiseren.
Een kijkje waard: — Eén abonnement voor door de universiteit ondersteunde Python- en data-science-certificaten.
Voor hardwarefabrikanten en leveranciers van commerciële software is snelle verandering de beste manier om ervoor te zorgen dat klanten nieuwe machines kopen en hun licenties regelmatig vernieuwen. Er is natuurlijk ten minste één gemeenschap die wel degelijk belang heeft bij de stabiliteit van computerplatforms: de gemeenschap van computationele wetenschappen. Als we onze software over 20 jaar nog steeds zonder aanpassingen zouden kunnen draaien en dezelfde resultaten zouden krijgen, zouden we tevreden zijn.
We willen geen softwareonderhoud doen, en de meesten van ons kunnen redelijkerwijs de software die ze voor hun eigen onderzoek ontwikkelen niet langer onderhouden dan direct nodig is voor hun persoonlijke behoeften. Het is nog minder redelijk om van iemand te verwachten dat hij andermans software onderhoudt, bijvoorbeeld de software die is achtergelaten door een promovendus die inmiddels in het bedrijfsleven werkt.
In de praktijk wordt alleen widely used community-software over voldoende lange periodes onderhouden. Maar zelfs onderzoeksprojecten die gebruikmaken van veelgebruikte en onderhouden packages vereisen doorgaans ook projectspecifieke software, op zijn minst een paar shell-scripts. En dat is een van de redenen waarom de reproduceerbaarheid van computationele studies zo slecht is. Kan de wetenschappelijke gemeenschap hier iets aan doen?
Ik geloof van wel, maar ik ben niet optimistisch dat er op korte termijn actie wordt ondernomen. Het is waarschijnlijk dat wetenschappers commodity-hardware zullen blijven gebruiken voor wetenschappelijk rekenwerk, wat betekent dat ze de evolutie van hardware en de bijbehorende systeemsoftware moeten accepteren, waar ze geen controle over hebben.
Ze kunnen echter wel een stabiel platform bovenop deze voortdurend evoluerende platforms bouwen, althans voor het puur computationele deel van hun werk. Op fundamenteel niveau zijn alle Turing-complete notaties voor software equivalent en kunnen ze in elkaar worden omgezet. In de praktijk leggen prestatieoverwegingen een grens op aan code-conversie, maar het is nog steeds mogelijk om coderepresentaties te definiëren die efficiënt kunnen worden vertaald naar allerlei onderliggende hardware en systeemsoftware en daarmee stabiel blijven.
Twee reële voorbeelden zijn JVM-bytecode en LLVM ‘s intermediate form . JVM-bytecode bestaat al 20 jaar en heeft zich uiterst stabiel getoond. LLVM’s intermediate form is niet bedoeld om stabiel te zijn, maar dat komt omdat de ontwikkelaars van LLVM hun toekomstige opties niet willen beperken door zich vast te leggen op een stabiele representatie.
Google’s PNaCl-project probeert deze waarschuwing te negeren en LLVM-code te gebruiken op een manier die alleen zinvol is als deze stabiel blijft. De tijd zal leren hoe dit uitpakt. De wetenschappelijke gemeenschap zou haar eigen intermediate coderepresentatie kunnen definiëren, voortbouwend op de ervaring met bestaande benaderingen, en hun platform optimaliseren voor wetenschappelijke toepassingen.
Maar zoals ik hierboven al zei, ben ik niet optimistisch dat dit zal gebeuren. Twee vereisten zouden een langetermijncommitment van verschillende grote onderzoeks- en financieringsorganisaties zijn om dit platform vele decennia lang te onderhouden.
Ik ben ervan overtuigd dat dit economisch verstandig zou zijn, omdat ik zeker weet dat het onderhouden van één platform goedkoper is dan het onderhouden van talloze wetenschappelijke softwarepackages en het voortdurend herschrijven van diegenen die niet werden onderhouden. Maar het zou een niveau van overeenstemming en toezegging vereisen dat zeldzaam is in de wetenschap; het is slechts gebeurd bij een paar enorme installaties zoals CERN . Het belangrijke voordeel dat een stabiel platform biedt, is de reden waarom de eerste editie van ActivePapers rondom de JVM is ontworpen.
Helaas is de JVM niet erg populair in wetenschappelijk rekenwerk. Dit wordt vaak verklaard door een gebrek aan prestaties, hoewel dat argument niet meer zo geldig is als vroeger.
Er zijn ook enkele ontwerpproblemen, met name betreffende floating-point-bewerkingen, maar hetzelfde kan gezegd worden van populaire talen zoals C of C++, wat wetenschappers er niet van heeft weerhouden ze te gebruiken. De praktisch nuttigere Python-editie van ActivePapers is gebouwd op een platform dat wordt gedefinieerd door het Scientific Python-ecosysteem (met name Python, NumPy en h5py). Dit platform heeft zich in het verleden matig stabiel getoond, waarbij de overgang naar Python 3 de belangrijkste gebeurtenis van instabiliteit was. De tijdschaal waarop wetenschappelijk
Verder lezen
- SciPy — Wikipedia
Leer Python door in uw browser te coderen
Interactieve Python- en datascience-cursussen die u rechtstreeks in de browser codeert