20 лет назад у меня был какой-то курс в универе где мы использовали Prolog. Тогда мне язык показался занятным, но практического применения ему так и не было видно и я про него как-то и забыл. А сейчас, в конце года, все "языкозамерялки" выпускают годовые обзоры и Prolog фигурирует фактически во всех них и сильно не на последних места, где-то рядом с Haskell, Elixir, OCaml, D и другими коммерчески используемыми, пусть и не мэйнстримовыми языками.
Соответственно я подумал, если за 20 лет Prolog так и не сдох, что странно как мне кажется, то наверное его где-то используют в коммерческой разработке? Или это всё это ощущение живого языка вызвано использованием его в университетах для обучения? Может кто-то его использует сейчас в коммерческой разработке? А для каких задач?
Здравствуйте, kaa.python, Вы писали:
KP>Соответственно я подумал, если за 20 лет Prolog так и не сдох, что странно как мне кажется, то наверное его где-то используют в коммерческой разработке? Или это всё это ощущение живого языка вызвано использованием его в университетах для обучения? Может кто-то его использует сейчас в коммерческой разработке? А для каких задач?
В википедии пишут, что на прологе сделаны , и часть IBM Watson:
Prolog is used for pattern matching over natural language parse trees. The developers have stated: "We required a language in which we could conveniently express pattern matching rules over the parse trees and other annotations (such as named entity recognition results), and a technology that could execute these rules very efficiently. We found that Prolog was the ideal choice for the language due to its simplicity and expressiveness."
Здравствуйте, Михaил, Вы писали:
М>В википедии пишут, что на прологе сделаны , и часть IBM Watson:
М>
М>Prolog is used for pattern matching over natural language parse trees. The developers have stated: "We required a language in which we could conveniently express pattern matching rules over the parse trees and other annotations (such as named entity recognition results), and a technology that could execute these rules very efficiently. We found that Prolog was the ideal choice for the language due to its simplicity and expressiveness."
Кстати, да, TerminusDB — единственный живой проект на Prolog что я нашел на GitHub.
Здравствуйте, kaa.python, Вы писали:
KP>Соответственно я подумал, если за 20 лет Prolog так и не сдох, что странно
Почему странно, это логический декларативный язык программирования. И у тебя нет задач для которых он требуется. Скажу даже более, были бы такие задачи, лично я бы подумал о создании собственной структуры данных и алгоритмов, которые используются для обхода списков, при этом отказавшись от парсера.
Так что дело здесь вовсе не в языке, а в заложенных в него идеях. А данные удобнее было бы хранить в базе данных, нежели в скриптах. Опять же лично для меня всё это больше находится в категории библиотек алгоритмов, нежели языков программирования.
Здравствуйте, velkin, Вы писали:
V>Так что дело здесь вовсе не в языке, а в заложенных в него идеях. А данные удобнее было бы хранить в базе данных, нежели в скриптах. Опять же лично для меня всё это больше находится в категории библиотек алгоритмов, нежели языков программирования.
Мне, как изучавшему Пролог в универе, кажется, что проще написать весь этот рекурсивный обход с возвратами самому, на своём языке программирования, чем тащить Пролог. По-любому придётся что-то допиливать, реализация движка кажется не такой сложной, как допиливание и изучение чужого велосипеда.
P.S. Поискал на Гитхабе "prolog interpreter" — вагон реализаций на всём подряд, даже писать самому не надо, просто пользоваться. На плюсах даже compile time prolog есть.
Здравствуйте, kaa.python, Вы писали:
KP>20 лет назад у меня был какой-то курс в универе где мы использовали Prolog. Тогда мне язык показался занятным, но практического применения ему так и не было видно и я про него как-то и забыл. А сейчас, в конце года, все "языкозамерялки" выпускают годовые обзоры и Prolog фигурирует фактически во всех них и сильно не на последних места, где-то рядом с Haskell, Elixir, OCaml, D и другими коммерчески используемыми, пусть и не мэйнстримовыми языками.
Интересно, чем и как меряли.
KP>Соответственно я подумал, если за 20 лет Prolog так и не сдох, что странно как мне кажется, то наверное его где-то используют в коммерческой разработке? Или это всё это ощущение живого языка вызвано использованием его в университетах для обучения? Может кто-то его использует сейчас в коммерческой разработке? А для каких задач?
Ну вот например в Windows NT 4, пишут, использовали его для генерации внутренней конфигурации сетевых интерфейсов.
В Gerrit на нём пишутся правила определения, какие оценки необходимы для ревью, чтобы его допустить в целевые ветки — можно изменять стандартные правила (уровни оценок, выделенные права/обязанности лидов, дополнительные ключи оценок и всё такое). Я эту штуку однажды настраивал, в принципе понимая Prolog, и чуть не поседел: разобраться, когда какая свёртка правила будет выполнена, оказалось нетривиально. На прошлой работе вообще этим не заморочились и всё свалили на Jenkins: если для конкретной репы нет тестов, он автоматически назначает Verified:+1.
Коллега рассказывал про использование Prolog для... обсчётов траекторий космических аппаратов — выбирался наиболее ценный путь среди обсчитанных, собирая их по кусочкам. Сейчас уже не помню названия конкретного аппарата.
Здравствуйте, kaa.python, Вы писали:
KP>20 лет назад
Интересно, примерно тогда же мне мой коллега говорил про сложности i = i + 1 в Прологе, это там отсутствует в принципе. И, знаете, я заметил странное кхм, как бы так точно, я то уже знал Пролог, ощущение мэтча. Не то, чтобы эврика, но мэтч — точно. И совсем немного предыстории.
Это было в Одессе, и человек говорил об этом весело и задорно, так будто он, поняв шутку, и потопав дальше что-то уяснил еще для себя, и вперед по Потемкинской лестнице вверх.
И вот, есть некое ощущение, что многие столкнувшись с этой сложностью в языке не приемлют его, по причине может неверного психического состояния в момент столкновения с этой проблемой. После чего человек получает негативный опыт и в дальнейшем мы получаем уже проблему другого масштаба. Встречал в архитектуре c++. "Наш герой", назовем коллегу так, столкнувшись с вычислениями в компайлтайм в С++ (где 100% принципы похожие), получает либо двойной стресс непонимания, в том случае, если он уже учил и получил стресс от пролога. Либо он получает стресс первого уровня. Но — практически сразу становится враждебен технологии. Ну и моментально в опозицию архитектуре ..коду, языку, отрасли)) всему. И бегом к виртуальным функциям греться, или отмокать. И дело даже не в самом прологе или С++, это один из видов логик используемых на практике, поняв философию чего, ты уже ощутив нечто похожее в другой области будешь иметь инициативу.
как-то так,
а про геррит, ну не знаю, вроде писать на пайтоне начинали? А потом переписали на джаве, и что туда куда-то пролог еще внедрили, не знал . Слышал есть Prolog.Net но 13-ый год последний коммит.
Что понравилось:
— нормальный Пролог, без расширений (вроде виртуальных предикатов как у Visual Prolog)
— встраивание в C++, то, что у них называется Logic Server API.
— Eclipse как среда, кросс-отладка — можно поставить останов в С++ и в Прологе и перемещаться между ними
— очень быстро получилось сделать прототип — на Прологе была его встроенная "БД" + "хранимые процедуры" — запросы к этой БД
— код работы с "БД" очень простой, понятный
Всё заработало, но закончилось всё печально
Вылезли проблемы с производительностью — оказалось, что по чтению из БД всё норм,
а вот когда надо взять сроку A, сложить со строкой B и покласть в БД и сделать так много-много раз — чудовищные тормоза...
Отчасти, как я понял с форумов, проблема в реализации этого Пролога — Virtual machine architecture.
Пришлось за 2 недели переписать этот прототип полностью на С++, сэмулировав интерфейс к Прологу и его работу.
Думаю, если бы взял бы другой Пролог, может всё и выгорело бы.
Хвалят этот Sicstus Prolog, но он дорогой.
И еще такой: Quintus Prolog.
Есть еще Datalog, к сожалению, не попробовал ничего с ним поделать.
Здравствуйте, kaa.python, Вы писали:
KP>Соответственно я подумал, если за 20 лет Prolog так и не сдох, что странно как мне кажется, то наверное его где-то используют в коммерческой разработке? Или это всё это ощущение живого языка вызвано использованием его в университетах для обучения? Может кто-то его использует сейчас в коммерческой разработке? А для каких задач?
Я могу поделиться своим опытом использования всего одной фичи встроенной в пролог при выводе типов. Фича эта — унификация. Для вывода типов доработанный унификатор (поддерживающие унификацию с подтипами) очень упрощает задачу. Впервые я увидел это в Nemerle, а потом использовал это в Nitra.
Проблем у пролога две:
1. Производительность. Базовый алгоритм унификации портит результат. По этому приходится изобретать систему отката значения. В итоге при наивной реализации получается очень храмовая сложность (стремится к квадрату от n). На это дело ложится перебор с возвратами увеличивая вычислительную сложность и доводящий ее до мало применимой на практике.
2. По сути Пролог это не совсем ЯП. Скорее это БД замаскированная под ЯП. Отсюда специфичность решаемых задач.
В реальной жизни, как не странно большинство задач решается хорошо скорее императивно. Бессмысленнее ФП в ГУЕ. Его там можно применять, но как не крути форма или веб страница — это изменяемые данные. К прологам придумано много императивных расширений, но на фиг они нужны, если есть высокоэффективные императивные ЯП? От части ФП (вошедшее в современные императивные ЯП) отняло у Пролога пальму декларативного первенства.
О Прологе — как будущем ИИ говорил еще мой отец в начале 90х. Он тогда работал проректором в одном институте повышения квалификации и по совместительству развлекался созданием экспертных систем, которые тогда считались зачатками ИИ.
Мне кажется, что в исходном виде Пролог не взлетит. Фактически на рынке его вытеснил SQL, в котором нет унификации, но который решает ту же задачу декларативной обработки данных, и для которого созданы эффективные механизмы выполнения на огромных массивах данных.
А вот механизм унификации мог бы прекрасно быть встроен в современные ЯП. Его можно и в виде библиотек использовать, но интеграция в язык могла бы дать новый уровень. Особенно если такой ЯП будет поддерживать зависимые вычисления (их часто называют ленивыми, но ленивость это побочный эффект, который можно и не использовать). В Nitra мы использовали движок зависимых вычислений для записи изменения унифицируемых объектов и последующего отката. Получилось намного эффективнее Nemerle-овй версии использующей для этого копирование при модификации и последующие откаты. Унификация позволяет строить графы зависимых объектов. В нашем случае это типы и параметры типов.
Вообще, тема новых ЯП не раскрыта. Современные языки в лучшем случае впитали себя идеи 1970-х годов. Та же многопоточность в компилируемых языках нормально не сделана нигде. Есть только Эрланг и его последователи. В общем, поле очень широкое. А индустрия очень консервативна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
спасибо за рассказ про Пролог, крайне интересно было!
VD>Вообще, тема новых ЯП не раскрыта. Современные языки в лучшем случае впитали себя идеи 1970-х годов. Та же многопоточность в компилируемых языках нормально не сделана нигде. Есть только Эрланг и его последователи. В общем, поле очень широкое. А индустрия очень консервативна.
Ну я бы сказал что в Го многопоточность очень прилично сделали, в реальной продуктовой разработке просто зверь. Хотя то что есть в BEAM получше будет, но тут или все данные константные и высокий порог входа, или привычный императивный язык.
Здравствуйте, kaa.python, Вы писали:
KP>Ну я бы сказал что в Го многопоточность очень прилично сделали, в реальной продуктовой разработке просто зверь. Хотя то что есть в BEAM получше будет, но тут или все данные константные и высокий порог входа, или привычный императивный язык.
Не. Я Го посмотрел. Там сделана та же ошибка как и всех других. Очереди могут быть двунаправленными (привет дедлокам) и можно разделять состояние между потоками обрабатывающими сообщения и другие. А именно этого нужно не допускать. В этом отношении Эрланг выглядит самым концептуально чистым. Но он интерпретируемый. Хорошей идей было бы ввести нечто вроде эрлэнговых акторов с полноценной изоляцией памяти и общением только асинхронными сообщениями, но так чтобы в песочницах можно было использовать всю мощью полноценных ЯП включая ООП, ФП и метапрограммирование.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
KP>>Ну я бы сказал что в Го многопоточность очень прилично сделали, в реальной продуктовой разработке просто зверь. Хотя то что есть в BEAM получше будет, но тут или все данные константные и высокий порог входа, или привычный императивный язык.
VD>Не. Я Го посмотрел. Там сделана та же ошибка как и всех других. Очереди могут быть двунаправленными (привет дедлокам)
Ничем не отличается от того, что кто-то заведёт две очереди и устроит дедлок между ними.
VD> и можно разделять состояние между потоками обрабатывающими сообщения и другие. А именно этого нужно не допускать.
Можно писать без такого разделяемого состояния, организовав соотв. дисциплину.
VD> В этом отношении Эрланг выглядит самым концептуально чистым.
Слишком чистым, писать под него нереально. (Знаю, сейчас кое-кто на букву S скажет, что я опять не умею под него писать.)
VD> Но он интерпретируемый. Хорошей идей было бы ввести нечто вроде эрлэнговых акторов
А почему "э"? половина западников произносит его "а́рлан".
VD> с полноценной изоляцией памяти и общением только асинхронными сообщениями, но так чтобы в песочницах можно было использовать всю мощью полноценных ЯП включая ООП, ФП и метапрограммирование.
Здравствуйте, kaa.python, Вы писали:
KP>20 лет назад у меня был какой-то курс в универе где мы использовали Prolog. Тогда мне язык показался занятным, но практического применения ему так и не было видно и я про него как-то и забыл. А сейчас, в конце года, все "языкозамерялки" выпускают годовые обзоры и Prolog фигурирует фактически во всех них и сильно не на последних места, где-то рядом с Haskell, Elixir, OCaml, D и другими коммерчески используемыми, пусть и не мэйнстримовыми языками.
Тоже был курс в универе, и так же я потом задавался вопросом "а где применять?". Живых проектов не нашёл, но пришёл к выводу, что язык стал плацдармом для изучения различных алгоритмов перебора. В этом плане видно небольшое сходство с Lisp: современных проектов на Lisp нет, потому что есть языки куда как более удобные, но Lisp весьма удобно использовать в академических целях, демонстрируя различные приёмы ФП.
Здравствуйте, VladD2, Вы писали:
VD> Хорошей идей было бы ввести нечто вроде эрлэнговых акторов с полноценной изоляцией памяти и общением только асинхронными сообщениями, но так чтобы в песочницах можно было использовать всю мощью полноценных ЯП включая ООП, ФП и метапрограммирование.
Pony как раз такой примерно. Но там местами перемудрили.
Здравствуйте, VladD2, Вы писали:
VD>В реальной жизни, как не странно большинство задач решается хорошо скорее императивно. Бессмысленнее ФП в ГУЕ. Его там можно применять, но как не крути форма или веб страница — это изменяемые данные.
Бесплатные undo/redo.
Возможность делать асинхронный УГИ. Это когда мы посылаем запрос на сервер и сразу же возвращаем заглушку ответа, которая будет заменена, когда придёт ответ. При этом остальной ГУИ не блокируется.
VD>Вообще, тема новых ЯП не раскрыта. Современные языки в лучшем случае впитали себя идеи 1970-х годов. Та же многопоточность в компилируемых языках нормально не сделана нигде. Есть только Эрланг и его последователи. В общем, поле очень широкое. А индустрия очень консервативна.
Эрланг в морг. Там selective receive, а у SR извлечение сообщения из очереди O(размер очереди). Соответственно разбор очереди O(N^2). Что произойдет в случае кратковременного всплеска нагрузки объяснять надо?
Нормальная многопоточность есть в rust. Там всё как ты хочешь.
Изоляция данных внутри потока. При этом можно писать императивно.
Можно пересылать изменяемые данные, между потоками имея гарантии, что старый поток не сохранит ссылки.
Мьютекс защищает данные. При захвате мьютекса мы получаем ссылку на данные. При отпускании мьютекса компилятор проверит, что ссылок на эти данные не осталось.
Можно превращать изменяемые данные в неизменяемые и шарить между потоков.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
KP>20 лет назад у меня был какой-то курс в универе где мы использовали Prolog.
30 лет назад я в Ташкенте общался с перцем, которые по приколу для задач АСУ на некоем предприятии использовал ТурбоПролог от Борланд...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
