Обсуждение

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

хех, у нас постоянный выбор -- или бежать быстро-быстро еще на полметра вперед, или остановиться и потратить время на презентацию того, куда мы уже добежали. Мы кажинный раз выбираем бежать вперед и подождать с презентацией :) Нет проблем встретиться (пиши мне на ailev@asmp.msk.su -- договоримся), хотя мы слово design понимаем сейчас исключительно нехудожественно (и переводим "конструирование и проектирование"). Но выявлением "главной идеи" в чем-нибудь не очень внятном занимаемся более чем регулярно. И презентацией всяких "стратегий" и "жизненных циклов", хотя и без "дизайна"...

>И смежный вопрос -- а почему функциональные языки процветают, а логические так и влачат маргинальное существование со времен компьютеров пятого поколения? Область применения узкая. Модель вычислений Пролога ещё сложней, чем модель вычислений ленивых ЯП. Программирование в ограничениях легко вписывается в обычные ЯП. По нужде и там, где нужно, не более. Так что в логических языках смысла особого нет.

Функциональные языки расцветают с функциями высших порядков, замыканиями и прочими приятными вещами, которых на уровне FOL быть не может, а над HOL никто прилично не реализовал. Да и с известной направленностью вычислений (в функциональных и императивных языках) работать удобнее. Наиболее удобным решением, на мой взгляд, была бы интеграция "мультинаправленных" решений в не-логические языки, с использованием их там, где для нескольких требующихся направлений действительно пригодно одно декларативное описание. Внезапно, именно это (пока на уровне "языка как библиотеки в языке") получаеется в нашем проекте.

А чем "логические" языки принципиально отличаются от других декларативных? Что такого можно написать на прологе, чего нельзя на SQL?

Ты повторяешь мой вопрос. Есть ведь Curry-Howard. Но функциональные цветут и пахнут, а логические вымирают, как динозавры.

Вот это "работать удобней" как раз непонятно. Для логиков даже controlled English есть, чего нет ни для каких других языков... Насчет высших порядков, вполне возможно, в этом всё дело: где у логик непонятная вычислимость, в других языках для частных случаев находятся конкретные алгоритмы. А гипотеза о том, что FOL в итоге вставится во все языки, скорее всего подтвердится.

То есть логический язык -- это такой крутой перец, которым перчат, но его не едят ложкой отдельно. Логические языки везде понавставляются в конечном итоге, это я понимаю, это текущий тренд. Насчет "узкой области применений" тут как раз логики спорят сильно. Насчет модели вычислений -- волнует ведь не модель вычислений, а удобство использования. Или освоить Haskell легче, чем Prolog?!

>это текущий тренд Так же, как вставление всюду замыканий, параллельные вычисления и тп. >Насчет модели вычислений -- волнует ведь не модель вычислений, а удобство использования. Ну, например, система типов. Я на Mercury не давно смотрел, когда последний раз интересовался системой типов для Пролога, она была неразрешимой (undecidable). Система типов - следствие модели вычислений. Система типов, также, обеспечивает удобство рассуждений о прогармме и все программисты ей пользуются, даже если отрицают это. >Или освоить Haskell легче, чем Prolog?! Да, легче. Односторонняя унификация, модель вычислений из двух операций.

ОК, все парадигмы пропитывают друг друга: логика, замыкания, параллельные вычислния и т.д. Тут у нас консенсус. Про систему типов -- я бы не сказал, что динамические типы кому-нибудь мешают, ежели глядеть на вечнозеленые Smalltalk, Python и прочая из этой серии. Религиозность подхода к типам мне понятна (конечно, все программисты пользуются типами, весь вопрос, как именно), аргументы сторон -- тоже понятны и им лет по тридцать от роду. Поэтому "отсутствует нормальная система типов" тут не аргумент (Mercury вряд ли бы распространился по миру, как пожар, даже если бы система типов там была эффективной), да и "проложность" меня меньше волнует -- функционально-логические языки идут в народ еще хуже, чем чисто логический пролог или чисто функциональный хаскел. Интересно, почему объект-ориентированное программирование рулит. Там что, модель вычислений из одной операции? У хаскеля -- из двух. У пролога что, в модели вычислений три операции? Можно ли связать распространение языка с числом операций в модели вычислений? Тут я молчу о Машине Тьюринга, и почему на ней не программируют...

