为什么识字编程不是主流？[关闭]

精通编程具有良好的理想。您为什么认为这不是主流？是因为它未能交付吗？

我首先在Knuth的著作中看到它，并认为它看起来很整洁。然后，我尝试使用文学编程显示来了解程序中正在发生的事情，并发现它比看上去更难。可能是我太习惯了浏览程序清单，但这似乎令人困惑。

然后，我查看了源代码，这使我断断续续。我必须学习以一种全新的方式编写程序，程序文本和编译器看到的内容之间的对应关系较少，并且看不到任何相应的好处。

另外，人们可以写很长且令人信服的参数，使代码实际上在执行Y时正在执行X，而我也遇到了误导性注释。我很喜欢阅读代码，以期看到它的早期状态。精辟的编程是对立的。

我要怪网络效应。为了让其他人编辑您的代码和文档，他们必须能够理解。

这使人们远离cweb / noweb之类的东西，因为使用它们将需要您在用于项目的编程语言之上学习TeX和特定于程序的语法。这可以被视为浪费大量时间，尤其是如果他们不需要任何一种数学排版，而这些数学排版首先对TeX如此吸引人。（对于许多应用程序程序员来说，他们实际上并不需要它。）相反，他们更喜欢Visual Studio的XML注释之类的东西，因为它已经很流行并且已经建立。

我见过的识字编程起步于科学/统计计算，其中大多数程序员都接受过数学，CS或统计方面的重要培训（即博士学位），因此已经熟悉LaTeX。他们编写的文档中更有可能包含许多最好用TeX编写的复杂公式，而且它们更有可能是用R进行编程的。知道SWeave的R程序员的比例肯定比（例如）了解cweb的C程序员的比例。

在上世纪90年代后期学习时，我对Literate Programming的概念着迷，但我仍然对Knuths的编程和排版方法感兴趣。唯有最好的办法。

Knuth设计的Literate Programming系统做了很多事情，远远超过了立即引起的注意，即，它克服了从Knuths源文件生成的代码生成工具（即标准Pascal）在底层编程语言中的许多缺点。

对于那些幸运的没有尝试过标准Pascal的人，这里是一些亮点。

• 为了使使用单遍编译器更加容易，语言规范指出，所有声明都必须按一定顺序进行。在Wikipedia页面上：“每个过程或函数都可以具有自己的goto标签，常量，类型，变量以及其他过程和函数的声明，它们必须都按该顺序排列。” 这意味着你可以不组你的东西在逻辑上在一起的源文件英寸
• 与纯C语言相比，字符串处理更加乏味。
• 标识符不能有任意长度。
• 还有更多我不记得的事情。

所有这些事情基本上意味着Knuth需要一种更好的编程语言（因此他发明了一种），并且使用Pascal作为其汇编语言。

大多数现代语言可以轻松完成这些任务，因此省去了Literate Programming要解决的大部分工作。

现代语言也更具表现力，可以在代码本身中添加更多思想。

那么，还剩下什么呢？能够从源代码生成文档的排版形式，并且这种功能已经存在。

试想一下JavaDoc-Java运行时API可能是当今可用的最大的Literate Programming片段（除了未实际提供代码，但是如果Java从一开始就开源的话，则应该如此）。例如，在http://download.oracle.com/javase/6/docs/api/java/util/Collection.html上查看集合框架的表示

我相信.NET和其他主流程序也存在类似的系统。

我在90年代开始从事文学编程工作时发现的一件事是，它吸引了许多非常热情的人，他们想做《准确地做正确的事》，这涉及编写自己的文学编程系统，因为没有一个适合他们的文学编程系统。noweb是通过为每个人提供足够好，最不常见的分母来实现这一目标的良好尝试，尽管即便如此，我仍然花费了大部分LP时间来为其开发漂亮的打印机...

另一个问题是它确实是反敏捷的。在某些方面，放慢脚步是件好事，因为它会迫使您多加思考，并在第一时间把事情做好。另一方面，在进行过程中精心记录文档意味着重构代码存在很大障碍。而且，如果您等到对代码进行加固后再对它进行LP验证，那么最终将需要进行多日的文档编制任务，这实际上会使您陷入困境。

