函数式编程是向自然语言编程迈出的下一步吗？ [关闭]答案

【问题标题】：Is functional programming the next step towards natural-language programming? [closed]函数式编程是向自然语言编程迈出的下一步吗？ [关闭]
【发布时间】：2008-11-12 23:43:05
【问题描述】：

这是我的第一个问题，所以我有点紧张，因为我不确定我是否理解得足够好。无论如何，我们走吧......

每当编程达到新的里程碑时，似乎他们总是有一个共同目标：让程序员更容易编程。

机器语言、操作码/助记符、过程/函数、结构、类 (OOP) 等始终有助于以更自然、更易于理解和更易于维护的方式规划、构造和编码程序。

当然，函数式编程绝不是新鲜事物，但近年来它似乎经历了某种复兴。我也相信，当微软将 F# 添加到他们的主流编程语言中时，FP 将得到巨大的推动。

回到我最初的问题，我相信最终编程将使用自然语言（英语）完成，几乎没有限制或规则。编译器将成为 AI/NLP 系统的一部分，该系统从代码中提取信息，或者我应该说文本并将其转换为编译器可以编译的中间语言。

那么，FP 是让编程更接近自然语言编程，还是说它是一个障碍，主流 OOP 会引导我们更快地走向自然语言编程？

这个问题不应该用来讨论自然语言编程的可用性或可行性，因为只有未来才能证明。

【问题讨论】：

恕我直言，函数式并不一定能让我们更接近 NLP，但这也很好 - 当您想要精确和一致性时，自然语言是毫无用处的。
好的，一旦我知道如何添加主观标签:)。但是，正如我在问题中提到的，我不想讨论 NLP 的用处。我在任何地方都没有提到我提倡 NLP。我只是好奇下一代编程语言将把我们带到哪里，以及 FP 是否是一个里程碑
如果您认为结束阶段甚至不太合理，您就无法解释中间阶段；）
函数式编程从一开始就存在（LISP 于 1958 年被指定并在之后几乎立即实施（与 1957 年的 fortran 相比）），并在 70 年代和 70 年代大量用于 AI 研究80 年代。如果这是某种进展中的一步，您不认为我们现在应该继续前进吗？
这个问题更适合programmers.stackexchange.com

标签： functional-programming nlp

【解决方案1】：

对不起，我完全不同意。代码最终是制作事物（对象）的蓝图，因此它必须非常精确且受规则支配才能可靠地运行。自然语言不会比在餐巾纸上画草图取代机械工程更早取代编程。

【讨论】：

但是，如果这些草图可以成为设计工具的一部分，它们可以让您开始走向最终产品的道路。我喜欢在我的平板电脑上勾勒出有关机器人、应用程序和网络的想法。帮助设计和实施。最好的部分是在平板电脑上，您可以获得的不仅仅是餐巾纸上的一个绘图层。
我从来没有贬低餐巾学的意思。它在工程中占有一席之地，就像自然语言在编程中占有一席之地一样（它是为了迎合接待员）。
+1 用于接待接待员。每个人都应该从 Ross Jeffries 那里学习编程课程 :) ...哦，等等，不同的 NLP sigh。

【解决方案2】：

我个人得出的结论是自然语言编程有些破解。

英语并不完全适合完全作为一门编程语言使用，太多的抽象词在编程中没有相关性，比如情感术语和其他在编程中没有地位的抽象概念，可以说编程永远将遵循“自然语言”，“自然语言”可能是编程，但事实并非如此。

现在，虽然我明白你在说什么，但问题是英语有太多废话和相同事物的重复名称，所以我们会使用甚至不是特定于领域的东西编程，用于编程任务。

我认为它更适合人们理解编程实际上是一种高度专业化的语言，并用他们的大脑学习用一种语言编写代码，这种语言简单，声明性并且具有一致的定义，不像英语那样定义是高度主观的。

一旦您了解了一种语言的来龙去脉，并了解了它的原理图和行为，您就可以将它们结合起来做新的事情。

以 Perl 为例，每个人都痛斥它是线路噪音，但是当您了解许多编程语言时，一旦您克服了“OMG LINE NOISE”的最初障碍，您就可以在一定程度上直观地编造东西你从来没有读过，然后看到它像你预期的那样神奇地工作。

恕我直言，在有针对性的问题解决方面，特定领域的语言胜过口语语言。

【讨论】：

@Bill the Lizard：嘿，概念验证，人类理解错别字。 ;) 电脑……会坏的。
我同意英语不是一种易于解释的语言，但我认为对于大多数现代语言来说都是如此。
@Kent：实际上，拼写检查器应该提醒你这些。 :)
@Bill：我有一个拼写检查器。它是火狐的一部分。 ;)。应该！= 做了。软件失败。当它检测到不准确时，它通常也会得到错误的建议（人类可以轻松解决）
@RB：自然语言实在是太模棱两可了。描述一个问题的文本，在“冗长”的编程语言中，需要 100 行，很容易需要 100 页来澄清所有的歧义。作为一个练习：试着写一段文字，明确而详细地描述一个博客。