Не FOL, а мультинаправленные решения в целом. Ограничиваться первым порядком есть смысл только для ряда domain experts. Пример с нашего совещания - если простая фильтрация помещается в FOL, то ядрёные мэппинги в UI требуют более мощных механизмов мультинаправленности, а также сочетания однонаправленного и мультинаправленного кода. Опять же, Controlled English это сахар. Когда для какой-то предметной области достаточно первого порядка, с совпадающими методами вычисления для всех направлений - ок, можно сверху присыпать семантику сахаром, облегчив воспринимаемость. Такой же сахар можно найти в Inform 7 или AppleScript для совершенно другого семантического низа. Неудобна именно семантика Prolog, для всех тех случаев, когда "получить a из b" и "получить b из a" осуществляется различными способами, не выводимыми автоматически один из другого. А в реальности это и есть самый распространённый случай.

>я бы не сказал, что динамические типы кому-нибудь мешают, ежели глядеть на вечнозеленые Smalltalk, Python и прочая из этой серии. Система типов идёт рука об руку с семантикой. Чем сложнее семантика, тем сложнее система типов. Объектные системы типов не могут выразить ничего более-менее полезного, у них проблемы с выводом типов и тд. Поэтому объектные языки очень часто динамические - St, Python тому пример. Почитайте, насколько сложна семантика у St или Python. Такого в сети хватает - "как я в очередной раз подумал, что в Пайтоне это просто, а оказалось, что там такой ужас!". Народ ими пользуется из-за низкого порога вхождения. Пока не пользуешься вещами, которые могут быть полезны для больших проектов (те же функции высших порядков) или пользуешься готовыми наработками для решения задач, очень похожих на твою, всё идёт отлично, радости нет предела. >Поэтому "отсутствует нормальная система типов" тут не аргумент И именно поэтому "отсутствие нормальной системы типов" тут аргумент, да ещё какой. Вот, смотрите. В Прологе мы имеем недетерминизм и побочные эффекты одновременно. При этом любая функция у нас тотальна: она всегда может вернуть "ложь" на любой вход. И если на классификацию яблок мы подадим апельсин, что произойдёт? Ошибка. Как её отыскать? Кто сделал унификацию с апельсином? И будет хорошо, если такая ошибка проявится сразу. А то мы вдруг получили "false", хотя программа должна работать бесконечно. Это general protection fault, только от языка, в котором такого не ждёшь. Пролог очень труден для программирования больших систем. Я пытался на нём написать диалог с пользователем банкомата - со всеми возможными вариантами. Неуловимые ошибки прут изо всех щелей. Создавая Эрланг из Прологе, отрезали всё прологовское, натурально. А то рассуждать о программах не получалось совсем. Надо сказать, что в ленивых ЯП проблему недетерминированности и побочных эффектов решили, двумя способами - монады и фуджеты. Всё потому, что были типы и комбинаторы (то есть, функции возвращают значение и не тотальны для всех возможных значений всех типов). >Интересно, почему объект-ориентированное программирование рулит. Сперва это был дешёвый полиморфизм по первому аргументу функции или процедуры, теперь деньги. >Там что, модель вычислений из одной операции? Деньги. Объектно-ориентированное программирование возможно только поверх машины Тьюринга. >У хаскеля -- из двух. У пролога что, в модели вычислений три операции? http://en.wikipedia.org/wiki/Unification_%28computing%29#Examples_of_unification В алгоритме унификации не менее трёх правил. >Можно ли связать распространение языка с числом операций в модели вычислений? Да, если не действуют другие силы. В математике, например, всё так и происходило. Все интересные результаты сперва получались для лямбда-исчисления (простая система типов, её непротиворечивость, вывод типов для неё, система типов с полиморфизмом, система типов Мартина-Лёфа и тп), а потом переносились в другие контексты - Фортран, например, с системой типов аналогичной простой системе типов ЛИ появился на 18 лет позже. Логик Хиндли сделал вывод типов для полиморфного ЛИ в 1968 году, в C# это попало когда? Года три назад, да и то, работает через пень-колоду. >Тут я молчу о Машине Тьюринга, и почему на ней не программируют... У неё три операции. Не программируют потому, что сложна. Начали использовать потому, что её упрощённый вариант оказалось проще реализовать в железе.

