Haskell中的文字编程真的是"文化编程"吗?

J. *_*bal 16 haskell literate-programming

我是文学编程概念的新手.我正在阅读Donald Knuth关于这个主题的论文(PDF),并且在最初的引言中,他说:

我们不是想象我们的主要任务是指导计算机做什么,而是让我们集中精力向人类解释我们想要计算机做什么.

他或她[文学编程的实践者]努力实现一个易于理解的程序,因为它的概念是以最适合人类理解的顺序引入的,使用了相互加强的正式和非正式方法的混合.

然后,进一步阅读:

关于程序的一个问题是它的结构关系.一个复杂的软件包括简单的部分和这些部分之间的简单关系; 程序员的任务是以最适合人类理解的顺序陈述那些部分和那些关系 - 而不是以某种严格确定的顺序,如自上而下或自下而上.

(......)

自上而下的编程让您对自己的目标有了强烈的了解,但它会迫使您保持很多计划; 悬念累积起来,因为没有任何东西真正被钉死到最后.编程的优势在于,随着越来越多的子程序的构建,你不断使用越来越强大的铅笔; 但它迫使你推迟整个计划组织直到最后一分钟,所以你可能会漫无目的地挣扎.

因此,WEB语言允许人以"意识流"顺序表达节目.缠绵能够争夺一切成的安排,一个Pascal编译器的需求.WEB的这一特性也许是它最大的资产;

上面的摘录让我对这个主题感兴趣,所以我调查了一下.在任何搜索引擎提供的结果中都不难看出Haskell和文字编程之间的关系,但我没有看到"最适合人类理解的命令".相反,我会看到一个做得很好的文档,同时保持计算机所需的顺序才能工作.

  • 你能否使用术语"文学编程"来消除该订单问题?
  • 有文化编程的其他定义是否需要"意识流"顺序功能?
  • Haskell真的有文化编程能力(使用Knuth的定义)吗?

最后,作为一个个人观点,我不得不说,即使Haskell所做的(也可能是许多其他语言)不是Knuth的文字编程,我仍然喜欢这种关于方法和算法的详尽描述的想法.当评论超出目前的代码时,它有很大的作用.


WEB和TANGLE是系统的一部分,最初是D. Knuth在他的第一个文化编程概念的实现中使用的.

ham*_*mar 15

在订购方面,Haskell在很大程度上非常灵活.在Haskell模块中,所有声明和定义可以按任何顺序发生.由于引用透明性,提取子问题也很容易,以便在其他地方实现它们.

订单重要的主要区域是模式匹配.函数的所有方程都必须在一起,因为它们按顺序匹配,所以它们不能总是重新排序.但是,我不认为这是一个重要的限制,因为(a)这通常是非常局部化的;(b)具有大量方程的大函数可以(并且可能应该)重构为更小的部分,然后更容易重新排序.

也许最烦人的限制是导入声明必须位于模块的顶部.这确实打破了意识流,并且用Haskell编写的许多文学程序都以"不介意这些导入,你会看到我们以后需要它们"的语句开头.如果能够在文本中更自然地命名导入,那么与Knuth对文字编程的定义会更加一致,从上下文中可以清楚地知道为什么需要它们.

除此之外,我认为Haskell适用于文学编程.它可能不完全符合Knuth的定义,但我认为它足够接近.

  • 我一直想知道为什么`import`语句需要位于文件的顶部. (8认同)
  • @Wes:是的,这基本上就是CWEB的作用.但是在语言和编译器中内置支持是一个很大的优势,我不认为文化编程会像没有它的Haskell博客社区那样受欢迎.它是熟悉的Haskell语法.您不必在其上学习CWEB的语法. (2认同)