TL;DR:
再現可能な研究に対する一般的な動的ドキュメント (IPython ノートブック スタイル) アプローチは、通常、再利用可能なソース コード モジュールにはなりません。コードをより再利用可能にするために、ソース コードを主要な媒体として使用し、その中にテキストを含めるツール/アプローチはありますか?
一般的な動的ドキュメント アプローチの問題点
動的なドキュメントやノートブックを使用した再現可能な研究のコンセプトがとても気に入っています。特にデータの調査と分析では、分析プロセスが発生したときに文書化してコメントするのが便利です。私は通常、Emacs Org-mode および/または IPython ノートブック/カーネルを使用しており、非常によく統合されています。また、R とその類似物 (ESS、knitr) も調べました。
ただし、通常、これらのドキュメントは、順番に実行される一連のコード ブロックで構成されています。もつれていると (ソース コードの抽出)、結果のソース コードは通常、モジュールまたはライブラリとして簡単に再利用できません。
それでも、「ああ、数日前に行った分析の特定の部分を使用できたらいいのに」と思うことがよくあります。通常、暗黙的な依存関係のために、興味深い部分の前にほとんどのセルを実行する必要があることがわかります。通常、織り上げられた文書の特定の部分だけを含めることも容易ではありません。そして、それが (Org-mode の#+INCLUDEディレクティブまたは LaTeX catchfile betweentags を使用して) あったとしても、通常、異なる段落は自己完結型ではありません。もちろん、以前の分析ドキュメントをコピーして編集し、関連する部分をコピー/貼り付け/転送することもできます。しかし、それはちょっと目的を破ります。
要約する：
一般的な動的ノートブック アプローチは、「線形」スタイルのコード開発を促進します。つまり、コード チャンクを順番に実行し、テキスト パラグラフは通常線形の物語に従うため、通常は自己完結型ではありません。これは通常、ひどく再利用可能な複雑なコードと織り込まれた (テキスト ドキュメント入力) テキスト ドキュメントをもたらします。
可能な解決策を探しています
これまでに思いついたこれらの問題を解決するためのアイデアをいくつか紹介します。
主要な媒体としてのソース コード
しばらくして、上記の問題は散文/テキスト文書が主要な媒体であることに起因するという結論に達しました。時折図や表を含むこのようなテキスト文書は、その性質上、何らかの物語の直線的な記述です。そして、これが「直線的すぎる」スタイルを助長していると思います。
ソース コードが主要な媒体である場合、さまざまな宣言/定義を最初からモジュール化し、それらのドキュメント/説明を自己完結型にすることができます。マスター ドキュメントは、必要な説明に従って、関連する部分だけを選択できます。いくつかの点で、これは Python で docstring が使用され、Sphinx で抽出および処理される方法に非常に似ています。プロット、テーブル、および値の生成シーケンスは、テスト スイートまたはサンプル コードの一部にすることができます。
ただし、このアプローチは、一般的なアプローチと比較して対話性を制限します。インタラクティブな作業のほとんどは、単体テストまたはサンプルの作成およびデバッグ中に行われます。単体テストと例を書くことを奨励することは悪いことではありませんが、IPython などでの迅速なテスト/プロトタイピングよりも遅くなる可能性があります。その一方で、より一貫性があり、おそらくより管理しやすいでしょう。
nowebの力を利用した「ノンリニア」な文芸的プログラミングスタイル
文芸的プログラミングは密接に関連していますが、この「直線的すぎる」アプローチを推奨するものではありません。しかし、それはそれを奨励しません。
ただし、通常、完全に絡み合っている場合にのみうまく機能します。また、インタラクティブな使用には向いていません。さらに、散文ブロックはコード ブロックのように参照できないため、テキストの側面は依然として「線形」です。
私の質問
- ソース コードを主要な媒体として、そのようなアプローチを使用している人はいますか?
- このようなアプローチを使用して、以前のレポートを新しいレポートで再利用することに成功した人はいますか?
- それとも、「非線形」の noweb の力が進むべき道なのでしょうか?