1. Как я понял, вы говорите, что "мелкая нежная трава кушается прорвой динамически типизированных насекомых" (и задач больше, и барьер вхождения меньше), а "толстые деревья кушаются огромными зубастыми типизированными динозаврами" (и задач меньше, и барьер вхождения больше) -- в итоге биомасса динамических насекомых выше биомассы типизированных динозавров, что сбивает с толку. Я бы не согласился. Отлаживаемость языка, конечно, задается его конструкцией, но она отнюдь не только типизацией определяется. Пролог и пайтон имеют разное распространение, а выигрыш хаскела у питона определяется отнюдь не тем, что там монады и фуджеты (по вашей теории -- тем, что там унификация на операцию больше). 2. Как я понял, вы подтверждаете гипотезу, что для неимперативных языков число операций в алгоритме унификации определяет их потенциальный успех (поэтому акторские и логические языки в загоне, а функциональные потихоньку выходят вперед). Но для императивных языков я всё равно не понял -- при их трех операциях в алгоритме унификации у них не должно было быть шанса. Лисп должен был давно мутировать и всех вынести. Но пока что этого не происходит. Даже хаскел в больших задачах в целом маргинален по сегодняшним меркам. 3. Тут еще есть мотив "побеждают не языки, а инструменты". Но трудно объяснить, почему для одних языков появляются десятки инструментов, а другие языки с одним-двумя убогими (например, медленными -- как у Пайтона) инструментами процветают. Дискуссия, конечно, вся носит отчетливо религиозный характер. Такие дикие выплески, как временный успех Perl, или даже C, она не объясняет...

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

>Отлаживаемость языка, конечно, задается его конструкцией, но она отнюдь не только типизацией определяется. Я повторю мой тезис: проще семантика ≡ проще типы. Чем проще семантика, тем проще рассуждать о программе. Чем проще рассуждать о программе, тем проще программировать. Чем проще программировать, тем больше программистов. Чем проще типы, тем больше программистов. >Пролог и пайтон имеют разное распространение, а выигрыш хаскела у питона определяется отнюдь не тем, что там монады и фуджеты (по вашей теории -- тем, что там унификация на операцию больше). Судя по всему, вы имели в виду сравнение Пролога и Хаскеля. И операция унификации Хаскеля (сравнение с образцом) имеет вполне определённое направление, в отличии от двунаправленной унификации Пролога. Выигрыш Хаскеля у Пролога определяется только и исключительно простотой ядра Хаскеля по отношению к Прологу. Которая позволила сделать IO и Fudgets. >Но для императивных языков я всё равно не понял -- при их трех операциях в алгоритме унификации у них не должно было быть шанса. Не в алгоритме унификации, а в семантике. С точки зрения человека, ЛИ описывает человека с карандашом и бумагой. МТ - карандаш, бумага, ластик. >Лисп должен был давно мутировать и всех вынести. Но пока что этого не происходит. Лисп прагматичен и удерживается в нынешнем состоянии длительное время количеством наработок, как Фортран. Тем не менее, есть Схема - как раз мутация. Результат труда полутора человек, используется много, где. >Даже хаскел в больших задачах в целом маргинален по сегодняшним меркам. Те, кто серьёзно этим занимаются - большими задачами, - те про Хаскель знают и используют. Просто большинство считает, что это "ракетная хирургия" и обычным людям не нужно. Вот и маргинальность. >Такие дикие выплески, как временный успех Perl, или даже C, она не объясняет... Если уж приплетать религиозность в нашу дискуссию, то у иудеев есть способы толкования Торы применительно к ситуации. Итак, Perl. Протокол WWW был сделан текстовым, что позволяло работать с ним обычному человеку. Распространение WWW привело к взрыву количества серверных программ. Однако у обычных ЯП работа с текстом никакая из-за работы с памятью, и наилучший вариант работы с текстом был у Perl - как анализ заголовков WWW для CGI, так и анализ отчётов серверов. Простота семантики работы с текстом. Тем не менее, его тут же вынес PHP, который работу с WWW выполнял ещё лучше. И тикль прорвался на эту сцену: AOLserver. А вот попробуйте на Перле сделать DSeL - мало не покажется. DSeL делают на Лиспах и прочих Хаскелях (а ранее делали на Форте). Популярность C. Во-первых, простота семантики. Во-вторых, часто кроме компилятора C на машине ничего не было - Фортран платный, Ада платная, Паскаль работает с P-машиной и медленный... В любом случае, простота семантики определённых операций чрезвычайно важна.

