nbdev:探索的プログラミングをPythonで実現する開発環境(2/4)

１．nbdev:探索的プログラミングをPythonで実現する開発環境(2/4)まとめ

・ソフトウェア開発手法がウォータフォールからアジャイルに代わってもツールはあまり変化がない
・プログラミングに関する優れたアイディアは過去に幾つか発案されたが完全に実現された実装がない
・インタラクティブ開発はJupyter Notebookが優れているが教育用途以外では著者も使っていない

２．ソフトウェア開発の進化の歴史

以下、www.fast.aiより「nbdev: use Jupyter Notebooks for everything」の意訳です。元記事は2019年12月2日、Jeremy Howardさんによる投稿です。アイキャッチ画像のクレジットは(Photo by Simon English on Unsplash)

ソフトウェア開発ツールの歴史
ほとんどのソフトウェア開発ツールは、探索的プログラミングが思考の基盤になる事を念頭においていません。私がコーディングを始めた約30年前、ソフトウェア開発手法はウォーターフォール開発が主流でした。ウォーターフォールは、言葉の通り水が流れるように、ソフトウェアシステム全体を詳細に事前に定義し、可能な限り仕様に近い形に段階的にコーディングしていくアプローチです。しかし、私が実際に作業を行う際のやり方にはまったく適合していないアプローチであるように思えました。

しかし、1990年代には状況が変わり始めました。アジャイル開発が一般的になりました。人々は、ほとんどのソフトウェア開発が反復プロセスであるという現実を理解し始め、この事実を尊重する作業方法として反復的な開発手法を見出しました。

ただし、使用するソフトウェア開発ツールに大きな変更はなく、開発作業の進め方が大きく変更された現実に追随できていませんでした。もちろん、私たちの武器庫に新たに追加されたいくつかのツールは存在し、特にテスト駆動開発をより簡単に行えるようにする事に関しては改善がありました。しかし、このツールは、開発環境がどのようにあるべきかを真に再考したのではなく、既存のエディターおよび開発環境に対するマイナーな拡張として実装される傾向がありました。

近年、アジャイル開発ツールボックスの重要なパーツとして、探索的試験への関心が高まってきています。私達はこのトレンドに絶対的に同意します！しかし、私達はまた、これだけでは満足するレベルには到達しないと思います。私たちは、ソフトウェア開発プロセスのほぼすべてのプロセスで、探索的作業が核心部であると考えています。

伝説的なプログラマーであるドナルド・クヌースは時代をはるかに超えていました。

彼は物事を非常に異なった観点から見る事を望んでいました。1983年に、彼は文芸的プログラミング(literate programming)と呼ばれる方法論を開発しました。

彼は文芸的プログラミングを以下のように表現しています。

「プログラミング言語とドキュメンテーション言語を組み合わせた方法論であり、それにより、高レベルプログラミング言語のみで書かれたプログラムよりも、プログラムをより堅牢で、移植しやすく、保守しやすく、間違いなくするため、プログラムを書くのが楽しくなります。主なアイデアは、プログラムを文学作品として扱うことです。コンピューターではなく人間を対象とするのです。」

長い間、私はこのアイデアに魅了されましたが、残念なことに、広まりませんでした。このアプローチで使用できるツールを使ったソフトウェア開発は非常に長い時間がかかり、このトレードオフに価値があると判断した人はほとんどいなかったのです。

ほぼ30年後、別の優秀で革新的な思想家であるBret Victorが、現世代の開発ツールに対する深い不満を表明し、「プログラムを理解するためのプログラミングシステム」のデザイン手法を発表しました。

彼は画期的なスピーチ「Inventing on Principle」で述べました。

「コンピュータープログラムとは、コンパイラに渡すための定義をテキストで書いたリストです。これは、1950年代後半にFORTRAN言語とALGOL言語から直接派生したものです。これらの言語は入力をパンチカード(訳注：厚手の紙に穴を開けて、その位置や有無で情報を記録する記録媒体。マークシート的なイメージで、ディスクやテープがなかった頃のご先祖様的な媒体)で与えられる事を想定して設計されました。」

彼は、プログラミングシステムを設計するための一連の新しい原則を、完全に機能する事例で説明しました。まだ誰も彼のアイデアの全てを完全に実装していませんが、そのアイディアのいくつかの部分を実装しようとするいくつかの重要な試みがありました。

おそらく、最も有名で完全な実装は、Chris LattnerのSwiftとXcode Playgroundsです。これらは中間結果(intermediate results)のインライン表示を実装に含んでいます。

