Precedente histórico de por que o Prolog é menos popular que o SQL na Programação Imperativa? [fechadas]

Parece que escrever Declarative SQL é muito popular na Programação Imperativa . No entanto, também parece que escrever Declarative Prolog poderia economizar muita complexidade, mas isso não é muito comum.

Existe um precedente histórico para essa aparente preferência do SQL sobre o Prolog?

Se o motivo é a falta de suporte nativo por idiomas Imperative , é possível responder por que os criadores de idiomas não acharam útil dar suporte nativo Prologem primeiro lugar?

Para fornecer alguns exemplos específicos:

Exemplo 1 A
avaliação de um pedido de empréstimo pode ter apenas algumas linhas de código Prolog, como a SELECT/JOINconsulta que contém apenas algumas linhas de código SQL, mas parece que a vantagem não é tão óbvia quanto SQL.

Exemplo 2
Aqui está outro exemplo de problema e a solução no Prolog. O seguinte programa de lógica de restrição representa um conjunto de dados simplificado da história de john como professor:

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.

A seguinte cláusula de objetivo consulta o conjunto de dados para descobrir quando John ensinou lógica e foi professor :

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

Resultado:

2010 ≤ T, T ≤ 2012.

No exemplo acima, será fácil SQLobter o mesmo resultado. Mas suponha que você tenha esses dados em um Array. Então não é tão fácil obter os mesmos resultados usando SQL. E, no caso de dados armazenados em uma matriz, acredito que o código do Prolog será mais fácil de escrever e manter.

Eu acredito que isso é principalmente coisa histórica.

O SQL foi usado principalmente nas empresas para criar aplicativos de negócios. Algumas empresas constroem sua vida com a venda de soluções SQL e usam seu dinheiro para anunciar e colocar o SQL na mente de muitos. Isso foi especialmente influenciado pela importância dos dados para as pessoas de negócios. É por isso que o SQL conquistou muitos concorrentes e é tão amplamente conhecido e usado até hoje.

O prólogo, por outro lado, era mais conhecido na esfera acadêmica, geralmente na área de inteligência artificial. Os acadêmicos raramente impõem suas ferramentas e idéias sobre os outros da maneira que os negócios fazem. Geralmente, exige que uma empresa anuncie uma tecnologia que nasceu na academia para se espalhar entre desenvolvedores comuns. Além disso, embora os dados sejam extremamente importantes, as "regras de negócios" não são assim. Embora possam parecer importantes, são muito menos importantes que os dados. As regras de negócios geralmente podem ser corrigidas facilmente. Tentar corrigir dados "quebrados" geralmente é um problema muito mais difícil. Portanto, as empresas se concentraram muito mais em obter suas soluções de dados do que suas soluções de regras de negócios.

A razão é realmente bastante simples. Não tem nada a ver com a utilidade da linguagem para uma determinada tarefa e tudo a ver com a manutenção do código.

Lendo uma instrução SQL, muitos desenvolvedores poderão determinar o que as consultas mais básicas fazem sem conhecer o idioma. Eles podem ter mais dificuldade no caso de exemplos complexos, mas adaptar o código existente ou trabalhar com amostras é relativamente fácil. A barreira à compreensão é bastante baixa para a grande maioria das consultas.

Você lê algumas linhas de prólogo e muitos desenvolvedores ficam com os olhos cruzados e deixam a tarefa para outra pessoa, e possivelmente se deitam. A sintaxe predicada do prólogo simplesmente não se presta a uma leitura fácil.

Atualizar:

Com base no exemplo de código, os idiomas que implementam coleções devem se sair bem. Eu implementei uma solução em C # / Linq e ela não era significativamente maior que a amostra do prólogo (depois que você considerou a tipagem estática e as definições necessárias). Houve uma etapa extra envolvida em algum trabalho provisório para mesclar as listas para criar uma única linha do tempo a ser pesquisada, mas não foi uma quantidade significativa de trabalho.

Há outra razão. Na prática, o SQL é útil para dados persistidos no disco. Portanto, os bancos de dados são usados ​​para armazenar dados por um período "longo" (vários meses). Todo banco de dados SQL (por exemplo, PostgreSQL, MySQL, Oracle, ....) está gerenciando dados em discos (ou SSDs, ou seja, hardware que pode manter os dados se desligado adequadamente). No entanto, a maioria das implementações do Prolog que eu conheço estão trabalhando na memória e não podem ser usadas para manter os dados com segurança (dados persistentes após uma queda de energia, pelo menos uma programada). E as implementações de SQL podem lidar com terabytes de dados ....

Obviamente, um DBMS não grava imediatamente no disco (mas depois). Mas os intérpretes do Prolog de que ouvi falar nunca escrevem (implicitamente) suas bases de fatos e regras para persistir em disco.

(Algumas implementações de linguagem têm capacidade de persistência, por exemplo, SBCL com save-lisp-and-die... mas não conheço nenhum prólogo fazendo isso).

Pragmaticamente falando, o SQL é para bancos de dados - em discos -, mas o Prolog é uma linguagem de programação (para código fonte em arquivos de texto).

Um aspecto não mencionado até agora é a pressão por sistemas "abertos" nas décadas de 1980 e 1990. Em muitos lugares, os fornecedores de software teriam que fornecer acesso padrão do setor aos dados em seus bancos de dados. Na época, o SQL era um padrão estabelecido que era bem conhecido e entendido; Prolog era bastante esotérico e acadêmico. Depois que você começou a obter interfaces como ODBC para conectar sistemas facilmente, ninguém estava interessado em examinar outras tecnologias.

Eu trabalhei em um local no final dos anos 80, que tinha um banco de dados ISAM bastante bem-sucedido, forçado pelas pressões do mercado / regulamentações de compras para adicionar uma interface SQL.