精巧的编程，好的/坏的设计方法

10

我最近发现了识字编程的概念。我觉得这很有趣。但是我还没有遇到过声称这是构造程序的一种坏方法的说法。似乎没有覆盖很多地方。我什至在这里都找不到任何与此有关的问题。

我的问题不是关于它的缺陷或处理文档的方法。我认为文档对识字编程流程的影响是副作用。我知道设计本来是为了易于文档编制以及正向编程流程的概念。

将问题分为基于小句子的问题的想法似乎确实是一个绝妙的主意。因此，它将简化对程序流程的理解。

素养的设计方法的结果还在于，所需功能的数量将受限于程序员的想象力。代替为特定任务定义功能的方法，可以scrap在识字方法中将其创建为。这将产生代码的自动插入，而不是单独的函数编译，并且随后需要过程间编译优化步骤来获得等效速度。实际上，由于这个事实，唐纳德·E·克努斯（Donald E. Knuth）的第一次尝试执行时间较差。我知道编译器可以解决很多问题，但这不是我关心的问题。

因此，我想获得为什么应该认为这是一种不好/好的设计方法的反馈？

design-patterns language-design literate-programming

— 第零
source

2

零，我创建了识字编程标记，并根据Wikipedia文章添加了摘要。请使用相关信息帮助扩展标签Wiki。

— 尼斯2012年

@YannisRizos我将在这里添加它，我没有编辑权限。

— 2012年

1

好吧，我俩都不:)我添加了一些资源（维基百科文章，以及您问题中的链接），当您的编辑经过同行评审并接受时，这些资源将出现。这是一种有趣的方法，由于您已经在探索它，因此每次在其中找到您认为值得一提的内容时，请返回并改进标签Wiki。

— yannis'1

1

我会建议Literate Programming网站的作者访问UX stackexchange网站-颜色确实不好看。

— 丹尼·瓦罗德

1

仅供参考，literate-programmingStackOverflow上也有一个标签。那里的内容更多，尽管仍然不多。

— 罗斯·帕特森

9

这将产生代码的自动插入，而不是单独的函数编译，并且随后需要过程间编译优化步骤以获取等效速度

这无关紧要。已经几十年了。您可以将其从问题中删除，因为对于现代编译器来说，颠覆其优化器是没有意义的。

因此，我想获得为什么应该认为这是一种不好/好的设计方法的反馈？

精通编程没有不利之处。（我希望这种情绪能获得-1票的好成绩。）作为一名从业者，我从未见过任何问题。

对于某些论点，所有这些都等于“通过调整结果代码来颠覆使用高级语言进行编程”。对。通过调整生成的.o文件，可以颠覆C ++编程的方式。是真的，但是无关紧要。

编写读写程序仅意味着将高级和详细（代码级）设计组合到一个文档中，并用合适的工具集编写该工具集，以生成易于编译的文件和易于使用的文件。

当Knuth发明了识字编程时，主流的 OO语言并不存在。因此，大量的原始Web和编织工具使他能够为抽象数据类型创建类式定义。

如今，其中大部分已无关紧要。如果精简编程工具专注于现代的，高级的面向对象（或功能）编程语言，则它们可能非常简单。由于C（或Pascal或Assembler）的局限性，因此不需要详尽的解决方法。

编写识字程序的方法与编写文盲程序的方法没有什么不同。它仍然需要仔细的设计，单元测试和简洁的编码。除了编写代码外，唯一的额外工作就是编写说明。

仅出于这个原因（需要编写连贯的解释），对于某些程序员而言，熟练的编程是困难的。有相当多的程序员是成功的（他们的代码通过了所有的单元测试，简洁明了，易于理解），但是似乎不能用他们的母语写出连贯的句子。不知道为什么这是真的。

有大量的程序员似乎只是勉强成功，然后才偶然。（Stack Overflow中有很多不好的问题，表明许多程序员甚至都难以掌握基础知识。）对于那些问了很多不一致的堆栈溢出问题的程序员，我们知道他们不能真正做好读写编程的工作，因为他们可以编程不好。

— 洛特
source

7

在以正式或非正式的任何媒介进行解释时，无论是识字的编程，写评论，甚至是电子邮件，大量的程序员都不太协调。这真是一个奇迹，软件根本无法工作：)

— Andres F.

3

对我而言，扫盲编程最重要的方面（甚至只是很好的注释）不是提供文档，而是说明程序员的意图。在了解了所声明的意图后，您可以立即判断其后的代码是否确实可以达到预期的效果。无意间，您必须从代码正确的假设开始，然后通过归纳证明它是对或错-这更加累赘和耗时，因为它通常还需要熟悉所有周围的代码。

如此明确的意图通常可使其他不熟悉代码的人迅速跳入并发现错误，而不必知道它周围的大上下文。