Таких не бывает. Логическая парадигма это ограничение, как только появляется направленность вычислений - язык становится функциональным. Единственный случай, когда язык на базе Prolog стал популярным - Erlang, обычный функциональный язык. А вот полезную возможность включать мультинаправленность я бы не считал характеристикой "что-то + логических" языков. Есть другие примеры, включая Harmony/Boomerang. Здесь как с pattern matching, который начался с нескольких языков, включая императивный SNOBOL, функциональный РЕФАЛ и логический Prolog, но "в народе" чаще связывается с более поздними поколениями функциональщины.

Нет, я говорю, что там где надо писать декларативно, пишут на других, "нелогических" декларативных языках. Если нужны идиомы "логических" языков, несмотря на их проблемы, пишут на прологе, но, видимо, такие случаи редки. Логическое/сентенциальное программирование могло бы стрельнуть, будь у нас массовая быстрая ассоциативная память. Но ее как 30 лет назад не было, так и нет. На адресуемой памяти во всех выходящих за пределы школьного курса случаях логического программирования об эффективности приходится думать вручную или измерять ее, так что для него нужны очень веские основания. (Мне, конечно, в этой связи жалко не пролога, а рефала, хотя он и не логический в узком смысле). И, кстати, а вот эрланг --- логический, или все-таки функциональный?

Эрланг -- функциональный (хотя и разрабатывался при помощи Пролога). Как ехидно заметили тут по треду выше, "из него всю проложность выкинули, ибо только мешала". То есть логическая парадигма -- это временнЫе грабли, по твоей оценке. То есть не научились еще оптимизировать. Питоновская программа имеет шанс дойти в тщательно вручную писанном алгоритме при очень неспешливом движке, функциональная уже более выразительна, но опять таки очень медленна -- но не запредельна, ибо не полный перебор, а алгоритм. Логика -- все алгоритмы сводятся к тому или иному перебору. Получается, что логические алгоритмы будут хороши на "запутанных фотонах" (если делать ассоциативную память, то сразу на современной элементной базе ;), а императивные -- хороши сейчас на стековых/конвейерных архитектурах. А для функциональных алгоритмах нет такого железного зверя, для которого они были бы хороши -- им пофиг, почему и выживают :)

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

Ой, тут дискуссия сразу пошла во все стороны. Остались тезисы: а) проще семантика -- проще типы -- больше программистов [тут я соглашусь] в) больше задачи -- нужны сложные типы -- их будет решать меньше программистов. Функциональные языки уже позволяют делать сложные типы, а логические языки еще нет (хотя со временем и для них ожидается математика). [тут есть и альтернативные мнения, ниже по треду] г) по мере понимания языкоориентированности программирования в целом побеждать будут языки, в которых легко делать DSeL. Тогда всех победить должен функциональный наследник Форта -- Factor (мне лично, кстати, этот язык очень нравится). Но он более чем маргинален. А успокоится всё language workbench на Java, т.е. не язык будет побеждать, а IDE типа MPS или Whole Platform (вот уж где DSL в ассортименте). То есть в вашей модели предпочтений нужно выбирать для сложных задач сложность семантики максимальную, на которую тянут мозги текущих теоретиков -- и работать с такими языками (проверяя заодно на возможность реализации DSeL). Сейчас это Хаскел, раньше была Схема, в любом случае речь идет о функциональных языках. Логические уже слишком сложны, императивные и ОО -- слишком просты.