Возрождение логического программирования

[vitus_wagner]

Когда-то давно японцы с большой помпой организовали проект "компьютеров 5-го поколения". С упором на логическую парадигму, в частности язык Prolog. Проект с треском провалился.

В начале 90-х использованрие Prolog воспринималось скорее как курьез, хотя по крайней мере одну геоинформационную систему в нашей лаборатории в Почвенном институте (еще до моего прихода туда) на Turbo Prolog написали.

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

А вот сегодня abbra пишет об использовании Prolog в системе управления энергопотреблением Nokia N900.
Я злобно ругаюсь у него в комментариях. Почему? Да точно так же я бы ругался если бы кто-то сегодня использовал Fortran IV для решения задачи которую стоит решать в каком-нибудь Matlab или использования gw-basic там, где под рукой есть интерпретатор Python.

Другое дело, что предложить инструмент логического программирования эквивалентный по зрелости Python или Matlab я, пожалуй, не возьмусь. Если проводить параллель между Prolog и Fortran (хотя может быть, разумее сравнивать Prolog с basic - уж больно до хрена диалектов и Turbo среда опять же существовала), то make - это аналог bourne shell. Причем даже gnu make - ни разу не bash, а в лучшем случае dash. На bash/zsh тянут разве что bras и ему подобные make replacements.

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

Но вообще тенденция возвращения логического программирования интересна. Да, конечно, мы потеряли 20 лет. Но теперь, пусть из-за внутренних потребностей вычислительной техники - управления её собственным энергопотреблением, возвращаются технологии, которые пригодны для управления объектами реального мира. Вспомним, что Шумил описывает управление киберами именно как логическое программирование.

Comments

[potan.livejournal.com]

Prolog сегодня это не то же самое, что Prolog 20 лет назад. Он развивается.
Из интересных разработок в области ЛП отмечу Mercury и Curry. Первый очень эффективен, хоть и поддержка ЛП ограничена. Curry очень красив (синтаксис и многие фичи взяты из Haskell), но как-то вяло развивается.
Но сейчас более интересно обобщение ЛП - программирование в ограничениях.

[vitus_wagner]

Ну так Forran 90 это тоже не то же самое, что Fortan IV. А все равно закопать надо, чтобы не воняло, даже несмотря на миллионы строк накопленного кода.

А вот насчет Curry как современного языка ЛП надо посмотреть. Тем более что Haskell моден. Из этого может получиться "php от ЛП".

[wizzard]

>> php от ЛП

Да, эт надо бы. Обкатка технологии на массах - это полезно.

[potan.livejournal.com]

Боюсь, Curry повторит судьбу Clean. Mercury, все-таки практичнее. И предсказуемее (за счет отказа от некоторых возможностей).

А серьезных ляпов в дизайне Prologа, которые давали бы повод сравнивать его с Fortranом, я не вижу. Кое-чего (например предикатов высших порядков) так не хватает, но в остальном - приличный язык.
По моему, хорошо подходит для обучения. Я, правда, дочку научить не смог - но мне вообще педагогических способностей не хватает.

[http://users.livejournal.com/__const__/]

А Fortran 2003 не то же самое, что Fortran 90.
Извиняюсь, но что-то матлаб за альтернативу не держу. Особливо с учётом несвободности оного.
А более и считать-то нечем.

[vitus_wagner]

А вообще стоит ссылки давать.

[avryabov.livejournal.com]

Серьезно? лет 15 назад я делал на прологе одну программу.
Тогда столкнулся с эффектом недостаточной производительности.
то бишь простенькую задачу пролог тянул, но такие простенькие я и в уме быстро решал.
а там где перебор был по-больше, то пролог просто "зависал", и для получения ответа пришлось переписать всю логику на C, который, как раз вполне справился.
После чего мои эксперементы с прологом закончились.

[slobin.livejournal.com]

Но сейчас более интересно обобщение ЛП - программирование в ограничениях.

Угу. Тут кто-то (вспомнить бы кто...) явным образом предлагал Oz (ах, да, "ссылки давать"... в общем, Mozart/Oz) как современный Питон. Он принципиально, по построению, мультипарадигменный, и программирование в ограничениях среди прочих парадигм там тоже есть. Единственное "но": на традиционно питоновских (перловых etc...) задачах -- обработке строк -- он тормознооой. Впрочем, Эрланг этим тоже отличается, и ничего, используют помаленьку. Да, кстати, весь Эрланг внутри Оз тоже есть. Разве что насчёт подмены модулей на лету не уверен, и то, кажется, видел в примерах реализацию.

... Если я правильно ошибаюсь ...

[father-gorry.livejournal.com]

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

[potan.livejournal.com]

Ну между отвертной и стамеской тоже разница небольшая :-).

