Обновить
Комментарии 86
Для этого нужна ассоциативная память на аппаратном уровне, почти такая-же как у нас в мозгах.
Вряд ли все дело в этом. Поведение «почти как как в мозгах» уже частично реализуется на обычных. Со временем наверно придумают и что-то другое, в том числе и ассоциативную память.
Уже давно придумали, только в кремнии реализовать не получается. Обычное адресное пространство на кремнии — линейное. А ассоциативная память живёт в многомерном адресном пространстве. Да для неё даже математику и логику ещё не изобрели в полной мере, так — общие концепты на базовых операциях сложения и вычитания.
И да, основной прикол, нуля как математической единицы для такой памяти не существует.
Только хотел написать, что мы — аппаратное обеспечение для такого языка.
Ох уж эта молодость! Дискету как, часто в дисковод вставляешь? По-прежнему читается? Ну орёл!

Знакомые удивляются, как это — заголовок «Проблема логических языков программирования», и не строки кода? Не считывают они, что весь текст статьи — код на эзотерическом языке 'Эпилог', языке кинетическом, кларнетическом, протяжном.

И память для этого нужна на самом памятном уровне, иные уровни здесь не вытянут.

p.s. для дочитавших досюда — закрывающий тэг \сарказм.

Ха, я бы не сказал, что эти языки — эпилог.
Я буквально недавно использовал сви-пролог для написания поиска словоформ. Перед этим пытался сделать то же на стримах Java с не очень впечатляющими результатами. Да ещё и намучился. Всё-таки работать с большим количеством вариантов и их комбинаций на логическом языке проще.


Кстати после оптимизаций пролог-версия стала работать быстрее императивной. Это во вполне себе современном swi-prolog. А ведь есть ещё новый многообещающий Mercury, который по некоторым утверждениям вообще летать будет.


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

>Что касается именно задач ИИ, то конечно логическое программирование относится к отыгравшему поколению, не оправдав заявленных ожиданий.
Строго говоря, то что называется сегодня ИИ (как правило это ML) основано по большей части на идеях, которые нам еще преподавали на третьем курсе (а это было ой как давно). Ну т.е. новые идеи, плюс более мощные железки — и оно таки выстрелило через много лет после изобретения.

Я бы не исключал такого, что идеи пролога можно объединить с тем же ML, и получить некое новое качество. Просто еще никто не придумал, как.
Я бы не исключал такого, что идеи пролога можно объединить с тем же ML, и получить некое новое качество. Просто еще никто не придумал, как.
+1
> а это было ой как давно

Представьте себе, это было ещё раньше (70-е годы).
А какие вам идеи рассказывали на третьем курсе? Градиентный спуск?
Ну да, например и это. У нас был отдельный курс на эту тему. Это никто не называл машинным обучением — курс кажется звали Теория оптимизации.
Ну, видимо, потому что машинное обучение не является просто градиентным спуском, а лишь одним из многочисленных прикладных областей, которые ГС используют?
Ну так я и не говорю, что машинное обучение родилось в 70-х. Но многие идеи достаточно старые — просто реализовать их на новом уровне получилось недавно (и новые идеи конечно же тоже в наличии).
Градиентный спуск и другие методы оптимизации — лишь один из кирпичиков в фундаменте, и, вообще, для машинного обучения практически чёрный ящик (оно эти методы не исследует, а просто использует). Вас ведь не смущает, что современные писатели пишут примерно тем же алфавитом (с косметическими изменениями) те же слова (с косметическими изменениями), которые писал ещё Пушкин? Означает ли это, что они лишь реализуют на новом уровне идеи Пушкина и ничего принципиального за 200 лет не произошло?
Я ровно на этот вопрос только что отвечал :)

>новые идеи конечно же тоже в наличии
И тут совершенно не имелось в виду, что все основано на старых идеях, а новые — просто бантики.
Есть мнение Борхеса, что вся литература состоит всего из четырех архетипических сюжетов.

Так что сравнение не очень удачное. Наука все-таки периодически радует реально новыми открытиями.
Мне кажется, что Пролог и его различные диалекты, просто появились во времена, еще до начала поголовного увлечения нейросетями. В противном случае, в нем бы обязательно имелись инструменты по их обучению и/или использованию.

Возможно, проблему комбинаторного взрыва решат квантовые вычисления, тем более что они по природе своей скорее декларативные. Но тут я профан, это чисто интуитивное ощущение.

