Исторический прецедент, почему Prolog менее популярен, чем SQL в императивном программировании? [закрыто]

Кажется, что написание декларативного SQL очень популярно в императивном программировании . Тем не менее, также кажется, что написание декларативного Prolog может сэкономить много сложности, но это не очень распространено.

Есть ли исторический прецедент для этого очевидного предпочтения SQL над Прологом?

Если причина заключается в отсутствии собственной поддержки императивными языками, то можно ли ответить, почему создатели языка не сочли полезным изначально поддерживать Prologих?

Чтобы привести некоторые конкретные примеры:

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

Пример 2
Вот еще один пример проблемы и решения в Прологе. Следующая логическая программа ограничения представляет собой упрощенный набор данных истории Джона как учителя:

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. А в случае данных, хранящихся в массиве, я считаю, что код Пролога будет легче писать и поддерживать.

Я считаю, что это в первую очередь историческая вещь.

SQL в основном использовался в бизнесе для создания бизнес-приложений. Некоторые компании зарабатывают себе на жизнь, продавая SQL-решения, и они используют свои деньги для рекламы и внедрения SQL-решений в сознание многих. Это было особенно важно тем, насколько важны данные для деловых людей. Вот почему SQL выиграл у многих конкурентов и так широко известен и используется даже сегодня.

Пролог по-другому был в основном известен в академической сфере, обычно в области искусственного интеллекта. Академические люди редко навязывают свои инструменты и идеи другим людям, как это делает бизнес. Обычно требуется, чтобы какая-то компания рекламировала технологию, созданную в академических кругах, для ее распространения среди обычных разработчиков. Кроме того, хотя данные чрезвычайно важны, «бизнес-правила» не таковы. Хотя они могут показаться важными, они гораздо менее важны, чем данные. Деловые правила обычно могут быть легко исправлены. Попытка исправить «испорченные» данные обычно намного сложнее. Таким образом, компании больше внимания уделяли получению своих решений для обработки данных, чем решений для бизнес-правил.

Причина на самом деле довольно проста. Это не имеет ничего общего с тем, насколько язык полезен для данной задачи, и не связано с тем, насколько поддерживается код.

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

Вы прочитали несколько строк пролога, и многие разработчики слегка косятся глазами и оставят задачу кому-то другому, и, возможно, пойдут на ложь. Синтаксис предиката пролога просто не поддается легкому чтению.

Обновить:

Основываясь на примере кода, языки, которые реализуют коллекции, должны работать хорошо. Я реализовал решение в C # / Linq, и оно не было значительно больше, чем образец пролога (как только вы учли статическую типизацию и требуемые определения). В какой-то промежуточной работе был предпринят дополнительный шаг, чтобы объединить списки и создать единый график для поиска, но это не было значительным объемом работы.

Есть еще одна причина. Практически говоря, SQL полезен для данных, сохраняемых на диске. Таким образом, базы данных используются для хранения данных в течение «длительного» времени (несколько месяцев). Каждая база данных SQL (например, PostgreSQL, MySQL, Oracle, ....) управляет данными на дисках (или твердотельных накопителях, то есть оборудовании, которое может хранить данные при правильном отключении питания). Однако большинство реализаций Prolog, о которых я знаю, работают в памяти и не могут использоваться для надежного хранения данных (данные сохраняются после сбоя питания, по крайней мере, запрограммированного). И реализации SQL могут иметь дело с терабайтами данных ....

Конечно, СУБД не записывает сразу на диск (но позже). Но интерпретаторы Пролога, о которых я слышал, никогда не пишут (неявно) свои базы фактов и правил, чтобы сохранить их на диске.

(У некоторых языковых реализаций есть возможность сохранения, например, SBCL с save-lisp-and-die... но я не знаю, как это делает Пролог).

С практической точки зрения, SQL предназначен для баз данных на дисках, но Prolog - это язык программирования (для исходного кода в текстовых файлах).

Одним из аспектов, не упомянутых до сих пор, является стремление к «открытым» системам в 1980-х и 1990-х годах. Во многих местах поставщики программного обеспечения должны были бы обеспечить доступ отраслевых стандартов к данным в своих базах данных. В то время SQL был установленным стандартом, который был хорошо известен и понят; Пролог был довольно эзотерическим и академическим. Как только вы начали получать интерфейсы, такие как ODBC, для простого подключения систем, никто не заинтересовался другими технологиями.

В конце 80-х я работал в одном месте, где была довольно успешная база данных ISAM, которая была вынуждена рыночным давлением / правилами закупок добавить интерфейс SQL.