17

问候。我现在一直在看文学编程，我确实喜欢它背后的想法：你基本上写了一篇关于你的代码的小论文，并写下尽可能多的设计决策，代码可能围绕模块，内部工作由设计决策、潜在扩展产生的模块、假设和结论，所有这些都可以使用 tex 以一种很好的方式写下来。当然，第一点：它是文档。它必须保持最新，但这不应该那么糟糕，因为你的改变应该有一个理由，你可以把它写下来。

但是，文学编程如何在更大程度上扩展？总的来说，文学编程仍然只是文本。当然，文本是人类可读的，但仍然是文本，因此很难遵循大型系统。例如，我修改了编译器的大部分以使用 >> 和一些魔法将编译步骤链接在一起，因为一些 "x.register_follower(y); y.register_follower(z); y.register_follower(a);... " 变得非常笨拙，将其更改为 x >> y >> z >> a 使它变得更好一些，即使这也处于临界点。

那么，文学编程如何扩展到更大的系统？有人尝试这样做吗？

我的想法是使用 LP 来指定使用事件流相互通信的组件，并使用 graphviz 的子集将所有这些链接在一起。这将是 LP 的一个相当自然的扩展，因为您可以从网络中提取文档——数据流图——并且还可以很好地从中生成代码。你怎么看呢？

——特萨。

4

9 回答 9

8

“基于物理的渲染”一书（pbrt.org）是我所知道的大规模读写编程的最佳示例。本书实现了一套完整的渲染系统，书本和光线追踪代码都是从同一个“源”生成的。

在实践中，我发现仅仅使用像 Doxygen 这样的系统并真正深入挖掘并利用它的所有功能比完全成熟的“文学”编程要好，除了诸如教科书、教育材料之类的东西。

于 2008-11-18T16:14:20.870 回答
4

很好的问题。文学编程的动机永远不会消失，但我认为它应该被视为流动的。它的意思是“让读者休息一下，并教育他们你正在尝试做的事情”。我不认为这意味着“让你的代码真的很罗嗦”。

也就是说，读者将不得不付出一些努力，这取决于他们已经知道的内容。大概代码是值得理解的，没有什么是免费的。

我也认为这不仅仅意味着编写可读的代码。某人阅读代码的原因很可能是因为他们需要进行更改。您应该预测可能需要的更改，并在必要时告诉他们如何进行。

于 2008-11-18T15:52:37.357 回答
4

大约 15 年前，我使用 WEB 进行了一些文学编程。最近，我尝试从 wiki 提取代码并从 Squeak Smalltalk 环境生成文档。

自下而上的部分可以通过从 TDD/BDD 框架生成文档来处理得比较好，但 LP 侧重于向读者解释代码。

有几个问题：

  • 对于不同的利益相关者/读者来说，要讲述的故事是不同的；
  • 大多数环境中的项目结构不是讲故事所需的结构；
  • 缺少对连续改进/披露的支持；
  • 除了需要对图片的文字支持；
  • 从源代码控制系统中的注释可以得出系统是如何构建的。故事应该是系统是如何构建的（事后看来）。

要使 LP 用于更大的系统，您需要比 wiki 或对象浏览器更好的 IDE 支持。

于 2008-11-18T16:38:36.780 回答
4

“总的来说，文学编程仍然只是文本”

错误的。

图表很好。

我的想法是使用 LP 来指定使用事件流相互通信的组件

这只是建筑，这很好。

你可以从网上提取一个文档——一个数据流图——也可以很好地从中生成代码。你怎么看呢？

数据流图对于生成详细的代码并没有那么大的帮助。它们是方便的摘要，而不是精确的信息来源。

一个好的书写工具（如 LaTex）可以在文档中对图表进行编码。您可能可以从文档的其他部分找到一种方法。

底线

从长远来看，您最好生成图表作为文本的摘要。

为什么？

图表故意省略了细节。图表是摘要或概述。但是作为代码的来源，图表很糟糕。为了提供所有细节，图表变得非常混乱。

但是其他一些 LP 标记的图表总结会很好。

于 2010-03-31T10:38:43.663 回答
3

pbrt是一个基于物理的光线追踪器，以文学风格编写，用于计算机科学毕业生（和我）的教育，它是一个中等规模的系统。作为非专业程序员，这一级别的文档对于理解程序做什么以及为什么这样做是非常重要的。

我还可以使用 Java 中的研究渲染器，它写得很好，但相对没有文档，但有一些 SIGGRAPH 论文。这也是相对可以理解的，但我也可以接触到作者。

我也经常使用ImageJ，并在底层 Java 的底层进行了研究——如果不了解底层哲学，就很难理解。

总而言之，我的观点是，如果有人能抽出时间把它做好，那么识字编程是很棒的，这很可能是在教育环境中。很难看到它在商业代码生产中完成。我对代码可以完全自我记录的想法持怀疑态度。

于 2008-11-18T16:18:37.927 回答
3

文学编程背后的想法是强调文档，代码散布在文档中，而不是注释散布在代码中。

这是一种本质上不同的理念，更长的变量名、命名空间和类等差异不会影响理念。文学编程提倡有意义的变量名。

它可以扩展到更大的系统，因为文档与代码的基本比例与代码大小成线性关系。

于 2010-01-11T02:48:57.407 回答
1

12.5年后，终于有了一些有希望的发展。GToolkit提供了集成的多个视图、入口点和工具来做好文学编程。

于 2021-03-11T11:09:48.730 回答
0

文学编程是在一个根本不可能长变量和函数名称的时代发展起来的。正因为如此，代码真的不那么可读。

显然，从那以后发生了很多事情。

在当今世界，代码本身就是文档，因此称为“自文档化代码”。实现是没有一组注释或外部文档可以与底层代码保持同步。因此，当今许多程序员的目标是以其他人可读的方式编写代码。

于 2008-11-18T15:41:02.933 回答
0

Try NanoLP - LP 可扩展工具，支持多种文档格式（Markdown、OpenOffice、Creole、TeX、Asciidoc 等）、导入其他 LP 程序、模板等。用户可以添加自己的命令/宏（在 Python 中），例如进行特殊导入，例如从 VCS... http://code.google.com/p/nano-lp

于 2013-01-24T06:46:01.943 回答