Что вы именно подразумеваете под декларативными? Просто я практически всегда скептичен по отношению к рядом стоящим словам "квантовые" и "вычисления"

К декларативному стилю написания программ следует относить и язык структурированных запросов (SQL)
основное применения языков программирования в декларативном стиле — отказаться от необходимости описания четкого алгоритма поиска решения, отдав это компьютеру на откуп. Для которого самое простое решение «в лоб» — полный перебор возможных вариантов.
Именно в этом случае и начинается экспоненциальный рост времени выполнения алгоритма.

вы рассказываете о какой-то теории большого «Комбинаторного взрыва» вообще не понимая что это такое, и что к декларативному программированию это совсем не имеет отношения.
в противном случае никто бы не использовал SQL (некоторые задачи решаемые в рамках его предметной области могут привести к «взрыву» комбинаций которые необходимо обработать, но это совсем другой вопрос).

Программирование в ограничениях наиболее адекватный общий знаменатель ваших рассуждений с применением понятий «логическое программирование», «комбинаторный взрыв» и «декларативное программирование».
Программирование в ограничениях — это один из вариантов логического программирования, которое относится к декларативной парадигме.

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

Но вы же понимаете, что индексы — лишь особенность реализации, которая к самому SQL и реляционной алгебре отношения не имеет?
Плюс «одна строка» тоже очень сомниельное утверждение, суть же не в длине строкового представления запроса, а в связях внутри него.

Конечно, индексы это детали реализации. Ровно такие детали и скрыты для программиста, в то время, когда он пишет запросы к данным.

Именно поэтому такой стиль написания и называется декларативным. Так как оставляет на усмотрение компьютера детали его выполнения.

Что же касается оптимизации, то тут ничего сомнительного. Что будет легче, оптимизировать одну единственную строку или уже множество строк, между которыми могут быть различные связи, в том числе рекурсивные?

Лол, вы до моего комментария не знали о существовании программирования в ограничениях, иначе бы хоть как-то упомянули его в своей статье, а теперь мне же цитируете вики по данной теме)

Термин парадигма как раз является абстракцией самого высокого уровня в категоризации языков программирования, и отнести к нему можно очень много всякого.
Но когда вы отождествляете создание механизма решения задач и сопутствующую проблему комбинаторного взрыва с парадигмой программирования — это крайне глупо.

За языком SQL как раз стоит отличная реализация механизма решения задач, но как и всякий механизм его можно сломать — т.е. не понимая базовых принципов работы таки сделать ему комбинаторный взрыв (перемножить две таблицы по миллиарду строк, ну это диверсия а не проблема языка). Вот как раз ваш же пример основывается на том как сломать механизм своим невежеством
Но если запрос оптимизировать не получается (например, нет индекса по нужным полям),
когда это за наличие необходимых индексов стал отвечать SQL?! При этом адекватный запрос и без индексирования успешно выполнится, это как раз уже вопрос оптимизации, при чем формальной и без тупого перебора вариантов.
Раз вы лучше меня знаете про программирование в ограничениях, то может быть приведете какой нибудь пример по затронутой теме?
Вам примеров из википедии мало?
Так это вам примеры из вики не нравятся.
Лол, вы до моего комментария не знали о существовании программирования в ограничениях, иначе бы хоть как-то упомянули его в своей статье, а теперь мне же цитируете вики по данной теме)

Не видел от вас никаких примеров по теме «программирования в ограничениях».
Если что, то предметная область SQL к данному классу проблем не относится)
С вики все норм, просто даже после того, как вы прочитали что это такое, не поняв сути, строите на его же основании контраргументы вполне разумному замечанию:
Программирование в ограничениях — наиболее адекватный общий знаменатель ваших рассуждений с применением понятий «логическое программирование», «комбинаторный взрыв» и «декларативное программирование».
Так я и не приводил примеры по теме «программирования в ограничениях».

Изначально, вы меня обвили в том, что проблема «Комбинаторного взрыва» вообще не имеет отношения к декларативному программированию и ссылаетесь на концепцию «Программирование в ограничениях».
Но согласно вики, эта концепция как раз и является подмножеством декларативного программирования.

