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

[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ом, я не вижу. Кое-чего (например предикатов высших порядков) так не хватает, но в остальном - приличный язык.
По моему, хорошо подходит для обучения. Я, правда, дочку научить не смог - но мне вообще педагогических способностей не хватает.

[vitus_wagner]

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

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

[potan.livejournal.com]

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

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

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

[b-al-u.livejournal.com]

SciPy?

[potan.livejournal.com]

K, J?

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

[vitus_wagner]

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

[potan.livejournal.com]

Прошу прощения, испугался что за спам примут :-).

(в качестве ракламы) А вообще близкие ссылка есть в юзеринфо ru_declarative.

[vitus_wagner]

У меня - не примут. Я считаю что мне интересных ссылок приносят больше, чем спама.

[nealar.livejournal.com]

Кроме PAKCS есть ещё mcc.

[vitus_wagner]

А ссылку?

[avryabov.livejournal.com]

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

[vitus_wagner]

Сколько мегагерц и мегабайт было в твоем распоряжении 15 лет назад?
Насколько я помню, то что у меня в распоряжении было в 94, существенно уступает той доле ресурсов N900 которую abbra не жалко потратить на управление энергопотреблением (3-5% ресурсов устройства).

Собственно, провал проекта 5-го поколения в частности связан именно с тем, что тогдашние компьютеры были слабоваты. Сейчас мы с такой легкостью разбрасываемся гигагерцами и гигабайтами на кривые GUI, что prolog на этом фоне может оказаться вполне эффективным инструментом.

[avryabov.livejournal.com]

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

[abbra]

Пролог работает только в точке, где надо решение принять. Это, как правило, смена пользователем активного приложения или запуск нового. Реклассификация после принятия решения сделана на C. В целом, съедается менее трети процента, а чаще всего классификатор и модуль принятия решений спят. Они реагируют на exec()/fork() и некоторые другие действия.

[potan.livejournal.com]

В декларативных языках часто трудно предсказать производительность. Часто интуитивно-понятная реализация тормозит. Получить код, сопостовимый по производительности с C можно, но он получается едва ли не сложнее императивного :-(.
В Mercury запретили многие фичи, которые снижают производительность. На нем можно писать очень эффективно.

[avryabov.livejournal.com]

Получить код, сопостовимый по производительности с C можно, но он получается едва ли не сложнее императивного :-(.
Угу.
Что-то такое и вспоминается.

В Mercury запретили многие фичи, которые снижают производительность. На нем можно писать очень эффективно.
Будем знать.

[slobin.livejournal.com]

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

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

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

[potan.livejournal.com]

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

А для серьезной обработки строк (например в биоинформатике) интересно приспособить Рефал. Кстати, тоже во многом логический ;-).

[vitus_wagner]

О, как ни устроишь флейм про парадигмы програмирования, обязательно любители Рефала подтянутся. Рефал, рефу и буду рефать!

[slobin.livejournal.com]

Я как раз о несерьёзной обработке строк. Совершенно не уверен, что алгоритмы, хорошо обрабатывающие гигабайтные цепочки символов (кстати, а Рефал это делает? я не в курсе), будут хороши и на килобайтных. А, чтобы стать современным php, язык должен для начала вытеснить сам php. (задумавшись) Хотя, похоже, Руби это потихоньку удаётся...

... Защита от дурака на дур не рассчитана ...

[slobin.livejournal.com]

Вспомнил, кто это был: zhengxi. Он, правда, пишет в основном под замок, но и ты, и Витус у него во френдах. Вот тут про Mozart/Oz, а вот тут вообще про параллелизм (точнее, сначала про Go, но обсуждение ушло в параллелизм).

... Разве только вот воробьи ...