为什么逻辑编程没有流行起来？
随着时间的推移，函数式编程似乎对其他编程语言产生了越来越大的影响。 我们在人工智能课程中开始使用 Prolog，似乎有一些东西可以使非人工智能领域的编程变得更容易。 我的问题是：为什么逻辑编程没有以同样的方式流行起来？
在这个主题中，似乎达成了普遍共识逻辑编程是有用的，但必须得到证明。 有没有理由认为它没有用？
更新：也许我应该更清楚一点。 我并不是真的在问 Prolog。 我明白为什么对于大多数实际应用程序选择 Prolog 不是一个好主意。
为了给出我正在谈论的更多内容的示例，请考虑 Python 中的列表推导式/映射/过滤器。 这些显然受到函数式语言的影响。 为什么像 Python 这样的语言没有像函数式语言那样从逻辑编程语言中继承这些东西呢？
As time goes by, it appears more and more like functional programming is having more of an effect on other programming languages. We're starting on Prolog in my AI class, and it seems like there are some things there that would make programming in non-AI fields easier. My question is this: why hasn't logic programming caught on in the same way?
In this topic, it seems that a general consensus was reached that logic programming is useful but must be proven as such. Is there a reason why it's not seen as useful?
Update: Perhaps I should be a bit more clear. I'm not really asking about Prolog. I can see why it wouldn't be a good idea to choose Prolog for most real-world applications.
To give an example of more what I'm talking about, consider list comprehensions/map/filter in Python. These are clearly influenced by functional languages. Why is it that languages such as Python haven't also picked up on these kinds of things from logic programming languages like they have functional languages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
当您在计算机科学课程中使用 Prolog 学习逻辑编程时，重点不是让您成为一名熟练的 Prolog 程序员，而是让您敞开心扉，接受您所掌握的替代形式的编程技术（数据结构/算法）。 d 之前没有考虑过。
为了说明我的观点，当我开始学习计算机科学时，我的工程学校过去要求所有学生都用 Pascal 编写软件程序，但自从我毕业以来，我从未使用过 Pascal 一次。 但我通过选择正确的数据结构和算法学到的技能仍然每天都在使用。
Pascal 并没有作为我所知道的语言出现在我的简历中，但它在我作为软件工程师的培训中发挥了重要作用。 它的有用性不能仅通过当前生产中的 Pascal 代码行数来衡量。
当您开发软件时，您会意识到，即使您没有编写一行 Prolog 代码，您有时也会重复使用您可能在参加过的这些“无用”Prolog 或 AI 课程中首次学到的技术。
评估一项技术（特定编程语言、特定软件工具/应用程序）的有用性不仅仅是评估其实际使用水平，而是评估其影响力。
如果你看看逻辑编程在专家系统、计算机游戏人工智能、空中交通管制以及可能还有很多其他领域（有人建议吗？）领域的影响，我认为这不能说是逻辑-编程还没有流行起来...
When you learn about logic-programming in Computer Science classes using Prolog, the main point is not to make you a proficient Prolog programmer, but rather to open up your mind to alternate forms of programming techniques (data-structures/algorithms) that you'd not have considered before.
To illustrate my point when I started studying Computer Science my engineering school used to require all students to write their software programs in Pascal, but since I graduated I've never used Pascal even once. But the skills I learned by picking the right data-structures and algorithms I am still using every single day.
Pascal is not showing up on my resume as a language I know, but it has been instrumental in my training as a software engineer. Its usefulness cannot only be measured by the number of line of Pascal code currently in production.
When you'll develop software you'll realize that, even though you are not writing a single line of Prolog code, you are at times re-using techniques that you may have first learned in these "useless" Prolog or AI classes you attended.
Evaluating the usefulness of a technology (specific programming language, specific software tool/application) is not simply a matter of evaluating its actual level of use, but rather its influence.
If you look at the influence logic-programming has had in the field of expert systems, computer games AI, air traffic control, and probably quite a number of other fields (suggestions anybody?) I don't think it can be said logic-programming has not caught on...
我花了大约 4 年的编程生涯致力于一个基于规则的“专家系统”，用于根据客户要求配置和配置电话交换机的硬件。
它非常成功，据我所知十多年后仍在日常使用。 但寻找能够理解其工作原理的程序员比开发系统本身更艰巨。
我认为这就是为什么这种方法没有流行起来，因为与能够理解过程式和函数式编程概念的人相比，很少有人具备基于逻辑的编程的必要思维。
逻辑编程语言提供了一种将事实和推理规则输入“推理引擎”的机制，然后启动“推理引擎”将规则应用于给定的事实，以产生新的事实。 特定逻辑语言的成败取决于其特定推理引擎的强度。
Prolog 的推理引擎的实现非常幼稚并且效率非常低。 在大多数过程语言中，只需在循环中编写大量 if 语句，就可以更有效地解决同样的问题。
我们为“配置器”选择的语言是 DEC 的 RuleWorks，它是更广为人知的 OPS5 语言的改进版。 它有一个基于 Rete 算法 的推理引擎，这使得它比过程方法更加高效。
自从 DEC 被 Compaq 吞并，而 Compaq 又被 HP 吞并后，RuleWorks 已经开源并可以从此网页获取。
遗憾的是，人们对这些技术没有更多的兴趣，因为它们可以非常有效地解决各种棘手的问题。
I spent about 4 years of my programming career working on a rule based "Expert System" for provisioning and configuring hardware for telephone exchanges based on customer requirements.
It was very successful, and as far as I know is still in daily use more than 10 years later. But finding programmers who could understand how it worked was a greater task than developing the system itself.
I think this is why the approach has not taken off, because few people have the necessary mindset for logic based programming compared to the number of people that can understand the concepts of procedural and functional programming.
Logic programming languages provide a mechanism for feeding facts and rules of inference into an "inference engine" which is then set in motion to apply the rules to the given facts in order to produce new facts. A particular logic language stands or falls on the strength of it's particular inference engine.
Prolog's inference engine has a very naive implementation and is very inefficient. The same problem could be solved more efficiently in most procedural languages just by writing a lot of if statements in a loop.
The language we chose for our "Configurator" was DEC's RuleWorks which is a refinement of the more widely known OPS5 language. This has an inference engine based on the Rete Algorithm which makes it far more efficient than the procedural approach.
Since DEC got swallowed by Compaq which got swallowed by HP, RuleWorks has become open source and be obtained from this web page.
It's a shame there is not more interest in such techniques because they can be very effective for solving a variety of otherwise intractable problems.
我最近在一个游戏设计人工智能研究项目中使用了一堆逻辑编程（预告视频 ！），但我的逻辑密集型项目中至少有一半是实现基本游戏引擎的函数式或命令式 Scala 代码。 编程的要点，如果我可以这么说的话，就是让机器对你想要的东西的理解与你自己的同步——而大多数同步是< em>要求在某种程度上给出您希望如何完成某件事的必要详细信息。 那些愚蠢的机器总是那么字面意思……
逻辑编程，无论是传统的、演绎的、序言式的东西，还是更奇特的归纳逻辑编程或答案集编程风格，都以牺牲成本为某些风格的问题提供了巨大的影响力能够轻松地传达命令性知识（在现实世界的应用程序中某处总是需要这些知识）。 有时，交互式应用程序的问题会使您在表达命令性知识时的生产力受到哪怕最轻微的影响，这是不可接受的。 以逻辑编程风格编写整个游戏引擎始终是一个坏主意（同样尝试使用具有相同计算能力的 perl 兼容正则表达式）。 在混合语言中（或者在一种可以让您轻松嵌入逻辑解释器的语言中），您可以两全其美（我使用 jTrolog 将 Prolog 嵌入到我的 Scala 引擎中，形成某种多范式 voltron）。
我认为逻辑编程肯定会更流行、更容易理解，但是，从某种意义上说，纯逻辑编程在“流行”方面并不能比 SQL 或正则表达式做得更好，因为它的魔力来自于夺走你的知识。命令式的表达能力（理想情况下，可以防止你迷失在不重要的细节中）。 这个解释几乎同样适用于函数式编程。 我喜欢逻辑编程，但只是因为我可以选择何时使用它。 最好的前进方式似乎是混合语言，以一致、精心设计的方式呈现该选择。
I recently used a pile of logic programming in a game design AI research project (teaser video!), but at least half of my logic-heavy project was functional or imperative Scala code implementing a basic game engine. The point of programming, if I may claim such a thing, is to bring the machine's understanding of what you want into sync with your own -- and most of syncing is requires giving the imperative details, at some level, of how you want something done. Those silly machine are always so literal...
Logic programming, whether it be the traditional, deductive, prolog-style stuff, or the more exotic inductive logic programming or answer set programming flavors, gives massive leverage for some flavors of problems at the cost of being able to easily communicate imperative knowledge (which is always needed somewhere in real-world apps). Sometimes the concerns of an interactive application make even the slightest hits to your productivity in expressing imperative knowledge unacceptable. Writing an entire game engine in a logic programming style will always be a bad idea (likewise for trying it using perl-compatible regular expressions which have the same computational power). In a hybrid language (or in one that lets you embed a logic interpreter easily) you can have the best of both worlds (I used jTrolog to embed Prolog in my Scala engine, forming a multi-paradigm voltron of sorts).
I think logic programming could certainly stand to be more popular and well understood, but, in some sense, pure-logic programming can't do much better than SQL or regexes in terms of "catching on" because its magic comes from taking away your imperative expressiveness (keeping you from getting lost in unimportant details, ideally). This explanation applies almost equally to functional programming. I love logic programming, but only because I have a choice about when to use it. The best way forward seems to be hybrid languages that present that choice in a consistent, well-designed manner.
我对普通 Prolog 的印象是它是一种玩具语言。 这并不是说逻辑编程没有用处。 例如，在 Twelf 中，可以非常轻松地声明简单编程语言的语义，并使声明充当口译员。 我还听说过一些关于 λProlog 的好消息。
我认为尝试使用逻辑编程语言作为通用语言的问题是有些任务不太适合这个概念。 我认为逻辑编程功能需要合并到一种还具有命令式和函数式结构的语言中。 至少有一种这样的语言：Oz，但我还没有尝试过出来。
编辑：有一段时间我一直想尝试一个想法：将关系数据库作为原子提供给 Prolog，并用它来代替 SQL 进行查询。 我有一种感觉，这将是对 SQL 的巨大改进。
My impression of plain Prolog is that it's a toy language. That's not to say that logic programming can't be useful. For example, in Twelf it's possible to declare semantics for a simple programming language quite easily and have the declarations act as an interpreter. I've also heard some good things about λProlog.
The problem I think in trying to use a logic programming language as a general purpose language is that some tasks just don't fit the concept very well. I think that logic programming features need to be incorporated into a language that also has imperative and functional constructs. There is at least one such language: Oz, but I've yet to try it out.
Edit: There's one idea I've wanted to try for some time: Feed a relational database to Prolog as atoms and use it to do queries instead of SQL. I've a feeling it would be a great improvement over SQL.
当我们学习prolog时（在编程语言课上只学了几周，所以我算不上专家），教授还指出，根据你的定义，逻辑编程实际上可能根本不是编程。
当我们说编程时，我们通常指的是“向计算机发出一系列任务或指令”。 这就是命令式或函数式编程语言所做的事情。 这就是每种“真正的”编程语言所做的。 Prolog，或者逻辑编程，并没有真正做到这一点。 它更像是 SQL。 你可以向计算机询问很多问题。 它会根据您之前提供给它的数据，尽其所能地做出回答，但与其他编程范例不同，您并没有真正告诉计算机要做什么。
它只是非常专业，不适合通用编程。 而且它专门用于的事情通常并不需要。
另一方面，函数式编程绝对是通用编程，可以用于任何事情，没有什么大问题。 这就是为什么后者流行起来，而逻辑编程则不然。 我认为... ：）
When we learned prolog (just a couple of weeks in a programming languages class, so I'm hardly an expert), the professor also pointed out that depending on your definitions, logic programming may not actually be programming at all.
When we say programming, we usually refer to something like 'issuing a series of tasks or instructions to the computer'. That's what imperative or functional programming languages do. That's what every "real" programming language does. Prolog, or logic programming, doesn't really do that. It's more like SQL. You get to ask the computer a number of questions, pretty much. It'll answer, to the best of its ability, based on the data you fed it previously, but unlike other programming paradigms, you're not really telling the computer what to do.
It's just very specialized, and not suited for general purpose programming. And the things it is specialized for are not often needed.
Functional programming, on the other hand, is definitely general purpose programming, and can be used for anything, with no major problems. Which is why the latter is catching on, and logic programming isn't. I think... :)
我对 Prolog 遇到的第一个问题是它不是一种逻辑编程语言。 它缺乏“真”、“假”、“不知道”的三值标准逻辑，将后两者混为一谈。 也就是说，这两个真值实际上是“可以显示”和“不能显示”。 这给 Prolog 带来了“非”概念的真正问题，这对于逻辑推理来说是非常基本的。
在正常逻辑中，通过反驳其否定来证明一个命题是完全合理的，这被称为“反证法”。 （是的，有些人试图在不使用数学的情况下重建数学，但这有点深奥。）这在 Prolog 中根本行不通，因为证明错误和未证明任何东西之间没有区别。
因此，当我在Prolog中做一个类项目时，每当我将其视为编程逻辑时，我就会遇到麻烦。 我总是会做一些需要实际否定的事情。 也许其他人不会这样做，但我最终将其视为一种模式匹配语言，然后毫不费力地完成了该项目。
不可能有一种真正的基于逻辑的语言，程序员可以编写东西并真正依赖结果。 一阶谓词演算（即，带有变量、真或假函数、“与”、“或”、“非”、“对于所有”和“存在”的逻辑）肯定是不可判定的。 （毕竟，我们不断向数学家倒咖啡而不是机械地生成所有可能的定理，这是有原因的。）程序员无法先验地知道给定的命题是否会被证明，即使程序员已经知道它是真是假。
编辑：我还忘记了正确排序条款的关键必要性。 从逻辑上讲，你写下来的顺序并不重要。 在 Prolog 中，我不断陷入无限循环，直到我不再将其视为基于逻辑的语言。 再说一次，它作为一种模式匹配语言有一些很好的功能，但它不是逻辑，在我看来，它就像一种语言的一门小马。 YMMV，但其他一些人似乎同意我的观点。
The first problem I had with Prolog is that it isn't a logic programming language. It lacks the three-valued standard logic of "true", "false", and "don't know", conflating the two latter ones. In other words, the two truth values are actually "can be shown" and "cannot be shown". This gives Prolog real problems with the idea of "not", which is pretty basic to logical reasoning.
In normal logic, it's perfectly reasonable to prove a proposition by disproving its negation, this being called "reductio ad absurdum". (Yes, there are people who have tried to reconstruct mathematics without using it, but that's getting a bit esoteric.) This simply doesn't work in Prolog, since there's no distinction between proved false and not proved anything.
Therefore, when I did a class project in Prolog, I got into trouble whenever I thought of it as programming logic. I'd always wind up doing something that required actual negation. Perhaps other people don't do that, but I wound up thinking of it as a pattern-matching language, and then had little difficulty finishing the project.
It's not possible to have a true logic-based language where the programmer can write things and really rely on the results. First-order predicate calculus (i.e., logic with variables, true-or-false functions, "and", "or", "not", "for all", and "there exists") is positively undecidable. (There are reasons why we keep pouring coffee into mathematicians rather than generate all possible theorems mechanically, after all.) There is no way for a programmer to know a priori whether a given proposition will be proved or not, even if the programmer already knows it to be true or false.
Edit: I also forgot the critical necessity of ordering clauses properly. In logic, it doesn't matter in what order you write things down. In Prolog, I kept getting into infinite loops, until I stopped treating it as a logic-based language. Again, it has some nice features as a pattern-matching language, but it isn't logic, and it seemed to me like a one-trick pony of a language. YMMV, but some other people seem to agree with me.
函数式编程变得越来越流行，因为它在应用于多线程编程时具有一些重要的好处，并且随着我们越来越多地转向多核处理器，多线程编程将变得越来越重要。
Functional programming is becoming more popular because it has some important benefits when applied to multi-threaded programming, and as we move more and more toward multi-core processors multi-theaded programming will become more and more important.
根据我自己使用 Prolog 的经验，它非常适合特定任务，但作为一种通用编程语言，我认为它根本不像许多其他语言那么灵活。
From my own experience with Prolog it is very nice for specific tasks, but as a general purpose programming language it is simply not as flexible as a lot of other languages in my opinion.
事实上，Prolog 非常适合特定任务，但在我 11 年的工作经验中，我从未遇到过 Prolog 是最佳解决方案的问题。 只是 Prolog 适合解决的问题非常罕见。
It is a fact that Prolog is very nice for specific tasks but in my 11 years of work experience I have never had a problem where Prolog would be the best solution. It is just a matter that the kind of problems where Prolog would be ideal, is very rare.
当我在大学的人工智能课程中学习 Prolog 时，我发现它绝对令人着迷，但我现在只能想到在人工智能之外使用它的少数情况。 即使在这些情况下，我也不想使用它。 我花了很长时间才最终“掌握”了Prolog，当我这样做时，我认为它很棒，但我立即发现它的用处有限。
尽管如此，我还是强烈建议学习它，如果没有其他原因，只是为了学习以另一种不同的方式进行编程。 能够从许多不同的角度看待问题绝对会让你成为一个更好的程序员。
I found Prolog to be absolutely fascinating when I took it in my AI classes in college, but I can only think of a handful of situations where I'd use it outside of AI today. And even in those situations, I'd rather not use it. It took me a long time to finally "get" Prolog, and when I did, I thought it was great, but I immediately saw it's limited range of usefulness.
Still, I highly recommend learning it, if for no other reason than to learn to approach programming in another different way. Being able to look at a problem from many different vantage points absolutely makes you a better programmer.
这是使用正确工具完成工作的标准情况。 在某些情况下，您确实会看到逻辑编程：它们通常被称为基于规则或专家系统之类的东西。
在您的可计算性理论课程中，您将讨论以下事实：所有这些通用理论目的语言实际上是等价的（从数学的角度来看）。 然而，原型设计和长期开发是非常不同的领域。 因此，在基于规则的系统中，您完全有可能使用 Prolog 之类的东西来制定规则集（如果这适合您），然后在您的交付平台（例如 Java）上实现最终系统。
顺便说一句，我一直很喜欢 Prolog 对几乎所有事情的回答都是“不”。
This is the standard case of the using the right tool for the job. You do see logic programming in certain situations: they're usually called something like rule-based or expert systems.
In your computability theory course, you'll discuss the fact that all of these general purpose languages are effectively equivalent (from a mathematical standpoint). However, prototyping and long-term development are very different domains. So, it's entirely possible that, in a rule-based system, you might work out your ruleset using something like Prolog (if that works well for you) and then later implement the final system on your delivery platform (e.g., Java).
BTW, I always loved the way Prolog's answer to almost everything is "no."
事实上，您在 AI 课程中开始使用 Prolog 应该是一个提示。 人工智能也没有流行起来。
我记得早在 80 年代，我曾挑战一位教授展示人工智能的重要用途（好吧，“嘲笑”是一个更准确的词，但那时我还年轻）。当时他做不到，而今天，我怀疑他正在教学大约 1/10 他当时所热衷的人工智能应用程序
也许同样适用于 Prolog，我不记得我上次看到一家公司正在寻找 Prolog 经验，或者也许我从未见过。并忽略了它。
The fact that you're starting on Prolog in your AI class should be a hint. AI hasn't caught on too well, either.
I remember back in '80 challenging a professor to demonstrate significant uses for AI (ok, "scoffing' would be a more accurate term, but I was younger then). He couldn't do it then, and today, I suspect he's teaching about 1/10th the applications for AI that he was raving about back then.
Maybe the same applies to Prolog. I don't remember the last time I've seen a company looking for Prolog experience. Maybe never, or maybe I saw it and ignored it.
此讨论线程中呼吁使用真正声明性的逻辑编程语言（可以按任何顺序执行语句），并且可以将其用于查询数据库以替代 SQL。
Datalog 就是您要查找的内容。 例如，它用于数据集成、安全应用程序和程序分析。
There are calls in this discussion thread for a logic programming language that is truly declarative (statements can be made in any order), and that could be used for querying database as a replacement of SQL.
Datalog is what you are looking for. It's used in data integration, security applications and program analysis, for example.