Xcode Playgroundsのデモ

これは大きな前進ですが、探索的作業を念頭に置いていない開発環境内に留まっているという基本的な制限によって、依然として非常に制約されています。例えば、これによって探索的プロセスはまったく記録できず、テストを直接統合することはできず、文芸的プログラミングの完全で豊かなビジョンを実装することはできていません。

インタラクティブなプログラミング開発環境の歴史
ソフトウェア開発には、インタラクティブプログラミング(及びライブプログラミング)という別の非常に異なった方向性があります。それは何十年も前にLISPとForth REPLで始まりました。開発者は実行中のアプリケーションに対してインタラクティブにコードを追加および削除することができます。Smalltalkは更にアイディアを発展させ、完全にインタラクティブで視覚的なワークスペースを提供します。

上記事例では言語自体の特性がこの種のインタラクティブな作業に適していました。例えば、LISPのマクロシステムや「データとしてのコード(code as data)」基盤などです。

Smalltalkを使ったライブプログラミング(1980年)

このアプローチは、現在の通常のソフトウェア開発ではあまり一般的な方法ではありませんが、科学、統計、その他のデータ駆動型プログラミングの多くの分野では最も一般的なアプローチです。(しかし、JavaScriptフロントエンドプログラミングは、ホットリロードやブラウザ内ライブ編集など、これらのアプローチからのアイデアをますます取り入れています。)

例えば、Matlabは1970年代に完全にインタラクティブなツールとして始まり、今日でもエンジニアリング、生物学、およびその他のさまざまな分野で広く使用されています。(最近は通常のソフトウェア開発機能も提供しています)。

同様のアプローチがS-PLUS、及びS-PLUSのオープンソースの親戚Rで採用され、現在は統計およびデータ視覚化コミュニティ内で非常に人気があります。

私は約25年前にMathematicaを初めて使用したときに特に興奮しました。Mathematicaは、生産性を損なうことなく、最も丁寧に文芸的プログラミングをサポートするツールに見えました。

従来のREPLによく似た「ノートブック」インターフェースを使用していましたが、チャート、画像、書式設定されたテキスト、アウトラインセクションなど、他の種類の情報も含めることができました。

実際、生産性に妥協しなかっただけでなく、アルゴリズムを試してすぐに非常に視覚的な方法でフィードバックを得ることができたので、従来は自分の能力を超えていたものも構築できるようになりました。

最終的には、Mathematicaを使用してコードやアプリケーションを同僚に配布できなかったため(Mathematicaライセンスを使用するために数千ドルを費やした場合を除き)、Mathematicaを使用しても有用なものを構築する事はできませんでした。また、ユーザーがブラウザからアクセス可能なWebアプリケーションも簡単には作成できませんでした。更に、私のMathematicaコードは他の言語で書いたコードよりもはるかに遅く、より多くのメモリを必要とする場合が多い事もわかりました。

以上の経緯により、あなたはJupyter Notebookが登場したときの私の興奮を想像できると思います。

これはMathematicaと同じ基本的なノートブックインターフェースを使用してました。(ただし、最初は機能の小さなサブセットの集まりでした。)しかし、オープンソースであり、広くサポートされて自由に利用できるプログラミング言語で書くことができました。

私はJupyterを、アルゴリズム、API、および新しい研究アイデアの探索だけでなく、fast.aiの教育ツールとしても使用しています。多くの学生にとっても、入力を実験し、中間結果と出力を表示し、独自の修正を試す事が出来るJupyterの能力が、議論されているトピックをより深く理解するのに役立つ事を発見しました。

私達はまた、Jupyter Notebooksを使用して完全な本(訳注：「Deep Learning for Coders with fastai and PyTorch: AI Applications Without a PhD」O’Reillyより2020年7月14日に英語版が出版予定)を書いています。これは絶対的な喜びであり、文章、コード例、階層構造の見出しなどを組み合わせながら、サンプル出力(チャート、テーブル、画像を含む)が常にコードと正しく一致する事を確実にする事ができます。

要するに、私たちはJupyter Notebookの使用を本当に楽しんでおり、それを使ってすばらしい仕事をしており、生徒たちもそれを気に入っているのです。しかし、本の執筆や学習用教材としてはJupyter Notebookを使用していても、私達が自分達のソフトウェアを開発する際に実際にJupyter Notebookを使用していないと言う事実は、とても残念なことのように思えたのです！