Un précédent historique pour expliquer pourquoi Prolog est moins populaire que SQL dans la programmation impérative? [fermé]

12

Il semble que l'écriture déclarative SQL soit très populaire dans la programmation impérative . Cependant, il semble également que l'écriture de Déclaratif Prolog puisse économiser beaucoup de complexité mais ce n'est pas très courant.

Existe-t-il un précédent historique pour cette préférence apparente de SQL sur Prolog?

Si la raison est le manque de prise en charge native par les langues impératives , est-il possible de répondre pourquoi les créateurs de langues n'ont pas trouvé utile de prendre Prologen charge nativement en premier lieu?


Pour fournir des exemples spécifiques:

Exemple 1 L'
évaluation d'une demande de prêt peut ne prendre que quelques lignes de code Prolog, comme la SELECT/JOINrequête qui ne contient que quelques lignes de code SQL, mais il semble que l'avantage ne soit pas aussi évident que SQL.

Exemple 2
Voici un autre exemple de problème et la solution dans Prolog. Le programme de logique de contrainte suivant représente un ensemble de données simplifié de l' histoire de John en tant qu'enseignant:

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 clause d'objectif suivante interroge l'ensemble de données pour savoir quand John a à la fois enseigné la logique et était professeur :

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

Résultat:

2010  T, T  2012.

Dans l'exemple ci-dessus, il sera facile SQLd'obtenir le même résultat. Mais supposons que vous ayez ces données dans un fichier Array. Ensuite, il n'est pas aussi facile d'obtenir les mêmes résultats en utilisant SQL. Et dans le cas de données stockées dans un tableau, je pense que le code Prolog sera plus facile à écrire et à maintenir.

53777A
la source
8
Vous voudrez peut-être réduire l'aspect délirant.
4
La plupart du texte ressemble à une diatribe contre les personnes qui n'utilisent pas Prolog. Il y a une question qui mérite d'être posée, mais les autres choses (la diatribe) attirent les votes négatifs et découragent les gens qui pourraient apporter une réponse. En d'autres termes, je vous suggère d'essayer de formuler votre question d'une manière plus charitable.
6
"Par exemple, évaluer une demande de prêt peut n'être que quelques lignes de code dans Prolog" Je n'achète pas cela, pour la même raison que toute application qui en vaut la peine utilisera des tonnes de requêtes SQL personnalisées ou générées.
Euphoric
7
Peut-être que je manque quelque chose, mais je pense que la réponse ici est «les gens utilisent SQL parce que c'est ce que les bases de données prennent en charge» .
GrandmasterB
3
Ils font usage Prolog ... eh bien ... en fait ... ils font usage moteurs de règles , qui sont « ad hoc, de manière informelle spécifiée, truffé de bogues, la mise en œuvre lente de la moitié de Prolog » .
Jörg W Mittag

Réponses:

19

Je crois que c'est principalement une chose historique.

SQL était principalement utilisé dans les entreprises pour créer des applications commerciales. Certaines entreprises construisent leur dynamisme en vendant des solutions SQL et elles ont utilisé leur argent pour faire de la publicité et pousser SQL dans l'esprit de beaucoup. Cela a été particulièrement renforcé par l'importance des données pour les hommes d'affaires. C'est pourquoi SQL a conquis ses nombreux concurrents et est si largement connu et utilisé encore aujourd'hui.

Prolog, d'autre part, était surtout connu dans le domaine universitaire, généralement dans le domaine de l'intelligence artificielle. Les universitaires poussent rarement leurs outils et leurs idées sur les autres comme le font les entreprises. Cela nécessite généralement qu'une entreprise annonce une technologie née dans le monde universitaire pour qu'elle se propage parmi les développeurs communs. De plus, bien que les données soient extrêmement importantes, les "règles métier" ne le sont pas. Bien qu'elles puissent sembler importantes, elles sont beaucoup moins importantes que les données. Les règles commerciales peuvent généralement être fixées facilement. Essayer de réparer des données "cassées" est généralement un problème beaucoup plus difficile. Les entreprises se sont donc davantage concentrées sur l'obtention de leurs solutions de données que sur leurs solutions de règles métier.

Euphorique
la source
2
"Il faut généralement qu'une entreprise annonce une technologie née dans le monde universitaire pour qu'elle se propage parmi les développeurs courants.": Vrai. Beaucoup de bonnes idées sont développées dans le monde universitaire et plus tard rendues populaires par les entreprises qui ont le pouvoir de le faire. +1
Giorgio
6

La raison est en fait assez simple. Cela n'a rien à voir avec l'utilité du langage pour une tâche donnée et tout à voir avec la maintenabilité du code.

En lisant une instruction SQL, de nombreux développeurs pourront déterminer ce que font la plupart des requêtes de base sans connaître la langue. Ils peuvent avoir plus de difficulté dans le cas d'exemples complexes, mais l'adaptation du code existant ou le travail à partir d'exemples est relativement facile. La barrière à la compréhension est assez faible pour la grande majorité des requêtes.

Vous lisez quelques lignes de prologue et de nombreux développeurs vont légèrement croiser les yeux et laisser la tâche à quelqu'un d'autre, et éventuellement aller se coucher. La syntaxe de prédicat de prolog ne se prête tout simplement pas à une lecture facile.

Mise à jour:

