¿El precedente histórico de por qué Prolog es menos popular que SQL en la programación imperativa? [cerrado]

12

Parece que escribir Declarative SQL es muy popular en Imperative Programming . Sin embargo, también parece que escribir Declarative Prolog podría ahorrar mucha complejidad, pero esto no es muy común.

¿Existe un precedente histórico para esta aparente preferencia de SQL sobre Prolog?

Si la razón es la falta de soporte nativo por parte de los idiomas Imperative , ¿es posible responder por qué a los creadores del lenguaje no les pareció útil en primer lugar admitir Prolog ?

Para proporcionar algunos ejemplos específicos:

Ejemplo 1
La evaluación de una solicitud de préstamo podría ser solo unas pocas líneas de código en Prolog , como la consulta SELECT/JOIN que es solo unas pocas líneas de código en SQL , pero parece que la ventaja no es tan obvia como SQL .

Ejemplo 2
Aquí hay otro problema de ejemplo y la solución en Prolog. El siguiente programa de lógica de restricción representa un conjunto de datos simplificado de la historia de john's como profesor:

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.

La siguiente cláusula de objetivo consulta el conjunto de datos para averiguar cuándo John enseñó lógica y era un profesor :

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

Resultado:

2010 ≤ T, T ≤ 2012.

En el ejemplo anterior, será fácil con SQL obtener el mismo resultado. Pero suponga que tiene estos datos en un Array . Entonces no es tan fácil obtener los mismos resultados utilizando SQL . Y en el caso de los datos almacenados en una matriz, creo que el código Prolog será más fácil de escribir y mantener.

    
pregunta 53777A 07.12.2014 - 16:07

4 respuestas

19

Creo que esto es principalmente cosa histórica.

SQL se usó principalmente en negocios para hacer aplicaciones de negocios. Algunas compañías construyen su vitalidad en la venta de soluciones de SQL y utilizan su dinero para publicitar y llevar a SQL a la mente de muchos. Esto fue especialmente potenciado por la importancia de los datos para los empresarios. Esta es la razón por la que el SQL ganó a sus muchos competidores y es tan ampliamente conocido y utilizado incluso hoy en día.

Por otro lado, el prólogo era conocido principalmente en la esfera académica, generalmente en el área de la inteligencia artificial. Las personas académicas rara vez presionan sus herramientas e ideas sobre otros de una manera en que lo hacen los negocios. Por lo general, se requiere que alguna compañía anuncie una tecnología que nació en el mundo académico para que se propague entre los desarrolladores comunes. Además, si bien los datos son extremadamente importantes, las "reglas de negocios" no lo son. Si bien pueden parecer importantes, son mucho menos importantes que los datos. Las reglas de negocios generalmente se pueden arreglar fácilmente. Tratar de arreglar los datos "rotos" suele ser un problema mucho más difícil. Así que las empresas se enfocaron mucho más en obtener sus soluciones de datos que sus soluciones de reglas de negocios.

    
respondido por el Euphoric 07.12.2014 - 18:42
6

La razón es en realidad bastante simple. No tiene nada que ver con lo útil que es el lenguaje para una tarea determinada y todo lo relacionado con la facilidad de mantenimiento del código.

Al leer una declaración SQL, muchos desarrolladores podrán determinar qué hacen las consultas más básicas sin saber el idioma. Pueden tener más dificultades en el caso de los ejemplos complejos, pero adaptar el código existente o trabajar con muestras es relativamente fácil. La barrera para la comprensión es bastante baja para la gran mayoría de las consultas.

Leíste unas pocas líneas de prólogo y muchos desarrolladores pasarán un poco bizco y dejarán la tarea para otra persona, y posiblemente irán a echarse. La sintaxis predicada de prólogo simplemente no se presta a una lectura fácil.

Actualización:

Según el ejemplo de código, los idiomas que implementan colecciones deberían funcionar bien. Implementé una solución en C # / Linq y no fue significativamente más grande que la muestra del prólogo (una vez que contabilizó la escritura estática y las definiciones requeridas). Hubo un paso adicional involucrado en algún trabajo interino para fusionar las listas para hacer una sola línea de tiempo para ser buscado, pero no fue una cantidad significativa de trabajo.

    
respondido por el James Snell 07.12.2014 - 17:07
4

Hay otra razón. En términos prácticos, SQL es útil para los datos que se conservan en el disco. Por lo tanto, las bases de datos se utilizan para almacenar datos durante un tiempo "largo" (varios meses). Cada base de datos SQL (por ejemplo, PostgreSQL, MySQL, Oracle, ...) administra datos en discos (o SSD, es decir, hardware que podría mantener los datos si se apaga correctamente). Sin embargo, la mayoría de las implementaciones de Prolog que conozco funcionan en la memoria y no se pueden utilizar para mantener los datos de manera confiable (datos persistentes después de un corte de energía, al menos uno programado). Y las implementaciones de SQL pueden tratar con terabytes de datos ...

Por supuesto, un DBMS no escribe inmediatamente en el disco (sino más tarde). Pero los intérpretes de Prolog que escuché nunca escriben (implícitamente) su hecho y su Bases de reglas para persistirlas en el disco.

(Algunas implementaciones de lenguaje tienen capacidad de persistencia, por ejemplo, SBCL con save-lisp-and-die ... pero no conozco a Prolog haciendo eso).

Hablando de manera pragmática, SQL es para bases de datos (en discos), pero Prolog es un lenguaje de programación (para el código fuente en archivos de texto).

    
respondido por el Basile Starynkevitch 07.12.2014 - 20:36
1

Un aspecto no mencionado hasta ahora es el impulso a los sistemas "abiertos" en los años ochenta y noventa. En muchos lugares, los proveedores de software tendrían que proporcionar acceso estándar de la industria a los datos en sus bases de datos. En ese momento, SQL era un estándar establecido que era bien conocido y comprendido; El prólogo era bastante esotérico y académico. Una vez que comenzó a obtener interfaces como ODBC para conectar sistemas fácilmente, nadie estaba interesado en buscar otras tecnologías.

Trabajé en un lugar a finales de los 80 que tenía una base de datos ISAM bastante exitosa que se vio obligada por las presiones del mercado / regulaciones de adquisición para agregar una interfaz SQL a.

    
respondido por el dave 09.12.2014 - 06:24

Lea otras preguntas en las etiquetas