扩展识字编程？
问候。 我现在一直在研究文学编程，我确实喜欢它背后的想法：你基本上写了一篇关于你的代码的小论文，并写下了尽可能多的设计决策、可能围绕模块的代码、模块的内部工作原理。模块、设计决策产生的假设和结论、潜在的扩展，所有这些都可以使用 tex 以一种很好的方式写下来。 当然，第一点：它是文档。 它必须保持最新，但这不应该那么糟糕，因为您的更改应该有理由，并且您可以将其写下来。
然而，文学编程如何更大程度地扩展呢？ 总的来说，文学编程仍然只是文本。 当然，非常适合人类阅读的文本，但仍然是文本，因此很难遵循大型系统。 例如，我重新设计了编译器的大部分以使用 >> 还有一些将编译步骤链接在一起的魔法，因为一些“x.register_follower(y); y.register_follower(z); y.register_follower(a);...”变得非常笨拙，并将其更改为 x >> y>> z>> a 让它变得更好一些，尽管这也处于临界点。
那么，文学编程如何扩展到更大的系统呢？ 有人尝试这样做吗？
我的想法是使用 LP 来指定使用事件流相互通信的组件，并使用 graphviz 的子集将所有这些组件链接在一起。 这将是对 LP 的相当自然的扩展，因为您可以从网络中提取文档（数据流图），并且还可以很好地从中生成代码。 你怎么看呢？
——特莎。
Greetings.
I have been looking at Literate Programming a bit now, and I do like the idea behind it: you basically write a little paper about your code and write down as much of the design decisions, the code probably surrounding the module, the inner workins of the module, assumptions and conclusions resulting from the design decisions, potential extension, all this can be written down in a nice way using tex. Granted, the first point: it is documentation. It must be kept up-to-date, but that should not be that bad, because your change should have a justification and you can write that down.
However, how does Literate Programming Scale to a larger degree? Overall, Literate Programming is still just text. Very human readable text, of course, but still text, and thus, it is hard to follow large systems. For example, I reworked large parts of my compiler to use >> and some magic to chain compile steps together, because some "x.register_follower(y); y.register_follower(z); y.register_follower(a);..." got really unwieldy, and changing that to x >> y >> z >> a made it a bit better, even though this is at its breaking point, too.
So, how does Literate Programming scale to larger systems? Does anyone try to do that?
My thought would be to use LP to specify components that communicate with each other using event streams and chain all of these together using a subset of graphviz. This would be a fairly natural extension to LP, as you can extract a documentation -- a dataflow diagram -- from the net and also generate code from it really well. What do you think of it?
-- Tetha.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
《Physically Based Rendering》(pbrt.org) 这本书是我所了解的大规模文学编程的最佳示例。我知道。 本书实现了完整的渲染系统，书籍文本和光线追踪器代码都是从同一个“源”生成的。
在实践中，我发现仅仅使用像 Doxygen 这样的系统并真正深入挖掘并利用它的所有功能比成熟的“文学”编程更好，除了像这样的东西，即教科书、教育材料。
The book "Physically Based Rendering" (pbrt.org) is the best example of large-scale literate programming that I'm aware of. The book implements a complete rendering system, and both the book text and the raytracer code are generated from the same "source".
In practice, I've found that just using a system like Doxygen and really digging in and making use of all of its features is better than full-blown "literate" programming, except for things like this, i.e. textbooks, educational materials.
很好的问题。 识字编程的动机永远不会消失，但我认为它应该被视为流动的。 它的意思是“让读者休息一下，并教育他们去做你想做的事情”。 我不认为这意味着“让你的代码变得非常冗长”。
也就是说，读者必须根据他们已经知道的内容付出一些努力。 想必代码是值得理解的，没有什么是免费的。
我还认为这不仅仅意味着编写可读的代码。 人们阅读代码的原因很可能是因为他们需要进行更改。 您应该预见可能需要的更改，并在必要时告诉他们如何进行。
Excellent question. The motivation for literate programming will never go away, but I think it should be treated as fluid. It means "give the reader a break, and educate them to what you're trying to do". I don't think it means "make your code really wordy".
That said, the reader will have to put some effort into it, depending on what they already know. Presumably the code is worth understanding, and nothing comes for free.
I also think it means more than just making readable code. Most likely the reason someone is reading the code is because they need to make a change. You should anticipate the possible changes that might be needed, and tell them how to do it if necessary.
pbrt 是一款以文学风格编写的基于物理的光线追踪器，用于计算机科学毕业生（和我）的教育，它是一个中等规模的系统。 作为非专业程序员，这种级别的文档对于理解程序的功能和原因非常重要。
我还可以使用 Java 编写的研究渲染器，它写得很好，但相对没有文档记录，但只适用于一些 SIGGRAPH 论文。 这也是比较可以理解的，不过我也能接触到作者。
我还经常使用 ImageJ ，并深入了解了底层 Java - 如果不了解底层哲学，就很难理解。
总而言之，我的观点是，如果有人能抽出时间做好识字编程，那么识字编程就很棒，而且这很可能是在教育环境中。 很难看到它在商业代码生产中实现。 我对代码可以完全自我记录的想法持怀疑态度。
pbrt is a physically based ray tracer written in the literate style for the education of computer science graduates (and me), it is a moderately large scale system. As a non-specialist programmer this level of documentation is pretty essential for understanding what the program does and why it does it.
I also have access to a research-renderer, in Java, which is well-written but relatively undocumented but for a few SIGGRAPH papers. This is also relatively understandable, but I have access to the authors too.
I've also used ImageJ quite a lot, and looked under the hood at underlying Java - it's pretty difficult to follow without an idea of the underlying philosophy.
In sum, my view is that literate programming is great if someone can find the time to do it well and this is likely to be in educational settings. It's difficult to see it being done in commercial code production. I'm skeptical of the idea that code can be entirely self-documenting.
大约 15 年前，我用 WEB 进行了一些文学编程。 最近，我尝试从 wiki 中提取代码并从 Squeak Smalltalk 环境中生成文档。
自下而上的部分可以通过从 TDD/BDD 框架生成文档来处理，但 LP 侧重于向读者解释代码。
有几个问题：
这个故事应该是如何构建系统的（具有完美的事后诸葛亮）。
为了让 LP 适用于更大的系统，您需要比 wiki 或对象浏览器更好的 IDE 支持。
I did some literate programming with WEB some 15 years ago. More recently I tried extracting code from a wiki and generating documentation from a Squeak Smalltalk environment.
The bottom-up part can be handled relatively well by generating documents from TDD/BDD frameworks, but LP focuses on explaining the code to the reader.
There are a few issues:
The story should be how the system could have been build (with perfect hindsight).
For LP to work for larger systems, you need better IDE support than a wiki or an object browser.
错误。
图表很好。
这只是架构，而且很好。
数据流程图对于生成详细代码并没有多大帮助。 它们是一个方便的摘要，而不是精确的信息来源。
一个好的书写工具（如 LaTex）可以对文档中的图表进行编码。 您可能可以从文档的其他部分找到绘制该图的方法。
底线
从长远来看，您最好生成图表作为文本摘要。
为什么？
图表有意省略细节。 图表是摘要或概述。 但作为代码来源，图表很糟糕。 为了提供所有细节，图表变得非常混乱。
但是其他一些 LP 标记的图解摘要也可以很好地工作。
False.
Diagrams are fine.
That's just architecture, and that's fine.
Data flow diagrams aren't really all that helpful for generating detailed code. They're a handy summary, not a precise source of information.
A good writing tool (like LaTex) can encode the diagram in the document. You could probably figure a way to the diagram from other parts of the documentation.
Bottom Line
In the long run, you're better off generating the diagram as a summary of the text.
Why?
Diagrams intentionally elide details. A diagram is a summary or an overview. But as a source for code, diagrams are terrible. In order to provide all the details, the diagrams become very cluttered.
But a diagrammatic summary of some other LP markup will work out fine.
文学编程背后的想法是强调文档，代码散布在文档中，而不是注释散布在代码中。
这是一种本质上不同的哲学，较长的变量名、命名空间和类等差异不会影响该哲学。 文学编程提倡有意义的变量名称。
它可以扩展到更大的系统，因为文档与代码的基本比率与代码的大小成线性比例。
The idea behind literate programming is emphasis on the documentation, with code sprinkled through the documentation, rather than comments sprinkled through code.
This is an essentially different philosophy, and differences like longer variable names, namespaces, and classes don't affect the philosophy. Literate programming advocates meaningful variable names.
It scales up to larger systems, because the basic ratio of documentation to code scales linearly with the size of code.
12.5年后，终于出现了一些有希望的进展。 GToolkit 提供集成的多个视图、入口点和工具来很好地进行文字编程。
12.5 years later, there are finally some promising developments. GToolkit provides the integrated multiple views, entry points, and tools to do literate programming well.
文学编程是在长变量和函数名根本不可能存在的时代发展起来的。 因此，代码确实不那么可读。
显然，从那时起发生了很多事情。
在当今世界，代码本身就是文档，因此称为“自文档代码”。 人们认识到，任何注释或外部文档都无法与底层代码保持同步。 因此，当今许多程序员的目标是以其他人可读的方式编写代码。
Literate Programming was developed in an era where long variable and function names were simply not possible. Because of this, code really wasn't that readable.
Obviously, a lot has happened since then.
In today's world, the code itself is the documentation, hence the term "self documenting code." The realization is that no set of comments or external documentation can ever stay in sync with the underlying code. So, the goal of a lot of today's programmers is to write the code in such a way that it is readable to others.
尝试 NanoLP - LP 可扩展工具，支持多种文档格式（Markdown、OpenOffice、Creole、TeX、Asciidoc 等）、导入其他 LP 程序、模板等。 用户可以添加自己的命令/宏（在Python中），例如进行特殊导入，例如从VCS...
http://code.google.com/p/nano-lp
Try NanoLP - LP extensible tool, supports many document formats (Markdown, OpenOffice, Creole, TeX, Asciidoc and other), importing of another LP programs, templating and more. User can add own commands/macros (in Python), for example to do special importing, for example, from VCS...
http://code.google.com/p/nano-lp