Если честно, что я вообще потерял предмет обсуждения.
вы меня обвили в том, что проблема «Комбинаторного взрыва» вообще не имеет отношения к декларативному программированию и ссылаетесь на концепцию «Программирование в ограничениях»
на самом деле это ваша трактовка данного
Но когда вы отождествляете создание механизма решения задач и сопутствующую проблему комбинаторного взрыва с парадигмой программирования — это крайне глупо.
Не стоит смешивать в одно парадигмы программирования, классы задач, специфические проблемы, если уже давно есть конкретные направления работающие на стыке всего вышеперечисленного (подсказка: это «Программирование в ограничениях). Хотя это лишь моя попытка увязать изложенное вами в данной статье, и похоже вы и сами четко не знаете о чем это все, т.к. нет описания конкретных задач, четкого теоретического обоснования.
Мне кажется, тут нужно понять, откуда брался избыточный оптимизм и интерес к подобным системам в прошлом, и как ко всему этому надо относиться сейчас. В «те времена» у каждого языка была какая-то «фишка», чётко позиционировавшая язык в определённой нише. Для обучения, для системного программирования, для бухгалтерии, для математики и т.п.

Сейчас, конечно, тоже можно сказать, что C годится для микроконтроллеров, а JavaScript… ах, ну да, привет, Node.js и Electron. Сейчас (несмотря на всё ещё имеющееся разделение) хорошие идеи кочуют из языка в язык, и разница по большому счёту становится всё более косметически-стилистической, а умение стыковаться с модулями на других языках так просто обязательно для любого вменяемого средства разработки.

Так вот, банальное умение работать с фиксированной точкой в Коболе или хорошая математическая библиотека Фортрана уже могли быть достаточными причинами для выбора конкретного языка. Это сейчас можно рассуждать в стиле «да чё, не найду я на гитхабе хорошей библиотеки для численного решения уравнений?» Соответственно, встроенный «решатель» constraint satisfaction problem уже мог считаться мощной встроенной фичей, особенно в свете тогдашних планов реализовать это всё в быстром железе.

Да, часто встречающееся в источниках утверждение типа «мы просто опишем, что хотим получить, а компьютер сам найдёт способ найти ответ» — это чистое враньё, и думать о том, как именно компьютер в данном случае действует, всё-таки приходится. Впрочем, в известной книге Братко куда более честно сказано, что «многие придерживаются мнения, что лучше иметь хоть какую-то декларативную семантику, чем никакой». Ну, допустим.

Так вот, мне кажется, в наше время мало смысла рассматривать Пролог именно как «Язык Пролог». Он весь построен вокруг некоей единственной «фишки», которая сейчас может считаться уже библиотечной функциональностью. Имеет ли смысл constraint satisfaction problem solver? Да конечно, имеет! Но нужно ли всю программу писать в таком стиле — вот тут уже большой вопрос. Мне кажется, что если я увижу, что где-то возникла именно такого рода задача, я скорее подключу дополнительный модуль «решателя» в свою программу на C++/Python/whatever, нежели решу всё от начала до конца писать на Прологе.
Как вы считает, а реально ли создать язык логического программирования, который бы сам умел автоматизировать поиск решений для задач подобных классов?


Казалось бы и при чем тут язык программирования. Вы ищете механизм решения задач, а не механизм их описания. Для описания хватит и самого пролога и кучи других подобных решений. А вот с механизмами решения пока проблемы, но это совсем никак не относится к языку…
Язык программирования задает высокоуровневые абстракции, которыми и оперирует программист. И в конечном итоге все равно все скатывается к низкоуровневому машинному коду, но программировать на нем сейчас уже никто не пытается.

Так и с поиском решений. Недостаточно сделать классную реализацию, еще требуется удобный интерфейс для взаимодействия с ней, которым как раз и может являться язык программирования.
Странный ход мыслей, делать интерфейс к реализации которой еще нет)
Один из вариантов реализации поиска решения — полный перебор вариантов.
Еще один, уже поддерживающий оптимизацию — SQL.
Любой диалект Пролога, тоже пойдет как вариант реализации механизма поиска решений.

