Die ActivePapers Pharo-Edition

Python-Edition JVM-Edition Pharo-Edition Blog … Bibliothek —> Die ActivePapers Pharo-Edition von Konrad Hinsen, veröffentlicht am 10. Mai 2019 Die ActivePapers-Familie hat ein neues Mitglied: die ActivePaper Pharo-Edition .

Im Gegensatz zur Python- und JVM-Edition, die weitgehend dieselben Ideen und Konzepte auf zwei verschiedenen Plattformen umsetzen, verfolgt die Pharo-Edition ein anderes Ziel: die Erforschung der Mensch-Computer-Schnittstelle für reproduzierbare, nachvollziehbare und überprüfbare computergestützte Forschung. Eine der häufigsten Fragen, die ich zur Python-Edition von ActivePapers erhielt, lautete: „Funktioniert das auch mit Jupyter Notebooks?” Meine erste Antwort war: „Noch nicht, aber ich arbeite daran.” Und das tat ich auch.

Allerdings führte diese Arbeit nie zu einem zufriedenstellenden Ergebnis. Ein Grund dafür waren technische Hindernisse. Ich hatte versucht, Jupyter Notebooks in ein ActivePaper zu integrieren, doch das erwies sich als unmöglich, da das Zweiprozess-Design von Jupyter (Kernel und Notebook-Editor sind separate Prozesse, die über ein Kommunikationsprotokoll verbunden sind) nicht mit der Einschränkung der HDF5-Bibliothek vereinbar ist, dass nur ein Prozess gleichzeitig in eine Datei schreiben darf.

Das bedeutet, man kann kein Notebook und die damit berechneten Ergebnisse in derselben HDF5-Datei speichern. Je mehr ich jedoch über die Integration von ActivePapers und Jupyter nachdachte, desto klarer wurde mir, dass lineare Notebooks (eine Abfolge aus Code-, Dokumentations- und Ergebniszellen) für die Dokumentation wissenschaftlicher Berechnungen – außer in einfachen Fällen – nicht wirklich geeignet sind. Wenn man sich die verschiedenen veröffentlichten ActivePapers ansieht, enthalten diese durchweg mehrere Skripte sowie einige Bibliotheksmodule.

Oberflächlich betrachtet könnte es scheinen, als könnten Notebooks die Skripte ersetzen und dadurch die Dokumentation liefern. Eine gute Dokumentation muss jedoch das Ganze dokumentieren, nicht nur einzelne Teile.

Sie muss mehrere Skripte und Code aus den Bibliotheksmodulen miteinander verknüpfen. Üblicherweise werden Rechenmethoden in den Bibliotheksmodulen implementiert, während die Skripte diese auf Datensätze anwenden. Wenn die Dokumentation skriptweise erfolgt, wie dokumentiert man dann die Methoden? Heute gibt es zahlreiche veröffentlichte Jupyter Notebooks – wie gehen diese damit um? Ich habe sie natürlich nicht alle geprüft, aber bisher habe ich den Eindruck, dass es zwei Fälle gibt.

Verwandte: DataCamp — Interaktive Python- und Data-Science-Kurse, bei denen Sie direkt im Browser programmieren.

Der häufigste Fall sind Notebooks, die Datenanalysen auf Basis standardisierter, bekannter Methoden dokumentieren, die in etablierten Bibliotheken implementiert sind. Von den Lesern wird erwartet, dass sie mit diesen Methoden vertraut sind oder sich anderweitig darüber informieren.

Der andere Fall sind Notebooks, die die vollständige Implementierung der Methode enthalten. Dieser Ansatz ist nicht nur auf einfache Methoden beschränkt, er hat zudem den großen Nachteil, dass die Methodenisierung nicht wiederverwendbar ist. Da sich meine eigene Forschung hauptsächlich auf die Entwicklung und Evaluierung neuer Rechenmethoden konzentriert, kam ich zu dem Schluss, dass Notebooks für meine Arbeit nicht geeignet sind. Tatsächlich war ich bereits durch praktische Versuche zu genau diesem Schluss gelangt.

Wann immer ich ein neues Projekt als Notebook begann, wechselte ich schnell zu modularem Code und Skripten im klassischen Stil, wobei die Dokumentation in separaten Textdateien erfolgte. Ich empfand dies als durchaus ausreichende Technik für meinen persönlichen Gebrauch, doch eine Ansammlung von Dateien – selbst wenn sie gut organisiert ist – lädt keinen anderen Wissenschaftler, nicht einmal einen Kooperationspartner, dazu ein, sich intensiv damit auseinanderzusetzen. Als ich vor einigen Monaten eher zufällig auf Pharo stieß (ich meldete mich für den Pharo-MOOC an, um aus Lernerperspektive MOOC-Erfahrungen zu sammeln, bevor ich im MOOC zur Reproduzierbaren Forschung die Rolle des Dozenten übernahm ), entdeckte ich eine völlig andere Art von interaktiver Computing-Umgebung.

