Історичний прецедент, чому Prolog менш популярний, ніж SQL в імперативному програмуванні? [зачинено]


12

Здається, що написання Декларативної програми SQL дуже популярне в імперативному програмуванні . Однак також здається, що написання Декларації Prolog могло б врятувати багато складності, але це не дуже часто.

Чи є історичний прецедент цієї очевидної переваги SQL над Prolog?

Якщо причиною є недостатня підтримка рідних мов імперативними мовами, то чи можна відповісти, чому мовознавці не вважають корисним Prologв першу чергу підтримку натурою ?


Наведіть кілька конкретних прикладів:

Приклад 1
Оцінка заявки на позику може бути лише кількома рядками коду Prolog, як і SELECT/JOINзапит, який містить лише кілька рядків коду SQL, але, здається, перевага не настільки очевидно, як SQL.

Приклад 2
Ось ще одна приклад проблеми та рішення в Prolog. Наступна логічна програма обмеження являє собою спрощений набір даних історії Джона як вчителя:

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.

Наступний пункт цілі запитує набір даних, щоб з'ясувати, коли Джон обидва викладав логіку та був професором :

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

Результат:

2010  T, T  2012.

У наведеному вище прикладі буде легко SQLотримати такий же результат. Але припустимо, що у вас є ці дані в Array. Тоді не так просто отримати однакові результати, використовуючи SQL. Що стосується даних, що зберігаються в масиві, я вважаю, що код Prolog буде простіше писати та підтримувати.


8
Можливо, ви захочете набрати аспект ощадливості.

4
Більшість тексту звучить як вигук проти людей, які не використовують Prolog. В ньому міститься запитання, яке варто задати, але інший матеріал (тираж) приваблює низових людей і відключає людей, які могли б надати відповідь. Іншими словами, я пропоную вам спробувати сформулювати своє питання більш благодійним способом.

6
"Наприклад, для оцінки заявки на позику може бути лише кілька рядків коду в Prolog." Я цього не купую, з тієї ж причини, що і будь-яка програма, яка стоїть на солі, буде використовувати тонни на замовлення або генеровані SQL запити.
Ейфорія

7
Можливо, мені чогось не вистачає, але я думаю, що тут відповідь - «люди використовують SQL, тому що це підтримується базами даних» .
GrandmasterB

3
Вони роблять використання Пролог ... ну ... на насправді ... вони роблять використання Правило Engines , які є «спеціальним, неформально-вказано, помилка охопленого, повільної реалізація половини Прологу» .
Йорг W Міттаг

Відповіді:


19

Я вважаю, що це перш за все історична річ.

SQL в основному використовувався в бізнесі для виготовлення бізнес-додатків. Деякі компанії будують свій життєвий потенціал на продажі рішень SQL, і вони використовували свої гроші для реклами та підштовхування SQL до уваги багатьох. Особливо це було наділене можливостями важливих даних для ділових людей. Ось чому SQL перемогла його багатьох конкурентів і настільки широко відома і використовується навіть сьогодні.

З іншого боку, Пролог був відомий здебільшого в академічній сфері, як правило, в області штучного інтелекту. Академічні люди рідко наштовхують свої інструменти та ідеї на інших так, як це робить бізнес. Зазвичай для реклами технології, яка народилася в академічних колах, вона розповсюджується серед поширених розробників. Крім того, хоча дані є надзвичайно важливими, "правила бізнесу" не такі. Хоча вони можуть здатися важливими, вони набагато менш важливі, ніж дані. Правила ведення бізнесу зазвичай можна легко виправити. Спроба виправити "зламані" дані, як правило, набагато складніше. Тож бізнес орієнтувався набагато більше на отримання рішень для передачі даних, ніж на рішення для бізнес-правил.


2
"Зазвичай для того, щоб якась компанія вимагала рекламувати технологію, яка народилася в академічних колах, вона розповсюджується серед поширених розробників.": Правда. У наукових колах розроблено багато хороших ідей, які згодом стали популярними компаніями, які мають маркетингову силу для цього. +1
Джорджіо

6

Причина насправді досить проста. Це не має нічого спільного з тим, наскільки корисна мова для даного завдання і все, що стосується того, наскільки корисний код.

Читаючи оператор SQL, багато розробників зможуть визначити, що роблять більшість основних запитів, не знаючи мови. У випадку складних прикладів їм може бути складніше, але адаптувати існуючий код або працювати зі зразками порівняно просто. Бар'єр для розуміння є досить низьким для переважної більшості запитів.

Ви прочитаєте кілька рядків прологів, і багато розробників злегка заплющить очі і залишать завдання комусь іншому, і, можливо, лягають. Синтаксис предиката prolog просто не піддається простому читанню.

Оновлення:

На основі зразка коду мови, які реалізують колекції, повинні добре працювати. Я реалізував рішення в C # / Linq, і воно було не значно більше, ніж зразок пролога (колись ви враховували необхідне статичне введення тексту та визначення). Був додатковий крок, який займався тимчасовою роботою, щоб об'єднати списки, щоб зробити єдину шкалу пошуку, але це не була значна кількість роботи.


14
Це правда, що SQL призначений для ультравербольного класу COBOL та «природного» синтаксису, що робить його «легким» для читання. Але я дуже сумніваюся, що той, хто не знає SQL, зможе правильно зрозуміти середньоскладний вислів з кількома joins count(*)або чимось подібним. Якщо ми розуміємо основи SQL, це тому, що нам періодично доводиться користуватися цією мовою і тому доводиться вивчати ці основи. Реляційне зберігання даних - набагато частіша потреба, ніж розв’язання логічних систем, тому немає необхідності вивчати Пролог.
амон

3
@amon Це звучить як початок хорошої відповіді :-)
svick

1
Бар'єр для вивчення SQL може бути знижений через читабельність, prolog може відбиватися від людей через синтаксис, я цілком з цим згоден. Але насправді, не знаючи розуміння підзапросів SQL та декількох приєднань, це не так банально. Але нижній бар'єр при запуску з простих запитів, безумовно, є причиною, коли люди будуть використовувати SQL замість Prolog для запуску. :)
Ділан Мейус

4
@JamesSnell Вибачте, але -1. Те, що ви заявляєте, не відповідає жодному 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 є загадковим, важко писати, налагоджувати, підтримувати та змінювати чи розширювати, але вони надзвичайно популярні. Якби ви мали рацію, тоді RegEx ніколи не повинен був би набути своєї популярності між розробниками та розробниками мови.
53777A

4

Є ще одна причина. Практично кажучи, SQL корисний для даних, що зберігаються на диску. Таким чином, бази даних використовуються для зберігання даних протягом "тривалого" часу (кілька місяців). Кожна база даних SQL (наприклад, PostgreSQL, MySQL, Oracle, ....) управляє даними на дисках (або SSD, тобто обладнання, яке може зберігати дані при належному відключенні живлення). Однак більшість програм Prolog, про які я знаю, працюють у пам'яті, і їх не можна використовувати для надійного зберігання даних (дані, збережені після відключення живлення, принаймні запрограмовані). І реалізація SQL може працювати з терабайтами даних ....

Звичайно, СУБД не записує відразу на диск (але пізніше). Але інтерпретатори Prolog, про які я чув, ніколи не писали (неявно) своїх фактів і баз правил, щоб зберігати їх на диску.

(Деякі мовні реалізації мають здатність до стійкості, наприклад SBCL з save-lisp-and-die... але я не знаю, що жоден Prolog це робить)

Практично кажучи, SQL призначений для баз даних - на дисках, але Prolog - це мова програмування (для вихідного коду в текстових файлах).


1
Я не думаю, що жодна база даних SQL не працює строго з дисковим введенням / виведенням, оскільки це було б дуже неефективно (постійно є деякі дані в пам'яті), і немає технічної перешкоди для серіалізації обмежень прологу на диску, який я можна подумати на даний момент.
ідобі

3
Теоретично кажучи, SQL є мовою запитів і не переймається тим, як зберігаються дані, доки дані описуються реляційною моделлю. SQL - це просто інтерфейс, а не парадигма. Існують бази даних, що використовують SQL, які працюють повністю або частково в непостійній пам'яті. Можливо, навіть база даних, що використовують SQL, може зберігати дані у формі фактів Prolog! [потрібна цитата] Зрештою, факти просто описують відносини. І навпаки, можливо, Prolog-двигун зможе зберігати факти на зразок бази даних на диску, а не завантажувати все в пам'ять.
амон

1
Теоретично так, але практично SQL зберігається на диску, і це часто важливо
Базиль Старинкевич

1
@BasileStarynkevitch Правила та факти записуються у вихідний код, який зберігається на диску. Чому б ви зберігали їх у базі даних? Що ви розумієте, що Prolog не може зберегти дані? Це робити не передбачається. Ось чому бази даних існують. Не могли б ви докладніше розробити детальніше.
53777A

1
Саме SQL призначений для баз даних, а Prolog - мова програмування. Це моя думка.
Базиль Старинкевич

1

Один з аспектів, що не згадувався до цього часу, - це поштовх до "відкритих" систем у 1980-х та 1990-х роках. У багатьох місцях постачальникам програмного забезпечення доведеться надавати стандартний доступ до даних у своїх базах даних. У той час SQL був усталеним стандартом, який добре знали і розуміли; Пролог був досить езотеричним та академічним. Після того, як ви почали отримувати інтерфейси на зразок ODBC для легкого підключення систем, ніхто не цікавився переглядом інших технологій.

Я працював у місці в кінці 80-х, де була досить успішна база даних ISAM, яку змусили ринковий тиск / правила закупівель додати інтерфейс SQL.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.