Как видите, вариантов реализации уже сейчас много, и еще больше можно придумать, особенно их различных комбинаций. Вот только все они завязаны либо на свою предметную область, либо привязаны к конкретному языку программирования (среде выполнения).
Очень похоже что ваш абстрактный «механизм поиска решений» это разновидность кнопки «сделать все хорошо», без какой либо конкретики, только акцентируя на проблеме полного перебора.
Вот только все они завязаны либо на свою предметную область, либо привязаны к конкретному языку программирования
что SQL что Пролог как раз языки под конкретную предметную область — то есть предметно ориентированный язык (DSL), никакого «либо» здесь не может быть.
Более того «механизма поиска решений» который реализован в некой среде выполнения (сервер SQL или алгоритмы Пролога) сам по себе не решит на обум вашу задачу, для этого, вам необходимо еще и дать очень детальное и непротиворечивое описание конкретно вашего частного случая.
Для пролога это внесение набора предикатов, для sql это описание структуры таблиц и их связей, а универсальный «решатель» это уже из области фантастики, без знаний о предмете, ни один алгоритм не может быть полезен.
… сам по себе не решит на обум вашу задачу, для этого, вам необходимо еще и дать очень детальное и непротиворечивое описание конкретно вашего частного случая.
Так я с этого и начал пару комментариев выше.

И у меня нет «механизма поиска решений». Я просто отметил определенную проблему, что в тех предметно ориентированных языках, где «механизм поиска решений» реализован, при определенных условиях могут возникать сложности с поиском решений.
в тех предметно ориентированных языках, где «механизм поиска решений» реализован, при определенных условиях могут возникать сложности с поиском решений
аналогичное по сути утверждение в отношении математики возможно покажет бессмысленность такой постановки вопроса.
— в целом математика очень хорошо помогает решать большинство задач, но некоторые проблемы все еще остаются нерешенными.
Нужны новые IDE, новые синтаксические сахары…
я вот недавно попробовал джавскрипт на IntelliJ Idea — она кроме всего прочего умеет понимать, какая у полученного JSON-а будет структура (несмотря на то что он высылается в другом файле) и подсказывает об очевидных опечатках. Для интерпретируемого языка это просто чудо-сказка а не IDE!

Теперь бы еще такое же, только для аудио — чтобы например диффы от коммитов коллег можно было воспринимать на слух, и это бы позволило проводить пробежки гораздо болеее продуктивно :)
Сперва я хотел согласиться с подобным предположением (насчет включения подобного функционала в другие языки в виде отдельного модуля). Действительно, можно включить в состав приложения библиотеку, реализующую реляционную базу данных и это вполне нормально будет работать.

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

Вторым, и на мой взгляд более серьезным препятствием, может быть принципивльно разный подход программирования при использования императивного и декларативного стиля. Ведь вряд ли в коде программы на Прологе сможет сходу разобраться С++ или Python программист.
Вы изобретаете велосипед, которым математики занимались еще в 19 веке. Если память мне не изменяет, Гильберт пытался придумать некий универсальный алгоритм-генератор для создания математических утверждений с последующим их доказательством. Затем Курт Гедель своей теоремой о неполноте доказал невозможность подобного.
Изобретение новых способов изобретения велосипеда. Это какая-то рекурсия получается :-)
Чем больше я пытаюсь понять отличия «декларативного» и «императивного» стиля (и, в целом, концепцию такого деления), тем меньше принципиальных отличий я в них наблюдаю. При появлении даже простых абстракций в коде, при желании, его можно отнести к «декларативному» стилю. Вызывая код через верхний уровень абстракции мы неизбежно отдаём выбор реализации нижним. Сам же «декларативный» стиль (хотя, я бы использовал слово «подход») не может быть использован без обвязки из «императивного», собственно, и реализующего выбор алгоритма решения. Отсюда, в мало-мальски сложном приложении использованы по отдельности они быть не смогут. Они суть единое целое. В большинстве случаев даже четкой границы не провести: каждый метод или оператор, в сущности, говорит что сделать, а не как (как — сокрыто в его реализации), не говоря уж о более сложных конструкциях. Таким образом, дальнейшие рассуждения, на мой субъективный взгляд, смотрятся как поиск серебряной пули там, где для её наличия нет даже предпосылок.
Одной из проблем Пролога отмечают как раз отсутствие возможности писать программы в императивном стиле.
Поэтому, я с вами соглашусь, что использовать только декларативный не очень удобно и гораздо лучше иметь возможность комбинировать стили написания в рамках одной программы.
Как раз в случае с Прологом возможно использовать декларативный стиль совершенно без императивного. Это можно продемонстрировать очень просто — декларация равенства на Прологе выглядит просто как факт: равно(X,X). И тут нет ничего императивного, тем не менее это действительно программа и ее действительно можно использовать для решения задач…
И так вот на Прологе часто. Например, решение известной задачи Эйнштейна о размещениях в домиках людей решением назвать очень трудно — это просто прямое переписывание фактов из постановки задачи и затем постановка самого вопроса — и всё, Пролог-система сама сгенерирует все ответы…
И, тем не менее, «Пролог-система» должна быть кем-то императивно написана. С таким подходом разработчик со всем обилием инструментов вырождается в администратора, в лучшем случае. Искусственно можно выделить часть кода, которую, с натяжкой, можно назвать декларативной, но ценность такого результата — максимум, академическая. Ещё один вывод, если принять на веру Вашу интерпретацию — SQL, упомянутый в статье как декларативный, к оному подходу абсолютно никакого отношения не имеет. Даже ANSI, чего уж говорить о его расширениях. Про пролог ничего сказать не могу, даже в глаза не видел) Возможно, когда-нибудь из принципа возьмусь вникать. Из опыта изучения языков/сред могу сказать, что чем меньше подконтрольного разработчику, тем скромнее область применения. Суть разработчика — построение алгоритмов. Отнять второе — исчезнет первое.

