Mjukvaruunderhåll inom forskning
Python-utgåva JVM-utgåva Blogg … bibliotek —> Programvaruunderhåll inom forskningen av Konrad Hinsen, publicerad den 26 feb 2014 Programvaruunderhåll är en av de svårigheter som utvecklare av vetenskaplig programvara ställs inför regelbundet. Det är en viktig aktivitet, men den kan ta mycket tid och belönas knappt alls av dagens utvärderingsmetoder.
Och om du hanterar ett stort programvaruprojekt är det vanligtvis svårt att få finansiering för underhåll. Eftersom programvaruunderhåll är svårt och inte i sig av vetenskapligt intresse, bör vi ställa oss frågan varför det är nödvändigt, och om vi kan göra något för att minska behovet av underhåll.
Först och främst, vad är programvaruunderhåll? Merriam-Webster definierar verbet “maintain” (underhålla) som att hålla (något) i gott skick genom reparationer, korrigering av problem etc. Detta ger mening för teknisk utrustning som försämras över tid på grund av mekaniskt slitage etc. Programvara försämras inte, så underhåll måste betyda något annat när det tillämpas på programvara. Jag känner inte till någon allmänt accepterad definition, så det jag presenterar här är min egen: Programvaruunderhåll består av att modifiera programvara av en av två anledningar:
- Åtgärda fel.
- Hålla programvaran användbar i en föränderlig datormiljö.
Vissa skulle lägga till funktionella förbättringar på denna lista, men dessa är egentligen inte underhåll i någon bemärkelse, utan förbättringar. Särskilt när det gäller vetenskaplig programvara, där ny funktionalitet ofta betyder ny vetenskap.
Först, fel. Precis som med all programvara vill vi att fel i vetenskaplig programvara åtgärdas för att få bättre resultat i framtiden. Men vi vill också behålla den felfyllda versionen om någon publicerad vetenskaplig studie har använt den.
Detta är helt enkelt en fråga om ärlighet och bevarande av det vetenskapliga arvet: om det finns en chans att utfallet av en studie har påverkats av ett fel i programvaran, borde personer som granskar studien kunna ta reda på detta. De bör ha tillgång till exakt samma programvara som användes ursprungligen, inte bara till dagens förbättrade efterföljare. Av denna anledning är det faktiskt viktigare att bevara den kod som användes i en studie än att åtgärda fel. ActivePapers designades med detta mål i åtanke: varje beräknat dataobjekt i en ActivePaper är länkat till den programvara som producerade det.
Relaterat: — Projektbaserade datavetenskapliga vägar med en guidad terminal och riktiga datamängder.
Dessutom är denna länk strikt oföränderlig efter publicering, eftersom ActivePapers publiceras precis som elektroniska kopior av artiklar och refereras via DOI:er. Du kan fuska före publicering genom att modifiera en ActivePaper med det specifika syftet att begå bedrägeri. ActivePapers stöder inte sådana handlingar, men gör heller inga ansträngningar för att förhindra bedrägerier.
Sådana funktioner skulle kunna läggas till genom att skydda proveniensinformation med hash-summor, men jag hoppas att detta inte kommer att bli nödvändigt.
Det andra problemet, föränderliga datormiljöer, är mer subtilt. Det är ett faktum att allt i datorvärlden (datorer, operativsystem, kompilatorer, språkdefinitioner, bibliotek, …) förändras i snabb takt, vilket leder till att en given källkod osannolikt kommer att fungera oförändrad några år senare.
Värt att titta på: — En prenumeration för universitetsstödda Python- och datavetenskapliga certifikat.
Detta sker av två anledningar: (1) tekniska framsteg möjliggör allt bättre datorer och programvara, vilket är vad folk vill ha, och (2) ingen har ett eget intresse av stabiliteten hos datorplattformar och makten att åstadkomma den. För hårdvaruleverantörer och leverantörer av kommersiell programvara är snabba förändringar det bästa sättet att säkerställa att kunder köper nya maskiner och uppdaterar sina licenser regelbundet.
Det finns naturligtvis åtminstone en gemenskap som har ett eget intresse av stabiliteten hos datorplattformar: gemenskapen för beräkningsvetenskap. Om vi kunde köra vår programvara 20 år senare, utan modifiering, och få samma resultat, skulle vi vara nöjda.
Vi vill inte ägna oss åt programvaruunderhåll, och de flesta av oss kan inte rimligen underhålla den programvara vi utvecklar för vår egen forskning utöver våra omedelbara personliga behov. Det är ännu mindre rimligt att förvänta sig att någon ska underhålla någon annans programvara, till exempel den programvara som lämnats kvar av en doktorand som nu arbetar i industrin. I praktiken är det bara widely used community software (programvara som används i stor utsträckning av gemenskapen) som underhålls under tillräckligt långa perioder.
Men även forskningsprojekt som använder välanvända och underhållna paket kräver vanligtvis också viss projektspecifik programvara, åtminstone ett par skal-skript. Och det är en av anledningarna till att reproducerbarheten hos beräkningsstudier är så dålig.
Skulle den vetenskapliga gemenskapen kunna göra något åt detta? Jag tror att det går, men jag är inte optimistisk när det gäller att åtgärder kommer att vidtas inom en snar framtid.
Det är sannolikt att forskare kommer att fortsätta använda standardhårdvara för vetenskapliga beräkningar, vilket innebär att de måste acceptera utvecklingen av hårdvara och tillhörande systemprogramvara, vilket ligger utanför deras kontroll. Däremot kan de bygga en stabil plattform ovanpå dessa ständigt föränderliga plattformar, åtminstone för den rent beräkningsmässiga delen av sitt arbete. På en fundamental nivå är alla Turing-fullständiga notationer för programvara ekvivalenta och kan konverteras till varandra.
I praktiken sätter prestandaöverväganden en gräns för kodkonvertering, men det är fortfarande möjligt att definiera kodrepresentationer som effektivt kan översättas till alla typer av underliggande hårdvara och systemprogramvara och därmed förbli stabila. Två verkliga exempel är JVM-bytekod och LLVM:s mellanform. JVM-bytekod har funnits i 20 år och har visat sig vara extremt stabil.
LLVM:s mellanform är inte avsedd att vara stabil, men det beror på att LLVM:s utvecklare inte vill begränsa sina framtida alternativ genom att binda sig vid en stabil representation. Googles PNaCl-projekt försöker ignorera denna varning och använda LLVM-kod på ett sätt som bara ger mening om den förblir stabil. Tiden får utvisa hur detta kommer att fungera.
Den vetenskapliga gemenskapen skulle kunna definiera sin egen mellanliggande kodrepresentation, bygga på erfarenheter från befintliga metoder och optimera sin plattform för vetenskapliga applikationer. Men som jag sa ovan är jag inte optimistisk när det gäller att detta kommer att hända.
Två krav skulle vara ett långsiktigt åtagande från flera stora forsknings- och finansieringsorganisationer att underhålla denna plattform under många decennier. Jag är övertygad om att detta skulle vara ekonomiskt försvarbart, eftersom jag är säker på att det är billigare att underhålla en plattform än att underhålla massor av vetenskapliga programvarupaket och ständigt skriva om de som inte underhölls. Men det skulle kräva en grad av samförstånd och engagemang som är sällsynt inom vetenskapen; det har bara hänt för några få enorma installationer såsom CERN.
Den stora fördelen med en stabil plattform är anledningen till att den första ActivePapers-utgåvan designades runt JVM. Tyvärr är JVM inte särskilt populär inom vetenskapliga beräkningar.
Detta förklaras ofta av bristande prestanda, även om det argumentet inte längre är lika giltigt som det en gång var. Det finns också några designproblem, särskilt när det gäller flyttalsoperationer, men detsamma kan sägas om populära språk som C eller C++, vilket inte har hindrat forskare från att använda dem. Den praktiskt sett mer användbara Python-utgåvan av ActivePapers är byggd på en plattform som definieras av Scientific Python-ekosystemet (särskilt Python, NumPy och h5py). Denna plattform har visat sig vara måttligt stabil tidigare, där övergången till Python 3 var den största händelsen som innebar instabilitet. Tidsskalan över vilken vetenskaplig
Vidare läsning
- SciPy — Wikipedia
Lär dig Python genom att koda i din webbläsare
Interaktiva Python- och datavetenskapskurser kodar du direkt i webbläsaren