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