Я не знаю, в курсе вы или нет, но именно тенденция вырождения в администрирование прослеживается сейчас везде. Всё потому что все программы уже написаны в десятках вариаций. Теперь задача состоит в эффективной их компоновке.

Это вы, наверно, просто далековато от передовой — у нас тут всегда ситуация, когда ничего не написано…
Смотря о какой передовой идёт речь. Вы на каком фронте?
тенденция вырождения в администрирование прослеживается сейчас везде

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

Насчет SQL совершенно верно — он не декларативный получается. Насчет Пролога — можно, например, то что вы выше написали, как есть (дополнить описанием операторов) считать пролог-программой (ничего не меняя) — каждое предложение с точкой будет высказыванием — загрузить ее в пролог-машину и строить к ней вопросы или выводить следствия: такова мощь Пролога!

В Прологе всё подконтрольно разработчику, кроме собственно вычисления — тут используется принцип резолюций и более мощного аппарата у человечества пока нет.

А для алгоритмов Пролог практически идеален — то есть если вам удается написать алгоритм, то получится именно его декларативное определение.
И еще, мне кажется, вы несколько неверно определяете для себя декларативный стиль — в нем вообще-то нет никаких что делать, ни как. В нем именно декларируется нечто. И отсюда у вас в рассуждениях появляются абстракции, вызывая код, реализации…

Это всё не про то. Это про декларативный стиль для императивных языков. Но именно Пролог в чистом виде реализует эталон декларативного стиля и может обходится без императивного — но это, конечно, редко получается :)
В большинстве случаев даже четкой границы не провести: каждый метод или оператор, в сущности, говорит что сделать, а не как (как — сокрыто в его реализации), не говоря уж о более сложных конструкциях.
Сокрытие деталей реализации в методе или операторе — это способ повышения абстрактности (но никак не декларативности), на уровне языка (оператор) или на уровне конкретного проекта (метод), иерархически повышать его можно сколько угодно.
Декларативность кода состоит в том, что он "не используют понятия состояния, в частности, не содержат переменных и операторов присваивания", «на повышение уровня декларативности нацелено языково-ориентированное программирование.»
Честно говоря, я не согласен с утверждением, что «Как следствие, декларативные программы не используют понятия состояния, в частности, не содержат переменных и операторов присваивания, обеспечивается ссылочная прозрачность.»

Отсутствие переменных, это один из способов реализации конкретной проблемы и не более того. Но сама проблема (отказ от состояния и обеспечение ссылочной прозрачности), не является частью или обязательной составляющей парадигмы декларативного программирования.
Не согласны так несогласны, ваше право)
Но
Дайте тогда хоть собственное определение, обязательно поучаствую в его обсуждении.
Меня и текущее определение вполне устраивает «Декларати́вное программи́рование — парадигма программирования, в которой задаётся спецификация решения задачи, то есть описывается, что представляет собой проблема и ожидаемый результат.»

Я не согласен с необоснованным ограничением для основного определения.
Например, спецификация решения задачи, как «результат выполнения функции равен значению, хранящемуся в переменной», будет вполне в декларативном стиле.

И причем тут запрет на использование переменных? Ведь это только один из способов реализации чистоты функций, причем не единственный.
Перебор очень полезен даже если разработчик знает алгоритм решения.

Есть ветвь по сути всё того же логического програмиирования под названием model checkers. Ветвь очень востребована в узких областях. В более широком смысле это направление развивается в виде theorem provers (автоматического доказательства теорем).