Sur la base de l'exemple de code, les langages qui implémentent des collections devraient bien fonctionner. J'ai implémenté une solution en C # / Linq et elle n'était pas significativement plus grande que l'échantillon prologue (une fois que vous avez pris en compte le typage statique et les définitions nécessaires). Il y avait une étape supplémentaire impliquée dans certains travaux intérimaires pour fusionner les listes pour faire une seule chronologie à rechercher, mais ce n'était pas une quantité importante de travail.

James Snell
la source
14
Il est vrai que SQL a opté pour une syntaxe ultra-verbeuse et «naturelle» de qualité COBOL qui la rend «facile» à lire. Mais je doute fortement que quelqu'un qui ne connaît pas SQL puisse comprendre correctement une instruction moyennement compliquée avec quelques joins count(*)ou quelque chose comme ça. Si nous comprenons les bases de SQL, c'est parce que nous devons parfois utiliser ce langage et que nous avons donc dû apprendre ces bases. Le stockage de données relationnelles est un besoin beaucoup plus courant que la résolution de systèmes logiques, donc aucune nécessité comparable forte d'apprendre Prolog ne se présente.
amon
3
@amon Cela ressemble au début d'une bonne réponse :-)
svick
1
La barrière pour apprendre le SQL pourrait être abaissée en raison de la lisibilité, le prologue pourrait repousser les gens en raison de la syntaxe, je suis entièrement d'accord avec cela. Mais en effet, sans connaître SQL, comprendre les sous-requêtes et quelques jointures n'est pas si trivial. Mais la barrière inférieure lors du démarrage avec des requêtes simples est sûrement une raison pour laquelle les gens utiliseraient SQL au lieu de Prolog pour commencer. :)
Dylan Meeus
4
@JamesSnell Désolé mais -1. Ce que vous prétendez ne correspond à aucun 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
1
@JamesSnell RegEx sont cryptiques, difficiles à écrire, à déboguer, à maintenir et à modifier ou à étendre, mais ils sont extrêmement populaires. Si vous aviez raison, RegEx n'aurait jamais dû obtenir sa popularité actuelle entre les développeurs et les créateurs de langage.
53777A
4

Il y a une autre raison. En pratique, SQL est utile pour les données persistantes sur disque. Les bases de données sont donc utilisées pour stocker des données pendant une "longue" période (plusieurs mois). Chaque base de données SQL (par exemple PostgreSQL, MySQL, Oracle, ....) gère les données sur les disques (ou SSD, c'est-à-dire le matériel qui pourrait conserver les données s'il était correctement éteint). Cependant, la plupart des implémentations Prolog que je connais fonctionnent en mémoire et ne peuvent pas être utilisées pour conserver des données de manière fiable (données persistantes après une coupure de courant, au moins programmée). Et les implémentations SQL peuvent gérer des téraoctets de données ....

Bien sûr, un SGBD n'écrit pas immédiatement sur le disque (mais plus tard). Mais les interprètes Prolog dont j'ai entendu parler n'écrivent jamais (implicitement) leurs bases de faits et de règles pour les conserver sur le disque.

(Certaines implémentations de langage ont une capacité de persistance, par exemple SBCL avec save-lisp-and-die... mais je ne connais aucun Prolog faisant cela).

Pragmatiquement parlant, SQL est pour les bases de données -sur les disques-, mais Prolog est un langage de programmation (pour le code source dans les fichiers textuels).

Basile Starynkevitch
la source
1
Je ne pense pas, car aucune base de données SQL ne fonctionne strictement avec les E / S disque, car cela serait très inefficace (il y a toujours des données en mémoire), et il n'y a aucun obstacle technique à la sérialisation des contraintes de prologue sur le disque que je peut penser à l'heure actuelle.
idobie
3
En théorie, SQL est un langage de requête et ne se soucie pas de la façon dont les données sont stockées, tant que les données sont décrites par un modèle relationnel. SQL n'est qu'une interface, pas un paradigme. Il existe des bases de données utilisant SQL qui fonctionnent purement ou partiellement dans la mémoire non persistante. Il serait même possible pour une base de données utilisant SQL de stocker des données sous forme de faits Prolog! [la citation nécessaire] Après tout, les faits décrivent simplement les relations. Inversement, il serait probablement possible pour un moteur Prolog de stocker des faits sur le disque comme une base de données plutôt que de tout charger en mémoire.
amon
1
Théoriquement oui, mais pratiquement SQL stocke sur disque, et c'est souvent essentiel
Basile Starynkevitch
1
@BasileStarynkevitch Les règles et les faits sont écrits sur le code source qui persiste sur le disque. Pourquoi les stockeriez-vous à la place? Que voulez-vous dire par Prolog ne peut pas conserver les données? Ce n'est pas censé faire ça. C'est pourquoi les bases de données existent. Pourriez-vous développer davantage.
53777A
1
Exactement, SQL est pour les bases de données et Prolog est un langage de programmation. C'est mon point.
Basile Starynkevitch,
1

Un aspect non mentionné jusqu'à présent est la pression pour des systèmes "ouverts" dans les années 80 et 90. Dans de nombreux endroits, les éditeurs de logiciels devraient fournir un accès standard aux données de leurs bases de données. À l'époque, SQL était une norme établie qui était bien connue et comprise; Prolog était assez ésotérique et académique. Une fois que vous avez commencé à obtenir des interfaces comme ODBC pour connecter facilement des systèmes, personne n'était intéressé par les autres technologies.

J'ai travaillé dans un endroit à la fin des années 80 qui avait une base de données ISAM assez réussie qui a été forcée par les pressions du marché / les réglementations d'approvisionnement à ajouter une interface SQL.

Dave
la source