[eldhenn]

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

[zerthurd.livejournal.com]

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

[andrzejn]

Я крайне поверхностно знаком с логическим и функциональным программированиями, поэтому мне любопытно:

Можно ли кратко указать, какая существенная возможность Prolog отсутствует в современных функциональных языках - всех этих ML, Haskell, Clean, F#?...

[potan.livejournal.com]

Автоматический перебор с возвратом. Двунаправленные функции.
В классическом Prolog-е есть динамическое обноврение базы данных (assert) - это частично заменяет отсутствие макросов и сближает с динамическими языками.

[permea-kra.livejournal.com]

Витус, а посмотрите на языки, которые term rewriting. типа Pure.

[slobin.livejournal.com]

Часа два, наверное, смотрел. За это время вынес два соображения:

1. Для начала можно вообще не думать о нём как о "языке", а думать как о замене bc. Как об ОЧЕНЬ мощном калькуляторе. Витус, помнишь задачку от Белявского про 9^9^9? Pure на ней всех порвал, как Тузик грелку. Собственно, насколько я понял, автор языка сам им пользуется, чтобы видео и звук обсчитывать. Ну то есть считают, естественно, библиотеки, а язык -- просто удобный к ним интерфейс.
2. Семантика переписывания термов поначалу вводит в ступор при мелких ошибках. Например, если 3%6 вычислился обратно в 3%6 -- это потому что дробь не сокращается, или потому что я use math; сказать забыл? Пример нарочно тривиальный, но возможны и более реалистичные.

Но вообще да, интересная чем-то штука. Правда, совсем не Пролог. ;-) P.S. ссылка

... Я тут посчитал немного ...

[max630.livejournal.com]

Вот я так и не понял, что такое это логическое программирование. Учебные примеры на prolog по тасованию родственников совершенно неубедительны, кроме того непонятно как это имплементироваить иначе как полным перебором вариантов.

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

[migmit.vox.com (from livejournal.com)]

Пролог - это такой один большой перебор с возвратом, и ничего больше.

[vitus_wagner]

А вот make и есть ЛП. Единственное широко распространенное. Найди кратчайший путь к решению поставленной задачи и сформулировать последовательность действий, исходя из некоторой базы фактов об окружающем мире - это и есть ЛП.

[dottedmag.livejournal.com]

"непонятно как это имплементироваить иначе как полным перебором вариантов."

Ты быстро нащупал слабое место Prolog :)

Это backtracking с перебором. А чтобы перебор не вылиывался в экспоненту - в реализацию добавляются хаки / прагматы / форсирование порядка перебора.

[volodymir-k.livejournal.com]

> Проект с треском провалился.

Казалось бы, не работает -- похоронить и забыть. Пробовали много раз, разные люди. Не работает. Нет, "возрождают".

[vitus_wagner]

Ну так потребность значит есть. Когда у Можайского не полетело и у Максиа не полетело, летательный аппарат тяжелее воздуха все равно пытались сделать. Пока в конце концов у братьев Райт не полетело.

[vit-r.livejournal.com]

XSLT - убогий наследник Лиспа.

[afa-at-work.livejournal.com]

вот интересно, кста.
а рубишный rake куда среди мэйков отнесен будет?

[the-realistic.livejournal.com]

В Windows NT версии до 4ой на Прологе была написана та часть control panel, что строила реестр для сетевых компонент.

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

В 4рке вместо Пролога сделали скриптовый язык INF файлов, они были _императивные_, и да, отдаленно смахивали на Питон.

В w2k все это выбросили, и вместо этого сделали декларативный язык INF файлов (PnPшных, по некоей концептуальной сути оно похоже на make), с возможностью воткнуть куда не попадя еще и специфичные для компонента, написанные в машинном коде, coinstaller и notify object DLLs. В первом грубейшем приближении - сначала все делается на основе INF файлов, потом этот первый результат предъявляется nofify objectам, что вносят в него правки.

Это и по сей день так.