Комментарии 23
Скажите пожалуйста, вы в курсе, что накосячили с тегами заголовков и текст нечитаем?
Слушайте, последнее слово очень зацепило. В любом случае пишите! С третьего курса мучает тройка по программированию, которое получил за пролог. В то время давно уже работал, писал на Джаве и С++, думал нахрапом переделать какую-нибудь программку чужую и сдать. Преподаватель просек, что я нифига не разобрался и поставил тройку, сказав — я надеюсь, вы рано или поздно выучите Пролог.
Вот до сих пор иногда берусь за логические языки, но всегда не хватает, чтобы серьезно начать использовать. Кроме собственной лени, вижу еще ряд причин:
1) мало информации, как правильно организовать рабочий процесс — каким редактором редактировать, как удобно проверять исполнение программы, как оформлять готовую программу в виде исполняемого пекеджа.
2) нет грамотных тьюториалов. хотелось бы найти где-нибудь цикл лекций, в котором последовательно читатель вводится в язык с азов и до самых сложных хитрых штук, последовательно работая над маленькими интересными прикладными задачами, причем именно прикладными, с получением конкретных результатов
3) как то повествование о прологе сильно оторвано от практического применения. для меня пролог всегда появляется в какие то моменты на работе, когда вот думаешь — черт, а вот тут круто было бы сделать отдельный модуль на прологе, в своем джава приложении скормить ему данные и получить вывод.
например — есть логи, есть данные мониторинга системы, есть данные из базы. и есть какие то косячные данные, причину появления которых нужно определить. в голове у саппорта есть понимание, что в каких случаях делать и как копать. но запрограммировать это на процедурных языках как-то не очень удобно, к тому же логика постоянно меняется, появляются новые факты, правила. вот очень тут просится логический язык.
хочется понимать не просто пролог, а как его использовать в уже существующих сложившихся программных комплексах — в джаве, в питоне, в bash (говорю про то, чем сам пользуюсь). ведь очевидно, что не стоит на нем писать GUI приложение, а вот экспертную систему очень даже стоит.
Вот до сих пор иногда берусь за логические языки, но всегда не хватает, чтобы серьезно начать использовать. Кроме собственной лени, вижу еще ряд причин:
1) мало информации, как правильно организовать рабочий процесс — каким редактором редактировать, как удобно проверять исполнение программы, как оформлять готовую программу в виде исполняемого пекеджа.
2) нет грамотных тьюториалов. хотелось бы найти где-нибудь цикл лекций, в котором последовательно читатель вводится в язык с азов и до самых сложных хитрых штук, последовательно работая над маленькими интересными прикладными задачами, причем именно прикладными, с получением конкретных результатов
3) как то повествование о прологе сильно оторвано от практического применения. для меня пролог всегда появляется в какие то моменты на работе, когда вот думаешь — черт, а вот тут круто было бы сделать отдельный модуль на прологе, в своем джава приложении скормить ему данные и получить вывод.
например — есть логи, есть данные мониторинга системы, есть данные из базы. и есть какие то косячные данные, причину появления которых нужно определить. в голове у саппорта есть понимание, что в каких случаях делать и как копать. но запрограммировать это на процедурных языках как-то не очень удобно, к тому же логика постоянно меняется, появляются новые факты, правила. вот очень тут просится логический язык.
хочется понимать не просто пролог, а как его использовать в уже существующих сложившихся программных комплексах — в джаве, в питоне, в bash (говорю про то, чем сам пользуюсь). ведь очевидно, что не стоит на нем писать GUI приложение, а вот экспертную систему очень даже стоит.
Хотел подчеркнуть, что в последний раз брался за Пролог несколько лет назад, сейчас поискал на хабре и нашел много хороших статей как раз о том. Прошу сильно не бить и воспринимать это как дополнительную мотивацую автору продолжать свое благое дело.
В любом случае, Пролог — это не универсальный язык, зато на нем прекрасно решаются математические/декларативные задачи, а императивные (чтение из файла, ...) выглядят ужасно. Так что мейнстрим языком скорее всего не стать + еще к тому крайне необчная работа присваиваний и переменных.
Туториалов много и в первых статьях (1 и 2), я тоже пытался описать азы. Тут как вы правильно заметили нахрапом невозьмешь! :) Это не язык D, который можно понять зная C и Java. Это даже не функциональное программирование, которое при первом рассмотрении похоже на процедурное программирование. Логическое программирование вообще ни на что не похоже, реализаций Пролога много, но большинство из них называется Прологом (за исключением Mercury и других одиночек).
К примеру в 1-й статье я пытался объяснить, как читать программы. Это достаточно просто надо только отойти от некоторых «императивных» стереотипов. Писать программы, особенно легко читаемые, достаточно сложно для этого надо уметь выражать, что задача должна решать, а не каким способом. Примеры приводил во 2-й статье: если у вас есть задача «Судоку», то в императивном программировании вы бросаетесь искать переборные алгоритмы, стратегии и т.п., в Прологе вы в первую очередь должны формализовать, что такое игра «Судоку» и если ваша формализация полна и адекватна (соответствует реальному «Судоку»), то Пролог предоставит решение за вас. Процесс формализации задачи не так прост, как кажется.
1) Пишу в блокноте, заливаю файлы через стандартный предикат :-consult(). Swi-Prolog посмотрите наиболее документированный.
2) Продолжу писать статьи и отвечать на комментарии. Именно живое общение помогает обучению, несмотря на то, что книг написано достаточно хороших (Братко — советую)
3) Очень просто интегрировать в bash, так как Пролог представляет такой же интерфейс как РСУБД — консоль. В принципе они очень похоже и тулы у них схожие. Интеграция с Java очень простая через tuProlog, да куча способов.
По поводу вашей задачи, у меня была несколько другая задача на продакшене, которая закончилась и хорошо и плохо. Дело в том, что в доменной области было много маленьких и специфичных правил, которые я смог выразить в специальном синтаксисе и выполнять через Пролог. Хорошо — то, что эксперты из доменной области с радостью меняли эти файлы (для них это было как скрипты для администраторов), а вот программисты отказывались поддерживать часть с Прологом. А программа без поддержки программиста обречена, зато доменный язык на Прологе, очень расширяем и по сути представляет полную МТ, так что дописать практически всегда можно и извне.
Туториалов много и в первых статьях (1 и 2), я тоже пытался описать азы. Тут как вы правильно заметили нахрапом невозьмешь! :) Это не язык D, который можно понять зная C и Java. Это даже не функциональное программирование, которое при первом рассмотрении похоже на процедурное программирование. Логическое программирование вообще ни на что не похоже, реализаций Пролога много, но большинство из них называется Прологом (за исключением Mercury и других одиночек).
К примеру в 1-й статье я пытался объяснить, как читать программы. Это достаточно просто надо только отойти от некоторых «императивных» стереотипов. Писать программы, особенно легко читаемые, достаточно сложно для этого надо уметь выражать, что задача должна решать, а не каким способом. Примеры приводил во 2-й статье: если у вас есть задача «Судоку», то в императивном программировании вы бросаетесь искать переборные алгоритмы, стратегии и т.п., в Прологе вы в первую очередь должны формализовать, что такое игра «Судоку» и если ваша формализация полна и адекватна (соответствует реальному «Судоку»), то Пролог предоставит решение за вас. Процесс формализации задачи не так прост, как кажется.
1) Пишу в блокноте, заливаю файлы через стандартный предикат :-consult(). Swi-Prolog посмотрите наиболее документированный.
2) Продолжу писать статьи и отвечать на комментарии. Именно живое общение помогает обучению, несмотря на то, что книг написано достаточно хороших (Братко — советую)
3) Очень просто интегрировать в bash, так как Пролог представляет такой же интерфейс как РСУБД — консоль. В принципе они очень похоже и тулы у них схожие. Интеграция с Java очень простая через tuProlog, да куча способов.
По поводу вашей задачи, у меня была несколько другая задача на продакшене, которая закончилась и хорошо и плохо. Дело в том, что в доменной области было много маленьких и специфичных правил, которые я смог выразить в специальном синтаксисе и выполнять через Пролог. Хорошо — то, что эксперты из доменной области с радостью меняли эти файлы (для них это было как скрипты для администраторов), а вот программисты отказывались поддерживать часть с Прологом. А программа без поддержки программиста обречена, зато доменный язык на Прологе, очень расширяем и по сути представляет полную МТ, так что дописать практически всегда можно и извне.
Возвращаясь снова к задаче о логах :) Насколько я понимаю, в базу попадают косячные данные, а причина этого неизвестна, но может быть восстановлена из логов и из данных. К сожалению в таком общем виде вам только человек и поможет. Приведите примеры правил и фактов, какие бы вы могли запрограммировать сейчас.
Мне кажца основная заморочка его малого распространения в платности Visual Prolog'a. Вы так не считаете?
Ещё где-то читал, что на нем программировать легко, будто на естественном языке(в чем не получилось убедиться). И он, имхо, очень сложный в отладке и вспоминании задач, которые делал давно(из-за рекурсивности конструкций).
Ещё где-то читал, что на нем программировать легко, будто на естественном языке(в чем не получилось убедиться). И он, имхо, очень сложный в отладке и вспоминании задач, которые делал давно(из-за рекурсивности конструкций).
swi prolog?
gnu prolog? (я вроде им пользовался в универе)
глянул на страничку visual prolog'а — для некоммерческого использования бесплатен.
Т.е. это не заморочка: )
gnu prolog? (я вроде им пользовался в универе)
глянул на страничку visual prolog'а — для некоммерческого использования бесплатен.
Т.е. это не заморочка: )
Отладка была сложна, пока не открыл для себя консольный предикат trace. Ставите его в то место, где что непонятное происходит и смотрите как идет раскрутка + у вас есть пара команд, чтобы оценить, как поведет себя бэктрекинг, запустить предикат на проверку и т.п.
Visual Prolog является самым странным и неклассическим из тех, что я знаю. Он позволяет писать X = 2 + 3 и получать X = 5, хотя должно быть X='+'(2,3). И сама по себе направленность Visual, крайне сомнительна для пролога, UI описывать на прологе абсолютно не стоит из-за императивности обработчиков событий. В Visual классы есть? Header? В общем все это реклама :)
Не программировать легко на Прологе, а читать — это 2 большие разницы. Существует некоторые программы, что не веришь, что они вообще программы, а не комментарии.
Visual Prolog является самым странным и неклассическим из тех, что я знаю. Он позволяет писать X = 2 + 3 и получать X = 5, хотя должно быть X='+'(2,3). И сама по себе направленность Visual, крайне сомнительна для пролога, UI описывать на прологе абсолютно не стоит из-за императивности обработчиков событий. В Visual классы есть? Header? В общем все это реклама :)
Не программировать легко на Прологе, а читать — это 2 большие разницы. Существует некоторые программы, что не веришь, что они вообще программы, а не комментарии.
Отладка была сложна, пока не открыл для себя консольный предикат trace. Ставите его в то место, где что непонятное происходит и смотрите как идет раскрутка + у вас есть пара команд, чтобы оценить, как поведет себя бэктрекинг, запустить предикат на проверку и т.п.
Не программировать легко на Прологе, а читать — это 2 большие разницы. Существует некоторые программы, что не веришь, что они вообще программы, а не комментарии.Вот доказательство этого и ожидается от Вас, в принципе, если собираетесь развивать тему — на реальных примерах. ;) А ещё ответ на вопрос — куда это можно применять и как интегрировать. Т.е. будет ли выхлоп от того, что кто-то дополнительно выучит для себя новый язык. И каким образом этот профит произойдет.
За сим, с нетерпением будем ждать. :)
Эйлер вполне мог суммировать расходящиеся ряды.
Вот мужик был, прямо Чак Норрис среди математиков!
Я один прочитал сначала «языковые проблемы» как «языковые пробелы»?
На мой взгляд, пролог очень крут, но не как универсальный язык, а как язык запросов.
Пытался использовать пролог в разработке, просмотрел возможные варианты. Разобрался с сишным интерфейсом к swi-prolog, написал простую обертку для хаскеля.
Но фейл все-таки нашелся — этот интерпретатор не потокобезопасный. И использовать его, скажем, в веб приложении, не получится.
Мораль такова: стабильных работающих встраиваемых свободных реализаций нет.
Пытался использовать пролог в разработке, просмотрел возможные варианты. Разобрался с сишным интерфейсом к swi-prolog, написал простую обертку для хаскеля.
Но фейл все-таки нашелся — этот интерпретатор не потокобезопасный. И использовать его, скажем, в веб приложении, не получится.
Мораль такова: стабильных работающих встраиваемых свободных реализаций нет.
Не совсем понял про SWI-Prolog непотокобезопасный?
> If you are using SWI-Prolog as an embedded engine in a multi-threaded application you can access the Prolog engine from multiple threads by creating an engine in each thread from which you call Prolog.
Я хочу сделать базу фактов и обращаться к ней из нескольких потоков. Это сделать не получится, потому что на каждый поток нужно создавать свой «движок», наборы определённых предикатов для которых изолированы.
Я хочу сделать базу фактов и обращаться к ней из нескольких потоков. Это сделать не получится, потому что на каждый поток нужно создавать свой «движок», наборы определённых предикатов для которых изолированы.
Насколько я слышал простейшая имплементация Пролога в Лиспе 30 строк, вот пример имплементации реализации в Хаскеле не уверен насколько хорошая. Но факт в том, если ваша задача нетрудоемкая, старайтесь использовать интерпретаторы близкие к вашей среде — tuProlog на Java. Это поможет избежать изучение нового API (как удалять из списка, вычислять md5, ..) и позволит использовать нативные объекты, не вводя трансляторы из Хаскеля в Пролог и обратно.
Если ваша задача трудоемкая, то необходимо использовать process-embedded library, например, XSB. Она и потокобезопасная. В принципе, ничто не мешает запускать отдельные процессы.
Если ваша задача трудоемкая, то необходимо использовать process-embedded library, например, XSB. Она и потокобезопасная. В принципе, ничто не мешает запускать отдельные процессы.
Простейшая имплементация конечно простейшая, но нужны ещё стандартные предикаты, типы данных, многопоточность и ещё куча сложностей.
Да, именно для java есть очень много встраиваемых реализаций. Но тащить ради этого jvm как-то не хочется.
Есть мысль написать свою реализацию пролога, ориентированную на хранение данных. Точнее, дедуктивную СУБД с интерфейсом на datalog. Примерно так, как описано здесь: www.vldb.org/journal/VLDBJ3/P245.pdf. Хранить предикаты не в памяти, а на диске, сделать API для доступа к данным.
Поизучал WamBook, но разобраться и вплотную заняться этим проектом пока нет времени.
Да, именно для java есть очень много встраиваемых реализаций. Но тащить ради этого jvm как-то не хочется.
Есть мысль написать свою реализацию пролога, ориентированную на хранение данных. Точнее, дедуктивную СУБД с интерфейсом на datalog. Примерно так, как описано здесь: www.vldb.org/journal/VLDBJ3/P245.pdf. Хранить предикаты не в памяти, а на диске, сделать API для доступа к данным.
Поизучал WamBook, но разобраться и вплотную заняться этим проектом пока нет времени.
Wam очень мощная штука. XSB ее поддерживает с несколькими ограничениями. WAM — это абстрактная машина, которая позволяет очень быстро выполнять прологоориентированные программы. То, что вам нужно, это действительно datalog, а скорее всего bridge Relational DB -> Prolog. То есть факты хранятся в БД на диске, но вызываются через запросы на Прологе. Причем таблица из БД видна в Прологе, как обычный предикат с набором фактов stackoverflow.com/questions/724377/prolog-to-sql-converter.
Sql это частный случай той логики запросов, которую реализует пролог. Поэтому не каждая конструкция пролога может быть преобразована в запрос sql.
Если есть такой «bridge», то он на задание рекурсивных предикатов должен создавать в rdbms рекурсивную хранимую процедуру.
Для своих задач я бы не отказался от такой штуки.
Да и вообще, использование datalog вместо sql может сильно упростить жизнь. Например, писать foo(A,X1),bar(X1,X2),baz(X2,B). намного проще чем делать двойной join.
Если есть такой «bridge», то он на задание рекурсивных предикатов должен создавать в rdbms рекурсивную хранимую процедуру.
Для своих задач я бы не отказался от такой штуки.
Да и вообще, использование datalog вместо sql может сильно упростить жизнь. Например, писать foo(A,X1),bar(X1,X2),baz(X2,B). намного проще чем делать двойной join.
В этом и есть смысла бриджа, чтобы использовать только факты из таблицы данных, а запросы определять на уровне Пролога. Плюс решения немца, что он позволяет некоторые прологовские конструкции транслировать в sql, естественно не все, за счет этого увеличивается скорость запроса. Результат вы смотрите на Пролог программу, как на базу данных с готовыми запросами.
Когда 5 лет назад это направление выглядело очень перспективным, но думаю как всегда PL/SQL всех задавил административным ресурсом. Надо будет как-нибудь статью про это написать тем, что сейчас крайне популярны no-sql решения, где все по-новому.
Когда 5 лет назад это направление выглядело очень перспективным, но думаю как всегда PL/SQL всех задавил административным ресурсом. Надо будет как-нибудь статью про это написать тем, что сейчас крайне популярны no-sql решения, где все по-новому.
За ссылку на XSB спасибо, посмотрю что это такое.
Скажите, а вот какое-то подмножество естественного языка удобно парсить на Прологе? Например, задача: взять кучу объявлений по продаже машин на сайте типа «из рук в руки», и вычленить из каждого год выпуска, модель, цену? В простейшем варианте, без машинного обучения, с какой-то приемлимой долей ошибки. Ведь, хотя текст и пишется в произвольной форме, какие-то основные закономерности более-менее соблюдаются.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Prolog — грамматический разбор и языковые проблемы