可重复研究的通用动态文档(IPython笔记本样式)方法通常不会产生可重用的源代码模块。是否存在使用源代码作为主要媒介并在其中包含文本以使代码更可重用的工具/方法?
我非常喜欢使用动态文档/笔记本进行可重复研究的概念。特别是在数据研究和分析方面,它很有意义,可以方便地记录和评论分析过程。我通常使用Emacs Org-mode和/或IPython笔记本/内核,它集成得非常好。我还看了R及其类似物(ESS,knitr)。
但是,通常这些文档由一系列预期按顺序执行的代码块组成。当纠结(源代码提取)时,生成的源代码通常不能轻易地作为模块或库重用。
然而,我经常想“哦,我希望我可以使用我几天前所做的分析的特定部分”。事实证明,由于隐式依赖性,我必须在有趣的部分之前执行大多数单元格。通常也不容易包括编织文档的特定部分。即使它是(使用Org-mode的#+INCLUDE
指令或LaTeX catchfilebetweentags),通常不同的段落也不是自包含的。当然,我可以复制和编辑以前的分析文档并复制/粘贴/传输相关部分。但这有点挫败了目的。
常见的动态笔记本方法鼓励代码开发的“线性”风格,即代码块按顺序执行,文本段落遵循通常线性叙述,因此通常不是自包含的。这通常导致可重复使用的纠结代码和编织(文本文档输入)文本文档。
到目前为止,我提出了解决这些问题的一些想法。
经过一段时间后,我得出的结论是,上述问题源于散文/文本文件是主要媒介。这种带有偶尔图形和表格的文本文件本质上是对某些叙述的线性描述。而且我认为这是鼓励“过于线性”的风格。
如果源代码是主要媒介,那么不同的声明/定义从一开始就可以是模块化的,它们的文档/解释可以是自包含的。然后,主文档可以根据所需的叙述选择相关部分。在某些方面,这非常接近于如何在Python中使用文档字符串以及使用Sphinx提取和处理文档字符串。绘图,表格和值生成序列可以是测试套件或示例代码的一部分。
然而,与常规方法相比,这种方法限制了交互性。大多数交互式工作都是在创建和调试单元测试或示例时完成的。并不是令人鼓舞的写作单元测试和示例是一件坏事,但它可能比例如快速测试/原型设计慢。 IPython的。另一方面,它会更加一致,也许更易于管理。
文学编程密切相关,但不鼓励这种“过于线性”的方法,例如: noweb样式引用使得不那么“线性”和更模块化的样式非常可能。但它并没有鼓励它。
然而,它通常只有在完全纠结时才能正常工作。此外,它不适合交互式使用。另外,散文块不能像代码块一样被引用,因此文本方面仍然是“线性的”。