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


12

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.


8
Você pode discar para o aspecto desabafo.

4
A maior parte do texto soa como um discurso retórico contra pessoas que não usam o Prolog. Há uma pergunta que vale a pena fazer contida nela, mas a outra coisa (o discurso retórico) atrai votos negativos e desativa as pessoas que poderiam contribuir com uma resposta. Em outras palavras, sugiro que tente redigir sua pergunta de uma maneira mais caridosa.

6
"Por exemplo, avaliar um pedido de empréstimo pode ser apenas algumas linhas de código no Prolog" Eu não compro isso, pelo mesmo motivo que qualquer aplicativo que se preze usará toneladas de consultas SQL personalizadas ou geradas.
Euphoric

7
Talvez esteja faltando alguma coisa, mas acho que a resposta aqui é 'as pessoas usam SQL porque é isso que os bancos de dados suportam' .
GrandmasterB

3
Eles fazem uso Prolog ... bem ... na verdade ... eles fazem uso Regras motores , que são "ad hoc, informalmente especificada, cheia de defeitos, implementação lenta de metade do Prolog" .
Jörg W Mittag

Respostas:


19

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.


2
"Geralmente, exige que uma empresa anuncie uma tecnologia que nasceu na academia para se espalhar entre desenvolvedores comuns.": Verdade. Muitas boas idéias são desenvolvidas na academia e posteriormente tornadas populares por empresas que têm o poder de marketing para fazê-lo. +1
Giorgio

6

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.


14
É verdade que o SQL optou pela sintaxe ultra-detalhada e "natural" de nível COBOL, que facilita a leitura. Mas duvido muito que alguém que não conheça o SQL possa entender adequadamente uma declaração meio complicada com alguns joins count(*)ou algo assim. Se entendemos o básico do SQL, é porque ocasionalmente temos que usar essa linguagem e, portanto, tivemos que aprender esse básico. O armazenamento de dados relacionais é uma necessidade muito mais comum do que a solução de sistemas lógicos, portanto, nenhuma necessidade comparativamente forte de aprender o Prolog se apresenta.
amon

3
@amon que soa como o início de uma boa resposta :-)
svick

1
A barreira para aprender SQL pode ser reduzida por causa da legibilidade, o prólogo pode afastar as pessoas devido à sintaxe, eu concordo totalmente com isso. Mas, de fato, sem conhecer o SQL, entender subconsultas e algumas junções não é tão trivial. Mas a barreira mais baixa ao iniciar consultas simples é certamente uma razão pela qual as pessoas usariam o SQL em vez do Prolog para iniciar. :)
Dylan Meeus

4
@JamesSnell Desculpe, mas -1. O que você está reivindicando não corresponde a nenhum 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})$.
precisa saber é o seguinte

1
O @JamesSnell RegEx é enigmático, difícil de escrever, depurar, manter e modificar ou estender, mas é extremamente popular. Se você estivesse certo, o RegEx nunca deveria ter recebido sua popularidade atual entre desenvolvedores e criadores de idiomas.
precisa saber é o seguinte

4

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).


1
Acho que não, já que nenhum banco de dados SQL funciona estritamente com E / S de disco, pois isso seria muito ineficiente (há alguns dados na memória o tempo todo) e não há impedimento técnico para serializar restrições de prólogo no disco que eu pode pensar no momento.
Idolomeiro

3
Teoricamente falando, o SQL é uma linguagem de consulta e não se importa com o modo como os dados são armazenados, desde que os dados sejam descritos por um modelo relacional. SQL é apenas uma interface, não um paradigma. Existem bancos de dados que usam SQL que operam pura ou parcialmente na memória não persistente. Seria até possível para um banco de dados que usa SQL armazenar dados na forma de fatos do Prolog! [citação necessário] Afinal, fatos meramente descrevem relações. Por outro lado, provavelmente seria possível para um mecanismo Prolog armazenar fatos de maneira semelhante a um banco de dados em disco, em vez de carregar tudo na memória.
amon

1
Teoricamente sim, mas praticamente SQL é armazenado em disco, e que é muitas vezes essencial
Basile Starynkevitch

1
As regras e fatos do @BasileStarynkevitch estão escritos no código-fonte que persiste no disco. Por que você os armazenaria no banco de dados? O que você quer dizer com Prolog não pode manter os dados? Não é para fazer isso. É por isso que os bancos de dados existem. Poderia, por favor, elaborar mais.
precisa saber é o seguinte

1
Exatamente, o SQL é para bancos de dados e o Prolog é uma linguagem de programação. Esse é o meu ponto.
Basile Starynkevitch

1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.