Там перебор упрощает работу разработчика. Если я знаю, что в алгоритме нужно сделать сотню шагов, то все их написать и отладить — долго. Поэтому я беру модель и кручу её на сольвере. Экономия времени — это то, ради чего и развивается программирование.
я бы даже сказал — экономия человеческого времени

Проблема только в том, что солверы очень ограничены. Базовая линейная арифметика, базовые операции над множествами, все такое — это да, это работает. Для хоть немного сложных вещей приходится направлять автоматизацию по малюсеньким шагам.

Мне кажется, что автор не упомянул несколько интересных способов использования Пролога в современности.

Во-первых, я считаю, если вы смогли написать решение задачи на Прологе, то вы очень глубоко поняли это решение. Я прямо так и делаю, особенно если задача очень сложна — вначале выражаю задачу на Прологе, затем пишу решение. Да, это может обернуться низкой эффективностью решения, но зато это сильно экономит время (иногда — бесконечно :) до момента, когда я сам начинаю понимать задачу.

Во-вторых, Прологу нет равных в скорости начала работы с проблемой на проблемно-ориентированном языке. Тут с ним могут конкурировать только предметно-ориентированные системы, как Вольфрам или маткад… Я тут, помниться, даже статью написал как сделать web-сервер с микросервисами на Прологе.
Я писал не про сам Пролог, а назвал его только как самый распространенный пример и прародитель языков логического программирования.
На нем действительно можно писать программы в интересном стиле, но уж очень они заумно выглядят. Но если ты в этом сумел разобраться, то действительно — становится море по колено!
Да, это понятно… Вот только я не знаю никаких других языков логического программирования (даже Парлог и то всё тот же Пролог). А вы знаете?
Мне не известные реально работающие завершенные языки логического программирования.

Пролога несколько разновидностей.
Mercury, Oz?

Нет, я имел в виду не-Пролог, что-то еще… Хотя, как мне кажется, реализация принципа резолюций всё равно только одна.
я честно посмотрел оба языка — они не логические! Отсутствует унификация, логические переменные (есть типы) — в общем, не то, совсем не то…
Приведу пример процедуры поиска в ширину с формированием путей поиска — это потрясающая программа на Прологе:
% поиск в ширину с длиной цепи
искать(Цель, [p(L, [Цель|Путь])|_]-_, [Цель|Путь], L).
искать(Цель, [p(Q, [В|Путь])|Пути]-Z, Решение, L) :-
    bagof(p(LL, [B1, В|Путь]),
          (e(В, B1, W), \+member(B1, [В|Путь]), LL is W+Q),
          Новый),
    append(Новый, ZZ, Z),
    искать(Цель, Пути-ZZ, Решение, L).
искать(Цель, [_|Пути]-Z, Решение, L) :-
    Пути\==Z,
    искать(Цель, Пути-Z, Решение, L).

Она применяет разностные списки…
Но любой С++ разработчик сломает голову, если захочет понять, как она работает :-)
думаю, вы правы — я сам чуть её не сломал… но она всё же работает. Всё дело в append — это означает, что предикат append строит такое дополнение, которое должно привести к результату, который будет вычислен до самого предиката… В общем это звучит как «чтобы понять рекурсию, надо понять рекурсию»
Очевидная проблема состоит в том, что логика высказываний далеко не для всего подходит. Ну то есть как бы да, «вы поняли задачу, если описали её на Прологе», но это описание может быть громоздким или вывернутым наизнанку в сравнении с тем, который я бы назвал «пониманием», а всё из-за неадекватности выразительных средств.

Простой пример — математика, которая к Прологу прикручена к логике чуть ли не на изоленте. Менее очевидный — скажем, события, выстроенные в определённом порядке во времени (и поэтому в специализированных системах типа SPIN используется темпоральная логика, а не просто first-order logic).

Достаточно продвинутая технология неотличима от магии. Вы начали с рассуждения о логических языках, но потом обобщили местные проблемы до всего декларативного программирования. Хотя на практике это не так. К декларативным относят и другие языки, абстрагирующие от потока управления. Например регекспы, языки описания конфигураций, грамматики или там функциональные языки. Все это неплохо прижилось, настолько, что мы даже перестали обращать на них особое внимание. Даже в императивных языках, подязыки, которые используются для описания типов вполне декларативны.

Хочу подкинуть еще одну тему в это обсуждение. Мне кажется, что самое быстрое и уже нужное применение логических языков (и в целом их развитие) — это BDD.