Leserfavorit: Dataquest — Projektbasierte Data-Science-Pfade mit geführtem Terminal und realen Datensätzen.

Die Smalltalk-Familie, zu der Pharo als eines der jüngeren Mitglieder gehört, blickt auf eine lange Tradition zurück, in der Erkundbarkeit und Nachvollziehbarkeit hoch geschätzt werden (weitere Details finden Sie in diesem Blogbeitrag ). Kurz darauf entdeckte ich das Glamorous Toolkit , eine neue interaktive Umgebung, die auf Pharo aufbaut und durch formbare Entwicklungswerkzeuge (moldable development tools) noch höhere Erkundbarkeit anstrebt. Die Idee dahinter: Entwickler sollten die Umgebung mit domänenspezifischen Inspektionswerkzeugen erweitern können.

Den intellektuellen Hintergrund dieser Ideen hat Rafael Luque in einem Blogbeitrag anschaulich zusammengefasst. Verglichen mit den aktuellen und zukünftigen Umgebungen des Pharo-Universums wirken rechnerische Notebooks sehr begrenzt und einschränkend.

Das ist angesichts ihrer Herkunft kaum überraschend. Die heutigen Systeme Jupyter und RMarkdown sind lediglich geringfügige Variationen der Notebook-Idee, die Anfang der 1980er-Jahre von Mathematica eingeführt wurde. Mathematica wiederum baute – wie die meisten anderen Computeralgebrasysteme – auf dem Erbe von Lisp auf, das in den 1950er-Jahren viele revolutionäre Merkmale in die Informatik einbrachte. Dazu gehörte die Interaktivität mittels Read-Eval-Print-Loop (REPL), eine natürliche Möglichkeit, Interaktion innerhalb der damaligen Einschränkungen der Benutzerschnittstellen-Hardware umzusetzen: zeilenorientierte Terminals.

Smalltalk hingegen startete in den 1970er-Jahren von vornherein mit grafischen Displays und Zeigegeräten – zum Preis einer Abhängigkeit von Hardware, die damals nur wenigen Menschen zugänglich war. Wie Marshall McLuhan uns lehrte: Zuerst formen wir unsere Werkzeuge, dann formen unsere Werkzeuge uns.

Die zeilenorientierten Terminals der 1950er-Jahre haben eine Denkweise bei Computernutzern geprägt, die selbst heutige rechnerische Notebooks beibehalten haben, obwohl seit Jahrzehnten überlegene Ansätze verfügbar sind. Und diese überlegene Technologie ist nicht nur Smalltalk, das stets ein Nischensystem geblieben ist. Nicht-lineare grafische Benutzeroberflächen nutzen wir alle täglich für die Arbeit mit Bildern oder Audiodateien. Diese Aufgaben wären zeilenweise kaum lösbar; sie wurden erst durch GUIs möglich.

Für Berechnungen kamen GUIs wahrscheinlich zu spät: Lineares Denken war bereits zur kulturellen Norm geworden. Die Pharo-Edition von ActivePapers zielt darauf ab, die GToolkit-Umgebung so zu gestalten, dass sie nicht primär der Softwareentwicklung dient, sondern der computergestützten Forschung. Diese beiden Aktivitäten sind unterschiedlich, teilen jedoch viele Gemeinsamkeiten.

Verwandte: Udemy — Kaufen Sie einzelne wissenschaftliche Python-Kurse direkt, oft mit erheblichen Rabatten.

Der Hauptunterschied liegt darin, dass die Wissenschaft sich auf Daten und Modelle konzentriert, wobei Software lediglich ein Mittel zum Zweck ist. Dennoch ist dieses Mittel so wichtig, dass alles andere darum herum strukturiert wird. Zudem beschäftigt sich auch die Softwareentwicklung mit Daten (über Software) und Modellen (als Spezifikationen).

Letztlich sind die Unterschiede graduell, nicht fundamental. Diese Reise hat gerade erst begonnen, und ich weiß noch nicht genau, wohin sie führen wird. Bleiben Sie dran für Updates!

In der Zwischenzeit können Sie sich dieses Demo-Video ansehen . Kommentare bereitgestellt von Disqus