Utrzymanie oprogramowania w badaniach naukowych
edycja Python edycja JVM Blog … biblioteka —> Utrzymanie oprogramowania w badaniach naukowych autorstwa Konrada Hinsena, opublikowano 26 lutego 2014 r. Utrzymanie oprogramowania to jedno z wyzwań, z którymi regularnie mierzą się twórcy oprogramowania naukowego.
Jest to działalność istotna, ale bardzo czasochłonna i współczesne systemy ewaluacji rzadko ją doceniają. Co więcej, w przypadku dużych projektów programistowych pozyskanie finansowania na utrzymanie bywa zazwyczaj trudne. Biorąc pod uwagę, że utrzymanie oprogramowania jest skomplikowane i samo w sobie nie stanowi celu naukowego, warto zadać sobie pytanie, dlaczego jest ono konieczne oraz czy można coś zrobić, aby zmniejszyć potrzebę jego prowadzenia.
Przede wszystkim: czym jest utrzymanie oprogramowania? Słownik Merriam-Webster definiuje czasownik „maintain” (utrzymywać) jako dbanie o to, by coś pozostawało w dobrym stanie poprzez naprawy, usuwanie problemów itp.
Ma to sens w przypadku sprzętu technicznego, który z czasem ulega degradacji na skutek zużycia mechanicznego itd. Oprogramowanie nie ulega degradacji, więc w odniesieniu do niego „utrzymanie” musi oznaczać coś innego. Nie znam żadnej powszechnie uznanej definicji, dlatego przedstawiam własną:
Utrzymanie oprogramowania polega na jego modyfikacji z jednego z dwóch powodów:
- Naprawiania błędów.
- Zapewnienia użyteczności oprogramowania w zmieniających się środowiskach obliczeniowych.
Niektórzy dodaliby do tej listy również rozszerzanie funkcjonalności, jednak nie są to tak naprawdę działania utrzymaniowe, lecz ulepszenia. Szczególnie w przypadku oprogramowania naukowego nowa funkcjonalność często oznacza nowe odkrycia naukowe.
Powiązane: — Interaktywne kursy Python i data science, które kodujesz bezpośrednio w przeglądarce.
Po pierwsze: błędy. Jak w przypadku każdego oprogramowania, chcemy, aby błędy w oprogramowaniu naukowym były naprawiane, co pozwoli uzyskać lepsze wyniki w przyszłości.
Jednocześnie chcemy zachować wersję zawierającą błędy, jeśli została ona wykorzystana w jakiejkolwiek opublikowanej pracy naukowej. To po prostu kwestia uczciwości i ochrony dorobku naukowego: jeśli istnieje szansa, że na wynik badania wpłynął błąd w oprogramowaniu, osoby analizujące to badanie powinny mieć możliwość dowiedzenia się o tym. Powinny mieć dostęp do dokładnie tego samego oprogramowania, którego pierwotnie użyto, a nie tylko do jego dzisiejszej, ulepszonej wersji. Z tego powodu ważniejsze jest właściwie zachowanie kodu użytego w badaniu niż naprawianie błędów.
ActivePapers został zaprojektowany z myślą o tym celu: każdy element danych obliczeniowych w ActivePaper jest powiązany z oprogramowaniem, które go wygenerowało. Co więcej, połączenie to jest po publikacji całkowicie niemodyfikowalne, ponieważ ActivePapers są publikowane podobnie jak elektroniczne kopie artykułów i identyfikowane za pomocą DOI. Przed publikacją można oszukiwać, modyfikując ActivePaper w zamiarze popełnienia nadużycia.
Ulubiony czytelnik: — Ścieżki analizy danych oparte na projektach z terminalem z przewodnikiem i rzeczywistymi zbiorami danych.
ActivePapers nie wspiera takich działań, ale też nie podejmuje specjalnych wysiłków, aby im zapobiec. Takie funkcje można by dodać, zabezpieczając informacje o pochodzeniu danych za pomocą sum kontrolnych (hashy), jednak mam nadzieję, że nie będzie to konieczne.
Drugi problem – ewoluujące środowiska obliczeniowe – jest bardziej subtelny. To fakt, że w świecie informatycznym wszystko (komputery, systemy operacyjne, kompilatory, definicje języków, biblioteki…) zmienia się szybko, w wyniku czego dany kod źródłowy prawdopodobnie nie będzie działał bez zmian kilka lat później.
Dzieje się tak z dwóch przyczyn: (1) postęp techniczny umożliwia tworzenie coraz lepszych komputerów i oprogramowania, czego ludzie oczekują, oraz (2) nikt nie ma interesu w stabilności platform obliczeniowych ani władzy, by ją zapewnić. Dla producentów sprzętu i dostawców oprogramowania komercyjnego szybkie zmiany to najlepszy sposób na to, by klienci kupowali nowe maszyny i regularnie aktualizowali licencje.
Istnieje oczywiście co najmniej jedna społeczność zainteresowana stabilnością platform obliczeniowych: środowisko nauk obliczeniowych. Gdybyśmy mogli uruchomić nasze oprogramowanie za 20 lat bez żadnych modyfikacji i otrzymać te same wyniki, bylibyśmy zadowoleni.
Nie chcemy zajmować się utrzymaniem oprogramowania, a większość z nas nie jest w stanie rozsądnie utrzymywać oprogramowania opracowanego na potrzeby własnych badań poza ich bezpośrednimi, osobistymi wymaganiami. Jesmniej rozsądne jest oczekiwanie, że ktoś będzie utrzymywał cudze oprogramowanie – na przykład oprogramowanie pozostawione przez doktoranta, który obecnie pracuje w przemyśle. W praktyce jedynie szeroko stosowane oprogramowanie społecznościowe jest utrzymywane przez wystarczająco długie okresy.
Jednak nawet projekty badawcze korzystające z popularnych i utrzymywanych pakietów zazwyczaj wymagają także oprogramowania specyficznego dla danego projektu, choćby kilku skryptów powłoki. To jeden z powodów, dla których powtarzalność badań obliczeniowych pozostawia wiele do życzenia.
Czy środowisko naukowe mogłoby coś z tym zrobić? Sądzę, że tak, ale nie jestem optymistą co do podjęcia działań w najbliższej przyszłości. Prawdopodobnie naukowcy będą nadal korzystać ze standardowego sprzętu do obliczeń naukowych, co oznacza, że będą musieli zaakceptować ewolucję sprzętu i związanego z nim oprogramowania systemowego, na którą nie mają wpływu.
Mogą jednak zbudować stabilną platformę na bazie tych ciągle zmieniających się rozwiązań, przynajmniej w odniesieniu do czysto obliczeniowej części swojej pracy. Na fundamentalnym poziomie wszystkie notacje oprogramowania pełne Turinga są równoważne i mogą być wzajemnie konwertowane. W praktyce względy wydajnościowe nakładają pewne ograniczenia na konwersję kodu, niemniej nadal możliwe jest zdefiniowanie reprezentacji kodu, które można efektywnie tłumaczyć na różne rodzaje underlying sprzętu i oprogramowania systemowego, zachowując przy tym stabilność.
Dwa realne przykłady to bajtkod JVM oraz forma pośrednia LLVM. Bajtkod JVM istnieje od 20 lat i okazał się niezwykle stabilny. Forma pośrednia LLVM nie jest przeznaczona do bycia stabilną, ale wynika to z faktu, że deweloperzy LLVM nie chcą ograniczać swoich przyszłych opcji poprzez zobowiązanie się do jednej stabilnej reprezentacji.
Projekt Google PNaCl próbuje zignorować to ostrzeżenie i wykorzystać kod LLVM w sposób mający sens tylko wtedy, gdy pozostanie on stabilny. Czas pokaże, jak to się sprawdzi.
Społeczność naukowa mogłaby zdefiniować własną reprezentację kodu pośredniego, bazując na doświadczeniach z istniejącymi rozwiązaniami i optymalizując swoją platformę pod kątem aplikacji naukowych. Jednak, jak już wspominałem, nie jestem optymistą co do tego, że do tego dojdzie.
Konieczne byłyby długoterminowe zobowiązania ze strony kilku dużych instytucji badawczych i finansujących do utrzymania takiej platformy przez wiele dekad. Jestem przekonany, że byłoby to ekonomicznie uzasadnione, ponieważ utrzymanie jednej platformy jest z pewnością tańsze niż utrzymanie wielu pakietów oprogramowania naukowego i ciągłe przepisywanie tych, które nie były utrzymywane. Wymagałoby to jednak poziomu porozumienia i zaangażowania, który w nauce jest rzadki; zdarzyło się to jedynie w przypadku kilku ogromnych instalacji, takich jak CERN.
Istotną zaletą zapewnianą przez stabilną platformę jest powód, dla którego pierwsza edycja ActivePapers została zaprojektowana wokół JVM. Niestety, JVM nie cieszy się dużą popularnością w obliczeniach naukowych.
Często tłumaczy się to brakiem wydajności, choć argument ten nie jest już tak zasadny jak kiedyś. Istnieje też kilka problemów projektowych, szczególnie dotyczących operacji zmiennoprzecinkowych, ale to samo można powiedzieć o popularnych językach takich jak C czy C++, co nie powstrzymało naukowców przed ich użytkowaniem. Praktycznie bardziej użyteczna edycja Python ActivePapers została zbudowana na platformie zdefiniowanej przez ekosystem Scientific Python (w szczególności Python, NumPy i h5py).
Platforma ta w przeszłości wykazywała umiarkowaną stabilność, przy czym głównym wydarzeniem destabilizującym było przejście na Pythona 3. Skala czasowa, w której badania naukowe…
Literatura dodatkowa
- SciPy — Wikipedia
Posiadaj kurs na całe życie, a nie subskrypcję
Kupuj od ręki indywidualne kursy naukowe w języku Python, często z dużymi rabatami