Functional programming 函数式编程是走向自然语言编程的下一步吗？

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

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

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

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

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

---

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

---

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

对不起，我完全不同意。代码最终是制造事物（对象）的蓝图，因此它必须非常精确，并受规则约束，才能可靠地运行。自然语言不会很快取代编程，就像在餐巾纸上画草图会取代机械工程一样。

我个人得出结论，自然语言编程在某种程度上是有缺陷的

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

现在我明白你在说什么了，问题是英语中有太多的废弃术语和重复的名称，所以我们会使用一些甚至不特定于编程领域的东西来完成编程任务

我认为更适合的做法是人们理解编程实际上是一种高度专业化的语言，并运用他们的大脑学习用一种简单的、声明性的、具有一致定义的语言进行编码，而不像英语，英语的定义是高度主观的

一旦你了解了一门语言的来龙去脉，了解了它的原理图和行为，你就可以把它们结合起来做新的事情

以Perl为例，每个人都抨击它是行噪声，但是当你了解许多编程语言时，一旦你越过了“OMG行噪声”的最初障碍，你就有了一定程度的直觉，你可以编造一些你从未读过的东西，然后看到它神奇地像你期望的那样工作

---

而IMHO，在有针对性地解决问题方面，领域特定语言胜过口语语言

我不认为函数式编程比面向对象编程更接近自然语言编程。函数式编程具有非常面向动词的语法。当您使用Lisp或Scheme编程时，您会花费大量时间考虑函数以及要对数据采取的操作。在面向对象编程中，您大部分时间都在考虑对象，因此它看起来非常面向名词。但是，在Simultalk、C++和java中，你也有方法，允许你把动词应用到所有的名词（可以说）。 我不认为OO编程必然会引导我们使用自然语言编程，但在我看来，它比函数式编程更接近。在我看来，函数式编程似乎比自然语言更接近数学。这并不是一件坏事，因为也许数学是我们编程时应该考虑的语言。

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

都不是。两者的工作原理都是一样的，那就是你必须明确你想让电脑做什么。必须没有不确定性的空间，两种范式都与自然语言无关。它们处理一个完全不同的问题：管理和构造复杂代码和大型代码库

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

OOP和FP只是关于解析后发生的事情。一旦每个语义元素被识别和解析，它的意义就被赋予了

---

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

目前人们对函数式编程的兴趣主要来自C#3.0酷炫的新特性，基本上是为了实现并行性，并表示向多核计算的转变。恕我直言，我认为我们不能认为这是“自然语言编程”的下一个步骤

如果你正在寻找编程语言的下一个进化，我会看看DSL。DSL允许高度定制的语言