ActivePapers Pharo エディション

ActivePapers Pharo 版（Konrad Hinsen 著、2019 年 5 月 10 日公開）ActivePapers ファミリーに新しい仲間が加わりました。それが「ActivePapers Pharo 版」です。Python 版と JVM 版が主に同じアイデアと概念を異なるプラットフォーム上で実現しているのに対し、Pharo 版は異なる目標を掲げています。それは、再現可能で理解しやすく検証可能なコンピュータ支援研究における、人間とコンピュータのインタフェースを探求することです。

ActivePapers の Python 版について最も頻繁に寄せられた質問の一つは、「Jupyter ノートブックでも動作しますか？」というものでした。当初私の答えは「まだですが、現在取り組んでいます」でした。そして実際に取り組んだのです。しかし、その作業は満足できる結果には至りませんでした。一つ目の理由は技術的な障壁です。ActivePaper の内部に Jupyter ノートブックを組み込もうと試みましたが、これは不可能であることが判明しました。Jupyter は 2 プロセス設計（カーネルとノートブックエディタが通信プロトコルで接続された別々のプロセス）を採用しており、これが HDF5 ライブラリの「同時に書き込み可能なプロセスは一つのみ」という制約と相容れなかったためです。つまり、ノートブックとその計算結果を同じ HDF5 ファイル内に格納することはできないのです。

しかし、ActivePapers と Jupyter の統合について考えるほどに、線形なノートブック（コード、ドキュメント、結果のセルが順に並んだもの）は、単純なケースを除き、科学計算を文書化する任務には本質的に向いていないことに気づきました。これまでに公開された各種の ActivePapers を見てみると、 invariably 複数のスクリプトといくつかのライブラリモジュールで構成されています。表面的には、ノートブックがスクリプトを置き換え、それによってドキュメントを提供できるように見えるかもしれません。しかし、優れたドキュメントとは、部分ではなく全体を記述するものです。複数のスクリプトやライブラリモジュールからのコードを結びつける必要があります。通常、計算手法自体はライブラリモジュールに実装され、スクリプトがそれをデータセットに適用します。もしドキュメントがスクリプトごとに作成されるなら、手法そのものをどのように記述すればよいのでしょうか？

今日では多数の Jupyter ノートブックが公開されていますが、彼らはこの問題をどう扱っているのでしょうか？もちろんすべてを見たわけではありませんが、これまでのところ私の印象では、大きく分けて二つのケースがあります。最も頻繁に見られるのは、よく知られたライブラリに実装された標準的で周知の手法に基づくデータ解析を記述したノートブックです。こうしたノートブックの読者は、その手法について既に熟知しているか、あるいは他の場所で学ぶことを前提としています。もう一つのケースは、手法の実装そのものを完全に含めたノートブックです。これは単純な手法に限定されるだけでなく、大きな欠点として、その手法の実装が再利用できないという問題を抱えています。

私自身の研究は主に新しい計算手法の開発と評価に焦点を当てているため、ノートブックは私の仕事には適合しないと結論づけました。事实上、試行錯誤する過程で同じ結論に至っていたのです。新しいプロジェクトをノートブックとして始めたとしても、すぐに従来のモジュールとスクリプトの形式に戻し、ドキュメントは別テキストファイルで作成していました。この方法は個人的な用途としては十分に機能していましたが、たとえ整然と整理されていたとしても、単なるファイルの集合体は、共同研究者を含む他の科学者が積極的に調べたいと思わせるものではありません。

数ヶ月前、偶然にも Pharo に触れる機会がありました（Reproducible Research MOOC で講師を務める前に、学習者の立場から MOOC の経験を積むため、Pharo MOOC に登録したのがきっかけです）。そこで、まったく異なる種類の対話型計算環境を発見しました。Pharo もその一員である Smalltalk ファミリーは、長年にわたり「探求可能性」と「理解しやすさ」を重視してきました（詳細についてはこのブログ投稿をご覧ください）。さらにすぐさま、Glamorous Toolkit という新たな対話型環境に出会いました。これは Pharo を基盤とし、ドメイン固有の検査ツールを環境自体に拡張できるようにする「モールドブル開発ツール」を通じて、さらに高いレベルの探求可能性を目指しています。これらのアイデアの知的背景については、Rafael Luque によるブログ投稿で簡潔にまとめられています。

関連: DataCamp — ブラウザーで直接コーディングするインタラクティブな Python およびデータ サイエンス コース.

現在の、そして将来の Pharo ユニバースの環境と比較すると、計算用ノートブックは非常に限定的で制約が多いと感じられます。これはその起源を考えれば決して驚くべきことではありません。今日の Jupyter や RMarkdown は、1980 年代初頭に Mathematica が導入したノートブックのアイデアのわずかな変種に過ぎません。Mathematica 自体も、他の多くの数式処理システム同様、Lisp の遺産の上に成り立っています。Lisp は 1950 年代にコンピューティングに数々の革命的な特徴をもたらしましたが、その中には Read-Eval-Print Loop（REPL）を通じた対話性も含まれていました。これは当時のユーザーインターフェースハードウェアの制約（行指向ターミナル）の中で対話を実現するための自然な方法でした。

一方、Smalltalk は 1970 年代からグラフィカルディスプレイとポインティングデバイスを最初から備えてスタートしました。ただし、当時そうしたハードウェアにアクセスできた人はごく少数に限られていたという代償がありました。マーシャル・マクルーハンが教えたように、「我々が道具を形作り、その後道具が我々を形作る」のです。1950 年代の行指向ターミナルは、コンピューター利用者にある思考様式を刻み込みました。それは、数十年にわたり優れたアプローチが存在していたにもかかわらず、今日の計算用ノートブックにもなお残っている思考様式です。そして、その優れた技術とは単にニッチなシステムであり続けた Smalltalk だけではありません。非線形な GUI は、画像や音声ファイルを扱う際に誰もが使用しているものです。これらの作業を行単位で遂行するのはほぼ不可能であり、GUI が登場するまで本格的には行われませんでした。計算においては、GUI の登場はおそらく遅すぎたのでしょう。線形的思考がすでに文化的規範となっていたからです。

ActivePapers の Pharo 版は、GToolkit 環境をソフトウェア開発のためではなく、コンピュータ支援研究を行うための環境へと成形することを目指しています。これら二つの活動は異なりますが、多くの共通点を共有しています。主な違いは、科学がデータとモデルに焦点を当て、ソフトウェアはあくまで手段に過ぎない点です。しかし、その手段は極めて重要であり、他のすべての要素がそれを中心に構成されています。さらに、ソフトウェア開発もまた、データ（ソフトウェアに関するデータ）とモデル（仕様としてのモデル）を扱います。結局のところ、両者の違いは根本的というよりは漸進的なものです。

読者のお気に入り: Dataquest — ガイド付きターミナルと実際のデータセットを使用したプロジェクトベースのデータ サイエンス パス.

この旅はまだ始まったばかりであり、どこへ向かうのか私自身もはっきりとはわかりません。今後の更新情報にご期待ください！それまでは、こちらのデモ動画をご覧ください。comments powered by Disqus