Edycja Pharo ActivePapers
Edycja Python Edycja JVM Edycja Pharo Blog … biblioteka —> Edycja ActivePapers dla środowiska Pharo autorstwa Konrada Hinsena, opublikowana 10 maja 2019 r. Rodzina ActivePapers ma nowego członka: edycję ActivePaper dla środowiska Pharo.
W przeciwieństwie do edycji dla Pythona i JVM, które w dużej mierze implementują te same idee i koncepcje na dwóch różnych platformach, edycja Pharo realizuje odmienny cel: zbadanie interfejsu człowiek-komputer w kontekście powtarzalnych, zrozumiałych i weryfikowalnych badań wspomaganych komputerowo. Jednym z najczęściej zadawanych mi pytań dotyczących edycji ActivePapers dla Pythona było: „Czy to działa z notatnikami Jupyter?”. Początkowo moja odpowiedź brzmiała: „Jeszcze nie, ale nad tym pracuję”.
I rzeczywiście pracowałem. Jednakże praca ta nigdy nie przyniosła satysfakcjonującego rezultatu. Jednym z powodów były przeszkody techniczne. Próbowałem osadzić notatniki Jupyter wewnątrz ActivePaper, ale okazało się to niemożliwe, ponieważ architektura Jupyter oparta na dwóch procesach (jądro i edytor notatnika to oddzielne procesy połączone protokołem komunikacyjnym) była niezgodna z ograniczeniem biblioteki HDF5, która pozwala na zapis do pliku tylko jednemu procesowi w danym momencie.
Oznacza to, że nie można przechowywać notatnika i wyników, które on oblicza, w tym samym pliku HDF5. Im więcej jednak myślałem o integracji ActivePapers i Jupyter, tym bardziej uświadamiałem sobie, że ich liniowe notatniki (sekwencja komórek z kodem, dokumentacją i wynikami) nie są naprawdę dostosowane do zadania dokumentowania obliczeń naukowych, z wyjątkiem prostych przypadków. Jeśli przyjrzeć się различным opublikowanym ActivePapers, invariably zawierają one wiele skryptów plus kilka modułów bibliotecznych.
Pobieżnie może się wydawać, że notatniki mogą zastąpić skrypty, zapewniając jednocześnie dokumentację. Jednak dobra dokumentacja musi dokumentować całość, a nie tylko jej części.
Musi spajać ze sobą wiele skryptów oraz kod z modułów bibliotecznych. Zazwyczaj metody obliczeniowe są implementowane w modułach bibliotecznych, a skrypty stosują je do zbiorów danych. Jeśli dokumentacja prowadzona jest skrypt po skrypcie, w jaki sposób udokumentować same metody? Obecnie dostępnych jest wiele opublikowanych notatników Jupyter, więc jak radzą sobie z tym problemem?
Powiązane: — Ścieżki analizy danych oparte na projektach z terminalem z przewodnikiem i rzeczywistymi zbiorami danych.
Oczywiście nie przeanalizowałem ich wszystkich, ale moje dotychczasowe wrażenie jest takie, że mamy do czynienia z dwoma przypadkami. Najczęstszy przypadek to notatniki dokumentujące analizy danych oparte na standardowych, dobrze znanych metodach zaimplementowanych w powszechnie używanych bibliotekach.
Od czytelników takiego notatnika oczekuje się znajomości tych metod lub tego, że dowiedzą się o nich gdzie indziej. Drugi przypadek to notatniki zawierające pełną implementację metody. Oprócz ograniczenia do prostych metod, podejście to ma tę dużą wadę, że implementacja metody nie nadaje się do ponownego wykorzystania. Ponieważ moje własne badania koncentrują się głównie na opracowywaniu i ewaluacji nowych metod obliczeniowych, doszedłem do wniosku, że notatniki nie są odpowiednim narzędziem dla mojej pracy.
W rzeczywistości doszedłem do tego samego wniosku poprzez próby. Za każdym razem, gdy zaczynałem nowy projekt jako notatnik, szybko przechodziłem do modułów i skryptów w starym stylu, z dokumentacją w oddzielnych plikach tekstowych. Uznałem tę technikę za całkowicie wystarczającą do użytku osobistego, ale zbiór plików, nawet dobrze zorganizowany, nie zachęca innego naukowca, nawet współpracownika, do zgłębiania tematu.
Warto zobaczyć: — Jedna subskrypcja wspieranych przez uniwersytet certyfikatów Python i Data Science.
Kiedy kilka miesięcy temu zacząłem przyglądać się środowisku Pharo, w dużej mierze przez przypadek (zapisałem się na kurs MOOC dotyczący Pharo, aby zdobyć doświadczenie z perspektywy ucznia, zanim objąłem rolę instruktora w ramach kursu MOOC dotyczącego badań powtarzalnych), odkryłem zupełnie inny rodzaj interaktywnego środowiska obliczeniowego. Rodzina Smalltalk, do której Pharo należy jako jeden z młodszych członków, ma długą historię doceniania możliwości eksploracji i zrozumiałości (więcej szczegółów znajdziesz w tym wpisie na blogu).
Szybko odkryłem również Glamorous Toolkit – nowe interaktywne środowisko built on Pharo, którego celem jest osiągnięcie jeszcze wyższego poziomu eksplorowalności dzięki narzędziom rozwoju moldable; idea polega na tym, że programiści powinni mieć możliwość rozszerzania środowiska o narzędzia inspekcyjne specyficzne dla danej dziedziny. Tło intelektualne tych idei zostało pięknie podsumowane we wpisie na blogu Rafaela Luque.
W porównaniu z obecnymi i przyszłymi środowiskami wszechświata Pharo, obliczeniowe notatniki wydają się bardzo ograniczone i krępujące. Nie jest to zresztą zaskakujące, biorąc pod uwagę ich genezę. Dzisiejsze Jupyter i RMarkdown to niewielkie wariacje na temat idei notatnika wprowadzonej na początku lat 80. XX wieku przez system Mathematica.
Mathematica z kolei, podobnie jak większość innych systemów algebry komputerowej, czerpała z dziedzictwa Lispa, który w latach 50. wprowadził do informatyki wiele rewolucyjnych funkcji, wśród nich interaktywność poprzez pętlę Read-Eval-Print (REPL). Był to naturalny sposób implementacji interakcji w ramach ograniczeń sprzętu interfejsu użytkownika tamtej epoki: terminala zorientowanego liniowo.
Smalltalk z drugiej strony narodził się w latach 70. wraz z wyświetlaczami graficznymi i urządzeniami wskazującymi od samego początku, kosztem zależności od sprzętu, do którego w tamtym czasie miało dostęp bardzo niewiele osób. Jak nauczył nas Marshall McLuhan, najpierw my kształtujemy nasze narzędzia, a potem one kształtują nas. Terminala zorientowane liniowo z lat 50. odcisnęły piętno na sposobie myślenia użytkowników komputerów, które nawet dzisiejsze notatniki obliczeniowe zachowały, mimo że superiorne podejścia istniały od dziesięcioleci.
Co więcej, tą superiorową technologią nie jest jedynie Smalltalk, który zawsze pozostawał niszowym systemem. Nieliniowe interfejsy GUI to coś, czego wszyscy używamy do pracy z plikami obrazowymi lub dźwiękowymi. Zadania te są niemal niemożliwe do wykonania linia po linii, dlatego nie były realne przed erą GUI.
W przypadku obliczeń GUI pojawiły się prawdopodobnie za późno: liniowe myślenie zdążyło już stać się normą kulturową. Edycja ActivePapers dla środowiska Pharo ma na celu przekształcenie środowiska GToolkit w platformę służącą do prowadzenia badań wspomaganych komputerowo, a nie do tworzenia oprogramowania. Te dwie działalności są odmienne, ale dzielą wiele wspólnych cech.
Główna różnica polega na tym, że nauka koncentruje się na danych i modelach, a oprogramowanie jest jedynie środkiem do celu. Jest to jednak środek tak ważny, że wszystko inne strukturyzuje się wokół niego.
Co więcej, rozwój oprogramowania również zajmuje się danymi (o oprogramowaniu) i modelami (jako specyfikacjami). Ostatecznie różnice mają charakter stopniowy, a nie fundamentalny. Ta podróż dopiero się rozpoczęła i nie wiem tak naprawdę, dokąd zaprowadzi. Bądźcie czujni na aktualizacje!
Tymczasem możecie obejrzeć ten film demonstracyjny. komentarze zasilane przez Disqus
Ucz się języka Python, kodując w przeglądarce
Interaktywne kursy Python i data science, które kodujesz bezpośrednio w przeglądarce