logo标签列表

扩展文学编程？

methodologyliterate-programming
18
问候。 我现在正在研究文学编程，我很喜欢它背后的想法：你基本上写一篇关于代码的小论文，并写下大量设计决策、可能涉及到模块的代码、模块内部的工作原理、设计决策产生的假设和结论、潜在扩展，所有这些都可以使用tex以美好的方式写下。当然第一点是文件说明，必须保持最新状态，但这应该不会太糟糕，因为你的更改应该有一个理由，你可以写下来。
然而，文学编程如何扩展到更大的程度呢？总体而言，文学编程仍然只是文本。当然非常容易阅读，但仍然是文本，因此很难跟踪大型系统。例如，我重新设计了编译器的许多部分，使用>>和一些魔法将编译步骤链接在一起，因为一些"x.register_follower(y); y.register_follower(z); y.register_follower(a);..."变得非常难处理，而将其更改为x >> y >> z >> a使它稍微好一些，尽管这也到了临界点。
那么，文学编程如何扩展到更大的系统？有人试图做到这一点吗？
我的想法是使用LP指定彼此使用事件流进行通信的组件，并使用graphviz的子集将所有这些组件链接在一起。这将是对LP的一个相当自然的扩展，因为你可以从网络中提取说明--数据流图--并且也可以很好地从中生成代码。你觉得呢？
-- Tetha.
另请参见https://dev59.com/lnVC5IYBdhLWcg3wqzHV - Steven A. Lowe
我觉得有些答案把文学编程和流畅编程混淆了。只是这样说... - Benjol
1
Er，Knuth提出文学编程的动机一直是帮助他扩展规模：他用它编写了两个相当庞大的程序（TeX和METAFONT），甚至将TeX：The Program出版成了一本书。您可以根据需要进行少量或更多的注释；文学编程的重点在于能够按适合阐述的顺序编写它。 - ShreevatsaR
9个回答
8
《基于物理的渲染》（Physically Based Rendering）(pbrt.org) 这本书是我所知道的大规模文学编程的最佳示例。这本书实现了一个完整的渲染系统，书中的文本和光线追踪器代码都是从同一“源”生成的。
在实践中，我发现仅使用像Doxygen这样的系统并真正深入研究和利用其所有功能比全面的“文学”编程更好，除了像教科书、教育材料之类的东西。
4

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

错误。

图表是可以的。

我的想法是使用LP指定彼此使用事件流通信的组件

那只是架构，没问题。

您可以从网络中提取文档 - 数据流程图 - 并从中生成代码。你怎么看？

数据流程图并不真正有助于生成详细的代码。它们是方便的概要，而不是精确的信息来源。

良好的写作工具（如LaTex）可以将图表编码到文档中。您可能可以通过其他部分的文档找到图表的方法。

底线

从长远来看，将图表生成为文本的摘要更好。

为什么？

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

但是对于其他LP标记的图表式摘要，效果很好。

4
优秀的问题。文学编程的动机永远不会消失，但我认为它应该被视为流动的。它的意思是“给读者一个休息，并让他们了解你想做什么”。我不认为这意味着“让你的代码变得非常冗长”。
话虽如此，读者将需要付出一些努力，这取决于他们已经知道什么。可以假设代码值得理解，但没有什么是免费的。
我还认为它的意义不仅在于制作易读的代码。最有可能的原因是某人正在阅读代码是因为他们需要进行更改。您应该预见可能需要的更改，并在必要时告诉他们如何操作。
文学编程并不意味着“使你的代码变得非常啰嗦”——例如，如果您看一下[Knuth的程序]（http://www-cs-faculty.stanford.edu/~uno/programs.html），你需要在.w文件上运行cweave以获取.tex文件，然后再使用[pdf]tex将其转换成ps/pdf，其中有相当多的程序文档相对较少。只有一个顶层段落，后面是几个带编号的代码块（“chunks”）。真正的好处在于能够以任何顺序编写代码。 - ShreevatsaR
4

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

自下而上的部分可以通过从TDD/BDD框架生成文档来相对轻松地处理，但是LP侧重于向读者解释代码。

存在一些问题：

  • 要讲述的故事因不同的利益相关者/读者而异；
  • 大多数环境中的项目结构不是讲故事所需的结构；
  • 缺少连续改进/透明度支持；
  • 除了文本之外，还需要图片支持；
  • 通过源代码控制系统中的注释可以推导出系统的构建方式。故事应该是如何构建系统（具有完美的预见性）。

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

3

文学编程的理念是强调文档，代码散布在文档中，而不是注释散布在代码中。

这是一种本质上不同的哲学，如变量名更长、命名空间和类等差异并不影响这种哲学。文学编程主张有意义的变量名。

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

3

pbrt 是一款基于物理的光线追踪器，以文学风格编写，用于计算机科学毕业生（和我）的教育，它是一个中等规模的系统。对于非专业程序员来说，这种程度的文档对于理解程序的功能及其原因非常重要。

我还使用过一款名为Java的研究渲染器，它写得很好，但相对缺乏文档，只有几篇SIGGRAPH论文。这也相对容易理解，但我也可以联系到作者。

我还经常使用ImageJ，并查看底层Java的实现 - 如果没有底层哲学的概念，这将会非常困难。

总之，我认为文学编程很棒，如果有人能抽出时间好好做的话，这可能会在教育环境中发挥作用。很难想象它会在商业代码生产中被广泛采用。我对代码完全自我记录的想法持怀疑态度。

1
12.5年后，终于出现了一些有希望的进展。GToolkit 提供了集成的多个视图、入口和工具，可以很好地进行文学化编程。
0
尝试使用NanoLP - LP可扩展工具，支持多种文档格式（Markdown、OpenOffice、Creole、TeX、Asciidoc等），导入其他LP程序、模板等。用户可以添加自己的命令/宏（使用Python编写），例如执行特殊导入操作，例如从VCS导入... http://code.google.com/p/nano-lp
0

文学编程是在长变量和函数名不可行的时代发展起来的。因此，代码真的不太可读。

很明显，自那时以来发生了很多事情。

在今天的世界中，代码本身就是文档，因此出现了“自描述代码”这个术语。我们意识到，任何一组注释或外部文档都无法与底层代码保持同步。因此，今天许多程序员的目标是以一种易于他人阅读的方式编写代码。

当时也缺少命名空间和类。我认为文学编程是那个时代的产物，现在已经不再相关了。 - Nathan Shively-Sanders
5
所有这些好的新特性（或者不是，可以查一下Smalltalk的起源），意味着你需要更少的文档记录，而不是没有文档。在你开始之前需要深思熟虑的任何地方，你可能需要解释你做出了什么决定。 - dmckee --- ex-moderator kitten
5
@dmckee: 赞同。整个"代码是自己的文档"的趋势是一种危险的趋势，人们往往忘记文档不仅仅是关于代码在做什么（从代码阅读中明显），而是为什么，这是至关重要的问题，当不明显时应该进行记录。 - Adam Bellaire
是的，就像“是的”，就像“不”。所以当你继承同事的代码时，坐下来阅读代码比让同事来进行“导览”更容易。人类的解释往往是按完全不同的顺序排列的，并且提供了你的代码无法提供的整体图片。 - Benjol
1
代码仅代表设计的绝对底层，当没有文档时，所有更高级别的内容必须从中费力地进行逆向工程。 - Reb.Cabin
显示剩余3条评论
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接