Parece que la escritura declarativa SQL es muy popular en la programación imperativa . 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 lenguajes imperativos , entonces ¿es posible responder por qué los creadores del lenguaje no encontraron útil el soporte nativo Prologen primer lugar?
Para proporcionar algunos ejemplos específicos:
Ejemplo 1 La
evaluación de una solicitud de préstamo podría incluir solo unas pocas líneas de código Prolog, como la SELECT/JOINconsulta que solo contiene unas pocas líneas de código 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 como maestro:
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 objetivo consulta el conjunto de datos para averiguar cuándo juan enseñó lógica y fue profesor :
:- teaches(john, logic, T), rank(john, professor, T).Resultado:
2010 ≤ T, T ≤ 2012.En el ejemplo anterior, será fácil SQLobtener el mismo resultado. Pero suponga que tiene estos datos en un Array. Entonces no es tan fácil obtener los mismos resultados usando 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.
fuente
Respuestas:
Creo que esto es principalmente algo histórico.
SQL se utilizó principalmente en empresas para hacer aplicaciones comerciales. Algunas compañías construyen su estilo de vida vendiendo soluciones SQL y usaron su dinero para publicitar y empujar SQL a la mente de muchos. Esto fue especialmente potenciado por la importancia de los datos para la gente de negocios. Es por eso que SQL se ganó a sus muchos competidores y es tan ampliamente conocido y utilizado incluso hoy en día.
Por otro lado, Prolog se conocía principalmente en el ámbito académico, generalmente en el área de la inteligencia artificial. Los académicos rara vez empujan sus herramientas e ideas a los demás como lo hacen los negocios. Por lo general, requiere que alguna compañía anuncie una tecnología que nació en la academia para que se difunda entre los desarrolladores comunes. Además, aunque los datos son extremadamente importantes, las "reglas comerciales" no lo son. Si bien pueden parecer importantes, son mucho menos importantes que los datos. Las reglas comerciales generalmente se pueden arreglar fácilmente. Intentar arreglar datos "rotos" suele ser un problema mucho más difícil. Por lo tanto, las empresas se centraron mucho más en obtener sus soluciones de datos que sus soluciones de reglas comerciales.
fuente
La razón es realmente bastante simple. No tiene nada que ver con lo útil que es el lenguaje para una tarea determinada y todo lo que tiene que ver 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 conocer el idioma. Puede que les resulte más difícil en el caso de ejemplos complejos, pero adaptar el código existente o trabajar a partir de muestras es relativamente fácil. La barrera para la comprensión es bastante baja para la gran mayoría de las consultas.
Lees unas pocas líneas de prólogo y muchos desarrolladores se irán con los ojos cruzados y dejarán la tarea a otra persona, y posiblemente irán a acostarse. La sintaxis de predicado de prolog simplemente no se presta para una fácil lectura.
Actualizar:
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 era significativamente más grande que la muestra de prólogo (una vez que tomaste en cuenta el tipo estático 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 buscar, pero no fue una cantidad significativa de trabajo.
fuente
joins ocount(*)ni nada de eso. Si entendemos los conceptos básicos de SQL es porque ocasionalmente tenemos que usar ese lenguaje y, por lo tanto, tuvimos que aprender estos conceptos básicos. El almacenamiento de datos relacionales es una necesidad mucho más común que la resolución de sistemas lógicos, por lo que no se presenta una necesidad comparable de aprender Prolog.^(?:(?:(?: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})$.Hay otra razón En términos prácticos, SQL es útil para los datos persistentes 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, ...) está administrando 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 usar 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 manejar 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) sus bases de hechos y reglas para persistirlos en el disco.
(Algunas implementaciones de lenguaje tienen capacidad de persistencia, por ejemplo, SBCL con
save-lisp-and-die... pero no sé que Prolog lo haga).Hablando pragmáticamente, SQL es para bases de datos -en discos-, pero Prolog es un lenguaje de programación (para código fuente en archivos de texto).
fuente
Un aspecto no mencionado hasta ahora es el impulso de 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 entendido; Prolog fue bastante esotérico y académico. Una vez que comenzó a obtener interfaces como ODBC para conectar fácilmente los sistemas, a nadie le interesaba mirar otras tecnologías.
Trabajé en un lugar a fines de los años 80 que tenía una base de datos ISAM bastante exitosa que se vio obligada por las presiones del mercado / regulaciones de adquisición a agregar una interfaz SQL.
fuente