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

[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

[vitus_wagner]

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

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

[wizzard]

>> php от ЛП

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

[potan.livejournal.com]

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

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

[vitus_wagner]

Нет там серьезных ляпов в дизайне. Это просто первая ласточка, как и Fortran. Где у Fortran-а серьезные ляпы в дизайне, которые можно было в 50-е годы предвидеть?
Просто со времен создания пролога Computer Science ушла далеко вперед. Кстати, поэтому и не удается научить ребенка прологу. Ребенок просто не может понять "а нафига это?". Нужны библиотеки, которые позволяли бы легко и естественно взаимодействовать хотя бы с игровой реальностью. Попробуй make поучить. На примере каких-нибудь ценных для ребенка задач.

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

[potan.livejournal.com]

Так в Prolog-е и на современный взгляд ляпов нет. Ни чему плохому оно не научит. В отличие от Logo с dynamic scope.
А мотивация для Prolog-а есть. На нем удобно и красиво логические задачки решать. Мы с дочкой числовые ребусы решали - за одно и умножение слолбиком повторили.

[vitus_wagner]

На самом деле важно то, чего еще в прологе нет, кроме ляпов.

Я об этом и написал. Для того, чтобы от логического программирования была польза, необходимо
1. Собрать исходные данные для принятия решения. Т.е. нужен интерфейс к тому, что эти данные предоставляет.
2. Суметь это решение реализовать. Т.е. нужен интерфейс к эффекторам.

Сферический пролог в вакууме - это примерно как C без не только POSIX, но и вообще без libc. Не то чтобы вещь совсем бесполезная (можно ядра ОС писать, например), но с очень ограниченным диапазоном применения.

[permea-kra.livejournal.com]

Вопрос - а не тянет ли sql и некоторые языки запросов, типа xquery, на такие вот приземлённые прологи?

[vitus_wagner]

Не тянет. Но тот язык, который будет претендовать на место "php от ЛП" обязан будет уметь использовать SQL как источник фактов, на основе которых принимать решение.

[taris_marh.livejournal.com]

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

[vitus_wagner]

Писать надо не "устав", а "боевые приказы". Это более реалистично получится.

[taris_marh.livejournal.com]

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

[vitus_wagner]

НУ в смысле "устав" должен писаться разработчиками игры. Это часть игрового мира. А вот "приказы" - писаться игроком по ходу на основе анализа обставновки (вернее сводок, поступивших из штаба).

[permea-kra.livejournal.com]

Baldurs Gate в частности и многие ролевушки в целом.

[taris_marh.livejournal.com]

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

[potan.livejournal.com]

Да, я тоже о такой игре мечтаю :-).
Даже заглядывал в исходники freecraft в надежде что руки дойдут реализовать. Но руки так и не дошли, да и исходники мне не понравились.

PS Есть игра Colobot, но там возможности роботов ограничены, некоторые операции может выполнять только человек. Да и винда требуется...

[taris_marh.livejournal.com]

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

Re: Colobot

[kostix.myopenid.com (from livejournal.com)]

Colobot — не очень хороший пример: он программируется слишком императивно. То есть учить детей императивному программированию можно, но вряд ли можно логическому.

И вообще это не только с ней проблема такая. Как я понимаю, и MindRover, и TORCS, и все эти "стотыщпицот" различных "войн роботов", подразумевают императивное программирование.

[fau74.livejournal.com]

Dragons Age, ныне модный.
Там каждому неписю в команде можно повесить tactical clause - при наступлении таких-то ситуаций выполнять такие-то действия. Действия от самых грубых ("напасть", "встать в оборону") до, например, "зайти со спины и атаковать" или "догнать и перехватить атакующего на себя". Ситуации тоже разнообразны. В результате можно запрограммировать что-нибудь интересное.

Что интересно - количество таких clauses можно нарабатывать с экспой и со специализациями, в результате персонаж с опытом "умнеет".

[kostix.myopenid.com (from livejournal.com)]

Что-то такое появилось по-моему ещё в бородатых текстовых MUD'ах: можно было задавать реакцию протагониста на различные события в игре.

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

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

[b-al-u.livejournal.com]

SciPy?

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

MPI как?

[potan.livejournal.com]

K, J?

А вообще жалко что SISAL загнулся. Для расчетов он хорошо бы подошел.

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

кратко:
MPI как? OpenMP могут?

[potan.livejournal.com]

SISAL для MPI писал lispnik как курсовую. Не знаю, довел ли до ума.
На K написана СУБД, которая поддерживает кластера. Правда не MPI, а свой протокол.