【解决方案3】：

“那么，FP 是让编程更接近自然语言编程，还是说它是一个障碍，主流 OOP 会引导我们更快地走向自然语言编程？”

两者都没有。两者都遵循相同的原则，即您必须具体说明您希望计算机做什么。必须没有存在不确定性的余地，而且这两种范式都与自然语言没有任何关系。他们解决了一个完全不同的问题：管理和构建复杂代码和大型代码库。

自然语言的最大障碍是解析。明确地解析自然语言是不可能的。如果没有大量上下文信息（面部表情、语调），即使是人类也无法做到这一点，即便如此，我们仍然经常会出错。

OOP 和 FP 仅与解析后发生的情况有关。。一旦被识别和解析，每个语义元素会被赋予何种含义。

也许有一天我们能够使用自然语言进行编程。我怀疑它会在未来几十年内发生，但它可能有一天会发生。但是今天的编程范式既不会加速这个过程，也不会延迟它。他们根本与它无关，也无助于解决解析问题。

【讨论】：

【解决方案4】：

我不认为函数式编程比 OO 编程更接近自然语言编程。函数式编程具有非常面向动词的语法。当您使用 Lisp 或 Scheme 进行编程时，您会花费大量时间来考虑函数以及您希望对数据采取哪些操作。在 OO 编程中，您大部分时间都在考虑对象，因此它看起来非常面向名词。但是，在 Smalltalk、C++ 和 Java 中，您也有一些方法，可以让您将动词应用于所有名词（可以这么说）。

我不认为 OO 编程一定会引导我们走向自然语言编程，但在我看来它比函数式编程更接近一点。对我来说，函数式编程似乎更接近于数学而不是自然语言。这并不是一件坏事，因为也许数学是我们在编程时应该考虑的语言。

【讨论】：

尊重提问者的要求，以避免对自然语言编程的前景和优点进行辩论，我主要同意这样的评论，即函数式编程（实际上比 OOP 更早）并没有更接近于不管那是什么。
我也不清楚 OOP 是否更接近自然语言编程，尽管有时会听到一种神奇的信念，即编程语言对象与“真实对象”有某种密切的关系。对我来说，这种神奇的想法证明了 OOP 并没有走上通往 NLP 的道路。
OOP 对象固有地与现实世界的对象没有关系，但如果需要，您可以以这种方式对它们进行建模。我使用并创建了很多不使用的对象。

【解决方案5】：

仅供参考，Inform 7 可能是最接近自然语言编程的人。它是一种针对特定领域的语言：编写交互式小说，一种以“冒险游戏”开始的软件。

【讨论】：

【解决方案6】：

目前对函数式编程的兴趣激增主要是由于 C# 3.0 的酷炫新特性基本上是为了启用并行性，并表示向多核计算的转变。恕我直言，我认为我们不能将其视为“自然语言编程”的下一步

【讨论】：

我不会说一般的 C# 3.0 或 LINQ 主要是关于并行性。对我来说，LINQ 是关于跨数据源的声明性和一致的数据访问方法，无论在何种程度上是可行的。能够使用函数式样式对于非常而言非常方便，而不仅仅是并行性。
Jon... 我觉得 C# 中的 FP 转变更多地是并行性的推动者... 也许 Lamda 表达式符合我的情况？ :) 我同意你的观点，功能风格要多得多。为什么 C# 不是从这个词开始的功能呢？为什么现在多核成为常态？ ParallelFx 不是基于这些功能构建的？

【解决方案7】：

如果您正在寻找编程语言的下一个发展方向，我会寻找 DSL。 DSL 允许高度定制的语言，使复杂的商务用户能够配置系统，而不必担心编码细节，如数据类型、线程和 UI 小部件。

函数式语言将在“高度并行处理”领域占有一席之地。

【讨论】：

【解决方案8】：

您是否认为主观问题会在此处将“Windows Internals the 5th Element”订单添加到数据库并运送到我的地址？如果是这样，自然语言编程将非常接近函数式编程，因为我以某种函数式的方式提出了我的问题。如果不是，那么自然语言编程不会让我的订单发货，对吗？函数式编程可以工作，因为它仍然与自然语言无关。

【讨论】：

【解决方案9】：

没有。函数式编程将使我们更接近证明编译器。那是编译器可以证明有关您的代码的更多断言。能为我们证明的编译器越多，软件开发就越接近工程而非艺术。

NLP 编程语言可能更像是一种“按我的意思做，而不是按我说的做”风格的语言。这可能与函数式语言的发展方向相反。

“所有编程语言都在向 LISP 收敛。”

【讨论】：