为什么Prolog在命令式编程中不如SQL流行的历史先例？[关闭]

12

似乎编写声明式 SQL在命令式编程中很受欢迎。但是，编写声明式代码 似乎也Prolog可以节省很多复杂性，但这并不是很常见。

对于这种明显的优先于Prolog的SQL，是否有历史的先例？

如果原因是命令式语言缺乏本机支持，那么是否有可能回答为什么语言创建者最初对本机支持没有帮助Prolog呢？

提供一些具体示例：

示例1：
评估贷款申请可能只需要输入几行代码Prolog，就像SELECT/JOIN查询只需要输入几行代码一样SQL，但似乎好处不如SQL。

示例2
这是Prolog中的另一个示例问题和解决方案。以下约束逻辑程序代表约翰作为老师的历史的简化数据集：

teaches(john, hardware, T) :- 1990 ≤ T, T < 1999.
teaches(john, software, T) :- 1999 ≤ T, T < 2005.
teaches(john, logic, T) :- 2005 ≤ T, T ≤ 2012.
rank(john, instructor, T) :- 1990 ≤ T, T < 2010.
rank(john, professor, T) :- 2010 ≤ T, T < 2014.

以下目标条款查询数据集，以查找约翰既教授逻辑又是教授的时间：

:- teaches(john, logic, T), rank(john, professor, T).

结果：

2010 ≤ T, T ≤ 2012.

在上面的示例中，很容易SQL获得相同的结果。但是，假设您在中包含此数据Array。然后，使用获得相同的结果并不容易SQL。对于将数据存储在数组中的情况，我相信Prolog代码将更易于编写和维护。

— 53777A
source

8

您可能需要拨弄低调的方面。

4

对于大多数不使用Prolog的人来说，大多数文字听起来像是在咆哮。其中包含一个值得一提的问题，但其他东西（咆哮声）吸引了人们的不满，并拒绝了那些可以提供答案的人。换句话说，我建议您尝试以更慈善的方式表述您的问题。

6

“例如，评估贷款应用程序可能只是Prolog中的几行代码”，出于相同的原因，我不赞成这样做，因为值得花费的任何应用程序都将使用大量的定制或生成的SQL查询。

— 欣快感2014年

7

也许我缺少了一些东西，但是我认为答案是“人们使用SQL，因为这就是数据库所支持的”。

— GrandmasterB 2014年

3

他们确实使用了Prolog…很好…实际上…他们确实使用了规则引擎，这些规则引擎是“临时性的，非正式指定的，bug缠身的，缓慢执行的Prolog的一半”。

— 约尔格W¯¯米塔格

19

我相信这主要是历史性的事情。

SQL主要在企业中用于制作业务应用程序。一些公司靠出售SQL解决方案来维持生计，他们用自己的钱来宣传SQL并将其推入许多人的脑海。数据对商务人士的重要性尤其增强了这种能力。这就是为什么SQL赢得了众多竞争对手的原因，并且SQL至今仍广为人知和使用。

另一方面，Prolog在学术领域最为人所知，通常在人工智能领域。学术界人士很少以商业方式将自己的工具和想法推向他人。通常，它要求某些公司宣传一种学术界诞生的技术，以便使其在普通开发人员中传播。同样，尽管数据极其重要，但“业务规则”却并非如此。尽管它们看起来很重要，但它们远不如数据重要。通常可以轻松确定业务规则。尝试修复“损坏的”数据通常是更困难的问题。因此，企业比他们的业务规则解决方案更专注于获取数据解决方案。

— 欣快的
source

2

“它通常需要一些公司宣传一项学术界诞生的技术，以使其在普通开发人员中传播。”：正确。学术界提出了许多好主意，后来又被有行销能力的公司所接受。+1

— 乔治

6

原因实际上很简单。它与语言对于给定任务的有用程度以及代码的可维护性无关。

读取SQL语句，许多开发人员将能够在不了解语言的情况下确定大多数基本查询的功能。对于复杂的示例，它们可能会比较费时，但是改编现有代码或从示例中进行工作相对容易。对于绝大多数查询而言，理解的障碍非常低。

您读了几行序言后，许多开发人员就会有些眼花cross乱，将任务留给其他人，可能还会撒谎。Prolog的谓词语法根本无法使其易于阅读。

更新：

根据代码示例，实现集合的语言应该做得很好。我在C＃/ Linq中实现了一个解决方案，它并没有比prolog示例大很多（一旦您考虑了所需的静态类型和定义）。在一些临时工作中，还需要采取额外的步骤来合并列表，以使其成为单个要搜索的时间表，但这并不是很多工作。

