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

12

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

53777A
источник
8
Возможно, вы захотите набрать громкость.
4
Большая часть текста звучит как скандал против людей, которые не используют Пролог. В нем есть вопрос, который стоит задать, но другой материал (напыщенная речь) привлекает отрицательные голоса и отвлекает людей, которые могут дать ответ. Другими словами, я предлагаю вам попытаться сформулировать свой вопрос более благотворительно.
6
«Например, оценка приложения займа может быть всего лишь несколькими строками кода в Прологе». Я не покупаю это по той же причине, что любое приложение, достойное его внимания, будет использовать тонны пользовательских или сгенерированных запросов SQL.
Эйфорическая
7
Может быть, я что-то упускаю, но я думаю, что ответ здесь «люди используют SQL, потому что это то, что поддерживают базы данных» .
GrandmasterB
3
Они делают использование Пролог ... ну ... на самом деле ... они делают использование Правило Engines , которые являются «специальным, неформально-указано, ошибка охваченного, медленной реализация половины Пролога» .
Йорг Миттаг

Ответы:

19

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

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

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

Euphoric
источник
2
«Обычно требуется, чтобы какая-то компания рекламировала технологию, созданную в академических кругах, для ее распространения среди обычных разработчиков». Верно. В академии разработано много хороших идей, которые впоследствии стали популярными в компаниях, которые имеют для этого маркетинговые возможности. +1
Джорджио
6

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

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

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

Обновить:

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

Джеймс Снелл
источник
14
Это правда, что в SQL использовался ультра-многословный и «естественный» синтаксис класса COBOL, который делает его «легким» для чтения. Но я сильно сомневаюсь, что тот, кто не знает SQL, сможет правильно понять средне-сложное утверждение с несколькими joins count(*)или чем-то подобным. Если мы понимаем основы SQL, это потому, что нам иногда приходится использовать этот язык и, следовательно, пришлось изучать эти основы. Хранение реляционных данных является гораздо более распространенной потребностью, чем решение логических систем, поэтому нет необходимости в сравнительно сильной необходимости изучения Пролога.
Амон
3
@amon Это звучит как начало хорошего ответа :-)
svick
1
Барьер для изучения SQL может быть снижен из-за читабельности, пролог может отбиваться от людей из-за синтаксиса, я полностью согласен с этим. Но, действительно, без знания 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, ....) управляет данными на дисках (или твердотельных накопителях, то есть оборудовании, которое может хранить данные при правильном отключении питания). Однако большинство реализаций Prolog, о которых я знаю, работают в памяти и не могут использоваться для надежного хранения данных (данные сохраняются после сбоя питания, по крайней мере, запрограммированного). И реализации SQL могут иметь дело с терабайтами данных ....

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

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

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

Василий Старынкевич
источник
1
Я так не думаю, поскольку никакая база данных SQL не работает строго с дисковым вводом-выводом, поскольку это было бы очень неэффективно (в памяти всегда есть некоторые данные), и нет никаких технических препятствий для сериализации ограничений пролога на диск, которые я могу думать в данный момент.
idoby
3
Теоретически, SQL является языком запросов и не заботится о том, как хранятся данные, если данные описываются реляционной моделью. SQL это просто интерфейс, а не парадигма. Существуют базы данных, использующие SQL, которые работают полностью или частично в непостоянной памяти. Для базы данных, использующей SQL, можно даже хранить данные в виде фактов Пролога! [цитата нужна] В конце концов, факты просто описывают отношения. И наоборот, для движка Prolog было бы возможно хранить факты в виде базы данных на диске, а не загружать все в память.
Амон
1
Теоретически да, но практически SQL хранится на диске, и это часто необходимо
Василий Старынкевич
1
@BasileStarynkevitch Правила и факты написаны на исходном коде, который сохраняется на диске. Почему бы вместо этого хранить их в базе данных? Что вы подразумеваете под Прологом не может хранить данные? Это не должно делать это. Вот почему базы данных существуют. Не могли бы вы рассказать подробнее.
53777A
1
Точно, SQL для баз данных, а Prolog - это язык программирования. Это моя точка зрения.
Василий Старынкевич
1

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

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

Дейв
источник