以我的拙见，许多公司的文化与Literate Programming的目标相反：他们想要更快的结果（它们只在应用程序投入生产时才对质量大哭）。以我自己的经验，我的老板们拒绝理解更快的结果并不意味着“一个程序在我要求的第二天就可以运行”。对于他们来说，如果开发人员不忙于在键盘上打字，那么他就没有工作，那就是“浪费时间在无意义的设计中”。是的，我知道，我的老板是个混蛋。

编码员写的不是英语。

程序员不喜欢编写文档，因为它不能帮助代码运行。

编码人员不擅长编写文档，因为它是表达思想的不良手段。

精简编程似乎是将文档带入更高层次的想法，在该层次上，代码更多是事后思考。也许可以，但是对于大多数编码人员来说，它看起来像令人讨厌的文档。

主要是因为人们非常愚蠢。显而易见的证词是年轻人对这种简单技术的本质的无休止的猜测和误解。

人们认为LP是：（a）一种记录方法（b）一种写一些需要一些特殊技能或才能的精美论文的方法（c）根本不知道-作为Leo编程编辑器的创建者，他自己承认等等等等

然而，LP简单来说就是：（1）用一种（=任何一种）人类语言混合代码和短语来编写程序，后者代表其他代码块和/或包含的短语。这正是无数编程教科书的作者所做的。.（2）它是一个简单的预处理器，可以扩展人类中的这些短语（就好像所包含的子例程的名称一样），以在编译器要求的顺序中解开结果（或口译员）。否则，可以使用另一个小的实用程序来扩展书面文本，以包括格式符号，以将“文学来源”转换为格式良好的可读文本。

年轻人从不尝试这个极其简单的想法-幻想或想象虚假的理由，他们从不尝试或不这样做。

基本上，编程的主要思想是用人类语言编写“伪代码”，然后使用简单的预处理程序实用程序进行扩展以帮助管理（注意，这对于任何冗长的程序来说都是一个主要难题），非常类似于代码折叠或程序流程划分进入函数/子例程，这是您不需迷失细节，但对于机器执行而言完全不必要的。

我确实希望将识字编程的两个方面纳入主流编程中-嵌入式图像（例如设计图）以及指向先前尝试和替代尝试的指针（例如，“之所以这样，是因为我尝试了另一种方式，它没有用，因为...“）。这些方面均可通过文档注释和URI处理。

因为程序的逻辑与我们所说的不一样。程序具有明确指定的流程，条件和循环。

在进行大量编码之后，我会考虑这些术语。我的大脑将问题转化为可执行代码的目标领域。对于我来说，用一种通常的编程语言来编写代码要比执行额外的转换步骤使我的程序更加有素的效率更高。

实际上，我相信我的程序已经具备读写能力了……说出标识符，好的函数名，注释，这些都是我做了一些骇客的，几个月后我并不会立即意识到。

总结一下：我的Java代码本身就更加识字，就像每个“识字”程序都想做到的那样。

我以另一种方式来学习编程-我梦想着将代码组织成适合我的想法，而不是编译器要求的那样。我发现狮子座几乎是理想的选择。它还支持跟踪外部更改的文件。这些文件不必包含任何特殊的标记，因此我可以自己使用Leo，而无需团队中的其他人知道。这个功能-“ @shadow树”-非常有前景，尽管仍然有些小问题，但需要更多的关注。它还通过将所有内容组织到树轮廓中以及通过对外部文件的支持，解决了“哦，不，所有内容都在一个大文件中”的问题。

对我而言，与名字相反，“识字编程”根本不是关于文档的。我没有比以前更多的文档了。拥有结构使我不会迷路。我发誓特别是在管理庞然大物的JSP文件时（尽管Leo最初主要用于Python并且它不支持JSP语言-我必须手动将文件拆分为Leo树！）。

我认为它是一种有价值的教学工具，可以在其中撰写关于代码的论文，然后在其中插入工作代码段，以指导读者了解代码的方式，内容和原因。

在纯粹的教育环境之外，我认为只有Knuth真正了解如何最好地使用它。

这是世界上最糟糕的情况-您必须使用非特定语言=英语编写高度正确，高度特定的计算机程序。因此，您必须使用完全正确的短语仔细地编写它-因此您最好只编写代码。