— 詹姆斯·斯内尔
source

14

确实，SQL采用了COBOL级超冗长和“自然”的语法，使其“易于”阅读。但是我严重怀疑，一个不了解SQL的人是否能够正确理解带有几个joins或count(*)类似名称的中等复杂语句。如果我们了解SQL的基础知识，那是因为我们有时不得不使用该语言，因此必须学习这些基础知识。关系数据存储是比解决逻辑系统更为普遍的需求，因此学习Prolog本身并没有相对强烈的必要。

— 阿蒙2014年

3

@amon这听起来像是一个不错的答案的开始:-)

— svick 2014年

1

由于易读性，可能会降低学习SQL的障碍，由于语法的原因，序言可能会抵制人们，我完全同意。但是确实，在不了解SQL的情况下，了解子查询和一些联接并不是一件容易的事。但是，从简单查询开始时的较低障碍无疑是人们使用SQL而不是Prolog来开始的原因。:)

— Dylan Meeus 2014年

4

@JamesSnell对不起，但-1。您所声称的与任何RegEx不匹配。

^(?:(?:(?:0?[13578]|1[02])(\/|-|\.)31)\1|(?:(?:0?[13-9]|1[0-2])(\/|-|\.)(?:29|30)\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:0?2(\/|-|\.)29\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:(?:0?[1-9])|(?:1[0-2]))(\/|-|\.)(?:0?[1-9]|1\d|2[0-8])\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$

。

— 53777A 2014年

1

@JamesSnell RegEx很神秘，难以编写，调试，维护和修改或扩展，但它们非常流行。如果您是对的，那么RegEx应该永远不会在开发人员和语言创建者之间受到当前的欢迎。

— 53777A 2014年

4

还有另一个原因。实际上，SQL对于在磁盘上保留的数据很有用。因此，数据库用于存储数据的时间较长（数月）。每个SQL数据库（例如PostgreSQL，MySQL，Oracle等）都在磁盘（或SSD）上管理数据，SSD即在适当关闭电源后可以保留数据的硬件。但是，我知道的大多数Prolog实现都是在内存中工作的，不能用来可靠地保存数据（断电后数据是持久的，至少是编程的）。SQL实现可以处理TB级的数据。

当然，DBMS不会立即（但稍后）将数据写入磁盘。但是我听说的Prolog解释器从不（隐式）编写其事实和规则库来将它们持久保存到磁盘。

（某些语言实现确实具有持久性，例如带有save-lisp-and-die...的SBCL，但我不知道Prolog会这样做）。

从实用上讲，SQL用于磁盘上的数据库，但是Prolog是一种编程语言（用于文本文件中的源代码）。

— 巴西勒·斯塔林凯维奇
source

1

我不这么认为，因为没有SQL数据库严格地与磁盘I / O一起工作，因为这将非常低效（始终有一些数据存储在内存中），并且序列化约束条件到磁盘的序列化没有技术上的障碍。现在可以想到的。

— idoby 2014年

3

从理论上讲，SQL是一种查询语言，并且不关心数据的存储方式，只要数据由关系模型描述即可。SQL只是一个接口，而不是范例。有使用SQL的数据库，它们完全或部分在非永久内存中运行。使用SQL的数据库甚至可能以Prolog事实的形式存储数据！毕竟，事实只是描述关系。相反，Prolog引擎有可能以类似数据库的方式在磁盘上存储事实，而不是将所有内容都加载到内存中。

— 阿蒙2014年

1

理论上没错，但实际上SQL是在磁盘上存储，这往往是必不可少的

— 巴西莱Starynkevitch

1

@BasileStarynkevitch规则和事实写在源代码上，该源代码保存在磁盘上。为什么将它们存储在数据库中呢？您所说的Prolog不能保留数据是什么意思？不应该这样做。这就是为什么数据库确实存在的原因。您能否详细说明一下。

— 53777A 2014年

1

确切地说，SQL是用于数据库的，而Prolog是一种编程语言。这就是我的意思。

— Basile Starynkevitch 2014年

1

迄今为止未提及的一方面是在1980年代和1990年代推动“开放”系统。在许多地方，软件供应商将不得不提供对其数据库中数据的行业标准访问。当时，SQL是一个公认的标准，已广为人知和理解。Prolog非常深奥而学术。一旦开始获得诸如ODBC的接口以轻松连接系统，就没有人对研究其他技术感兴趣。

我在80年代后期的一个地方工作，那里有一个相当成功的ISAM数据库，由于市场压力/采购法规的要求，该数据库不得不添加SQL接口。

— 戴夫
source