当然，它也可以帮助您更快地学习代码的基本流程和设计，因为对于大多数人而言，纯英语通常比指针算法更直观。

— 迈克·欧文斯
source

1

尽管我自己对乱码编程的概念还比较陌生（因此我很可能完全迷失了方向），但似乎很符合DSL的概念。

DSL背后的思想是将问题领域分解为简单的，面向自然语言的语法，该语法可用于构建用于解决这些问题的算法。

对我来说，相同的想法，或者至少是它的核心基础，与扫盲编程是相同的，或者至少密切相关。

例如，在时髦的世界中，强烈要求更定期地使用DSL并创建新的DSL以解决常见问题。这种推动力来自该语言中的两个工具（简易构建器）以及支持基于DSL的API的核心库。

鉴于至少在世界的那个角落，趋势正在朝着识字编程的方向发展，我想说这是一个努力的好方法。

不幸的是，据我所见，创建一个良好的 dsl 所需的思维水平通常超出了大多数程序员。我知道我个人不时需要一些概念。正是这种困难阻止了此类技术获得更广泛的采用。

使用该工具是一回事，这是您的经典案例，但创建它却是在完全不同的层面上。

稍微扩展一下我的观点，DSL与识字编程不是一回事，而是使识字编程更容易实现。特别是当它们是自然语言DSL时。

在groovy的1.8版中，自然语言DSL功能通过添加更强大的命令链得到了显着改善。

例如，以下代码行是programming，而不仅仅是伪语句：

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

注意：代码示例来自Guillaume Laforge的博客

识字编程背后的核心思想是自然语言对人类更易理解，这很重要。在我看来，Groovy的自然语言DSL功能使这一现实变得更加紧密。尤其是在那些DSL用于为应用程序创建业务规则时。

能够使用自然语言对系统的关键组件进行“编码”是识字编程的本质。必须将自然语言与代码块一起散布是识字编程的混蛋形式。尽管有用，但我相信允许您使用自然语言作为代码本身的自然语言DSL 是一个巨大的飞跃。

通常，扩展编程能力是该过程的下一步，但是在很大程度上已经可以使用该工具。是的，还没有“通用” DSL，但是对于较小的域，功能就在那里。

有关此操作的更多示例（无特定顺序）：

— cdeszaq
source

2

有趣的观点。从我的角度来看，它与DSL的结合并不是很好。由于有文化的编程是在一些非DSL语言。而且这些工具也不太像DSL。它们不面向问题领域。您能否提供一个示例，说明您如何将识字编程视为DSL？链接或对示例的引用可能有助于阐明您的答案。

— S.Lott，2012年

这方面的一个例子是在Groovy 1.8命令链，让你“程序”的东西像turn left then right或paint wall with red, green and yellow：docs.codehaus.org/display/GROOVY/...

— cdeszaq

@ S.Lott-我同意DSL和扫盲编程之间肯定存在差异，但是我认为DSL可能是实现真正扫盲编程的工具，您可以在其中键入自然的语言并表达所需的算法。对我来说，将自然语言和代码混合在一起是盲目的扫盲形式。

— cdeszaq 2012年

充其量是不可能的，“您可以键入自然语言，并使其表达所需的算法”。有背景，合理性，正确性证明，复杂性断言（big- O）以及许多非DSL计划不包含的非对数支持文档。现在您已经弄清楚了，我不确定我是否同意并行。

— S.Lott，2012年

1

“程序逻辑的说明”。不是逻辑本身。但是一个解释。逻辑很少是不言自明的。它永远不会包含正确性的证明（这很困难，有时甚至是不可能的）。它很少包含big-O复杂性的理由。它很少解释性能较低或内存更多的替代方案。因此，我建议DSL远不及“解释”。

— S.Lott

-2

我认为认为LP是某种DSL是错误的。因为LP是已开发程序的日记本（带有图表，方案，伪代码片段，即大块），所以它是体系结构等...绝对类似于纸质笔记本-许多开发人员都在使用它们，但是在程序完成后-丢掉你的笔记本，文件...

很久以前，每个物理学家，天文学家，化学家/炼金术士，数学家都有自己的笔记本，包含许多方案的手稿，必要的信息和表格，没有它们，您将无法理解或重复他们的成功经验及其成果。而且在这些人之间总是存在手工爬行/笔记本狩猎。

今天，许多程序员编写代码，有时还会添加注释！Byt程序不仅是代码-它是思想，想法，想象力，概念，并且当新开发人员继承外来代码时-他经常破坏所有想法和概念，产生不同的“漏洞”和“后门”，希望您能理解我的知识:)

因此，LP（作为工具！）的主要要求也是允许所有这些都具有简单，轻便，易读的语法。我尝试了许多LP工具，但今天我正在开发自己的-NanoLP（http://code.google.com/p/nano-lp/），旨在满足这一需求。

— 保罗·阿格
source