Каждый раз, когда пишутся сценарии для конкретного проекта — фактически создается свой собственный имеретивный язык.


И вообще, бизнесу всегда будет проще выражать свои мысли на чем-то, что декларирует факты, а не описывает как этого добится.

Да, я хотел добавить про DSL, но мне показалось это уведет разговор в сторону.


Но раз он уже ушел.


ИМХО за DSL будущее. Хороший архитектор и программист даже в небольшом проекте начнет потихоньку двигатся в торону DSL используя основной язык как базу. Тот же DDD сильно способствует. Кончно в мейнстриме не хватает сахара для такого подхода. Например, написать user login with creds, что прозрачно (первую очерель для ИДЕ) становится user.login(creds).


Другое направление — это конечно конфигурации, декораторы и в целом AOP. Когда мы можем свободно в любом месте файла контроллера дописывать where routing is "/foo/bar" and using security. Вместо декораторов (или аннотаций или у кого как они называются), которые имеют очень строгие правила где их писать и как. Потому что, тот же роутинг может быть задан в разных конфигах, декораторах или даже просто где-то в коде-плагинах.


Задача собрать конфиг одной сущности (в примере — роутинг) в одну под-программу. Которая покажет и полное состояние, и дебаг и логику какая настройка какой перетерта очень близка логическим языкам. Как математически (необходимый мат. аппарат, чтобы собрать набор утверждений и высчитать результат), так и лингвичтически (наиболее удобная форма записи для чтения программитом).


Да, это простая задача для целого языка. Но основное что я хочу сказать — что результат выхода в мейнстрим все добиваются маленькими шажками. Именно такими шажками языки (тем более парадигмы) набирают популярность и вес.


Вообще же, нам давно пора научится писать несколькими языками одновременно. Напимер, в одном файле будет и ООП для структурного управления (этот клас описывает такую сущность и имеет такой функцонал), функциональщина для управления данными внутри методов и SQL для коннекта к 3rd party или математика для финального описания, где компилятор не может сам понять что делать.


И этот процесс уже идет. С самого начала (окей, с 80х) математика нативно интегрирована в языки. Сейчас весь мейстрим ООП'шный. Функциональщина практически везде реализована. AOP уверенно завоевывает языки. Сейчас внедряют SQL. Паровозом тут выступает .Net с их реализацией LINQ.


ИМХО дальше именно лоигческое программирование. Мы неявно уже давно его внедряем. Мы стараемся, чтобы в коде было максимально мест где компилятор\библиотека сами посчитают как лучше делать. Конфиги на первом месте по частоте применения. Все "умные" DI и толстые ORM. Из более екзотического — некоторые умеют выполнять шелл код, не уверен что это нужно, но пример в десятку. Сейчас идет (массовое внедрение) парарельность и разработчики стараются как можно больше управления потоками отдавать системе. Как я сказал выше — маленькие шажки.


Но для массосого программиста — нужно чтобы был сиснтаксис. Отличительный синтаксис, по которому они видят, что задача решаетсмя по другому. Что им надо думатьпо другому. И на маленьких проблемках тренироваться.


А без массового программиста революцию, к сожалению, не совершить.


PS какой бы не была эффективной система логического программирования — без хорошего дебага она не взлетит. Девелоперу надо видеть почему получен такой результат, который получен. Как минимальным измением его исправить. Та же проблема с ML сейчас встает все острее и острее. Но в логическом программировании дебаг хотя бы возможен.

Подходов может быть множество, и я ничуть не возражаю против описанного вами, хотя некоторые места мне и кажутся сомнительными (например, создание собственного языка под свою собственную задачу).
Ведь если спрогнозировать его развитие, то в конечном итоге каждая библиотека или заимствованный модуль будут иметь свой собственный язык.
И эта проблема возникает на пустом месте, просто потому, что у хорошего архитектора с разработчиком появилось мысль, сделать пользователям хорошо, уменьшив порог вхождения и реализовать собственное подмножество языка :-)

тут 2 мысли.


Первая. ДСЛ везде нужен не для того, чтобы можно было везде на него смотреть. А чтобы был можный стек инструментов, как у явы или дотнета. Чтобы зайдя на новый проект, не надо было месяц учить очередной не нужный язык. А, например, его можно в реальном времени интерпртировать в стандартный язык. Получить понятную, но длинную форму того-же кода. Быстро разобраться и начать нативно писать и читать проектный язык.


Вторая. Все проблемы ДСЛ уже существуют в любом, достаточно большом проекте. А достоинства бывают очень редко. Любой проект имеет свои правила (негласные и гласные) как писать код. Чем больше и старее проект — тем больше и строже правила. При этом тулы, которая эти правила проверяет автоматически пишут очень редко. Тем самым, правила надо учить через разговоры на код ревью.


ДСЛ, не добавляет проблем. Однако он сразу решает первую проблему — правила проверяются автоматически, а не в ручную. А если DSL станет мейнстримом и тулинг начнет нормально рзвиваться — мы получим редкую возможность переиспользования кода. Которая действительно работает.


А если таки будет прозрачная интерпритация, как я описал выше — мы получим новую уникальную фичу, которой раньше не было. Каждый программист сможет писать в своем собственном стиле, как лично му удобно. А проект все равно будет в командном стиле. И никому это не будет мешать.

Посмотрите комментарии к предыдущей статье habr.com/ru/post/531400.
Тестируемая идея почти в точности соответствует ДСЛ (человекопонятный язык для всех).
Но очень простой контраргумент, какой бы язык предметной области не был и пользователь его не знает, то он будет новым для него языком, который все равно нужно будет учиться применять (правила, возможные комбинации и допустимые взаимодействия, исключения из правил т.д.), и это даже в том случае, если сами термины ему знакомы. Ведь простого знания слов не достаточно для их реального применения.

А вот с любым формализованным языком гораздо проще. В них практически нет исключений из правил, и самое главное, публикуя объявление о вакансии на должность разработчика со заданным стеком технологий, можно быть уверенным, что эти знания описаются на реальную базу, а не на кастомный диалект ДСЛ языка, который он использовал в одном из предыдущих проектов.

А что касается автоматической проверки правил, в формальных ЯП можно не только правила проверять, но и использовать различные сканеры кода для выявления ошибок, потенциальных уязвимостей и пр. И пять, это сделать гораздо проще и удобнее для единого формального языка, чем городить огород для своего подмножества.

Там я уже не могу комментировать.


Но первое что бросается в глаза — DSL это НЕ человекопонятный. Человекопонятный — это подмножество. Лично мне хочется писать свои DSL поближе к нативным языкам. Но это далеко не всегда правильно.


Конрпримеры. Первый, конечно, математика. Математика это свой, другой язык. То что для большинства программистов он воспринимается как естественный — хорошо. Но это НЕ естественный язык.


Второй — это списки конфигов. Можно, конечно, писать вася юзер может иметь права админа. Но в конфигах на первое место выходит сокращение повтояющихся данных (или лаконичность). Идиальный конфиг, где вложенность определяется пробелами, а срока после трима вася админ.


За последние несколько лет любой программист уже должен понять, что "удобство" — это личное качество. Удобно всем не может быть. Всем может быть удобно — только если каждый видит один и тот-же код в своем личном стиле. И то, будут те, кому не удобен такой софт, потому что он дополнительный. И они будут хотеть, чтобы все писали в их любимом стиле и слали код через имейл.

«удобство» — это личное качество. Удобно всем не может быть. Всем может быть удобно — только если каждый видит один и тот-же код в своем личном стиле.
Подписываюсь!!!

так как:
Идиальный конфиг, где вложенность определяется пробелами…
Для меня, это самый ужасный конфиг, т.к. в нем нельзя использовать возможности автоматического форматирования :-)

Я говорю о представлении, которое я хочу видеть. Никому предлагать не собираюсь. Как оно хранится в битах или репе — для меня вторично. При условии что у меня есть тула, которая в моем екране форматирует как мне нравится и удаляет (для меня) лишнее.

EDIT


я когда добавил пример с нативным шеллом — ошибся абзацем. Это хороший пример нескольких языков в одном файле. И никак не пример уже существующего внедрения логического программирования.

DSL появляются чуть-ли не каждый день, но они редко получают развитие. Для поддержки разработчиков нужна документация, соответствующий инструментарий (IDE с подсветкой синтаксиса, форматтеры, линтеры, рефакторинги, дебагеры, кодмоды), байндинги для интеграции с мейнстрим языками. Дешево разрабатывать все это пока не научились. Ошибки в дизайне языка исправлять существенно дороже, чем поддерживать фреймворк или библиотеку.

это если DSL публичный. В рамках проекта — имхо, дешевле.


А про слабый тулигн в индустри (на сегодня) я пишу в каждом коменте к этой статье.

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