Декларативное программирование

Порешай на Прологе типовые задачки, сразу ощутишь грань :)

Разница как между «Возьми кисть, окуни в ведро с краской, нанеси мазок, повтори» (императивный подход), «Покрась стену» (декларативный) и «Стена окрашена» (разметка).

Ну хорошо, это все-таки не только, и не столько декларативное, сколько логическое. Стоит под капотом движок, занимается логическим выводом. А если исключить логику?

SQL довольно декларативен местами например. И да, Йогурт правильно упомянул Пролог — тоже весьма декларативненько. Собственно рекомендую первую (или вторую) лекцию SICP, там показывается наглядно на примере разница между декларативностью и императивностью.

Честное слово, вот не могу понять я такой вещи. Есть у нас разные языки, которые принято называть языки разметки, например xml. Очень похоже на декларативность, не правда-ли?

Все верно, xml декларативен.

Только вот я в толк никак не возьму, как на этом можно программировать?

Это не относится к декларативности, это относится к полноте по Тьюрингу.

Xml - декларативный, не Тьюринг-полный. Haskell - декларативный, Тьюринг-полный. Си - не декларативный, Тьюринг-полный.

Очень похоже на декларативность, не правда-ли?

Не «похоже», а это она самая и есть.

Это, кагбе можно, условно назвать программированием.

Про Тьюринг-полноту слышал?

Разница как между «Возьми кисть, окуни в ведро с краской, нанеси мазок, повтори» (императивный подход), «Покрась стену» (декларативный) и «Стена окрашена» (разметка).

То есть, если мне надо просто взять кисть, и не красить, я не смогу этого сделать, так?

BTW, большой разницы между последними двумя пунктами не вижу. Всего лишь, разница в словоформах, смысл одинаков, поскольку «покрась стену» автоматом превращается в «стена окрашена»

«Покрась стену» - императивщина. «Стена окрашена» - декларативщина.

Xml - декларативный, не Тьюринг-полный.

:'} А лисп тьюринг полный?

(* (+ 1 2) 3)

~~

<funcall name=«mul»>
  <arg id=«1»>
    <funcall name=«add»>
      <arg id=«1»>1</arg>
      <arg id=«2»>2</arg>
    </funcall>
  </arg>
  <arg id=«2»>
    3
  </arg>
</funcall>

Главное, вычислятор к нему написать.

Не слушай его. Аналогия не верна.

«покрась стену» - императивное действие.

А лисп тьюринг полный?

А лисп не декларативный.

В теории вычислимости исполнитель (множество вычисляющих элементов) называется тьюринг-полным...

wiki://Полнота по Тьюрингу/

Про Тьюринг-полноту слышал?

Слышал, но не совсем понятно, что это значит в данном контексте. Возьмем ту же стену. Допустим, у нас есть алгоритм перекрашивания стены в другой цвет. Как мы можем сделать это без деструктивного присваивания? Хорошо, мы можем скопировать весь «мир» и связать стену с другим цветом и затереть старый кадр новым, при этом, сам процесс перекрашивания невыразим. Считать ли это тем же самым, вопрос философский...

Императивный подход: перекрашиваешь стену из старого цвета в новый.

Декларативный подход: у тебя есть стена нужного цвета.

скопировать

Императивное действие.

Кстати, а чем отличается ТС от anonimous?

Юзернеймом.

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

А CSS3 вообще полон по Тюрингу.

html (по крайней мере в старых версиях) - не тьюринг-полный язык программирования.

чистый html может решить задачу с конечным числом возможных ответов (одна страница = один возможный ответ)

на нем действительно трудновато решать большинство задач

GNU Make видел? CMake, даже scons? Вот оно и есть декларативное программирование. А теперь иди учить уроки, сопля.

«Покрась стену» (декларативный)

нет. просто другой уровень абстракции. следующий уровень, например, «построй дворец».

нет. просто другой уровень абстракции. следующий уровень, например, «построй дворец».

Имхо, «покрась стену» и «построй дворец» находятся в пределах одного уровня абстракции.

окей, справедливо. ну сути это не отменяет, все равно императивно.

func Покрась_стену() { 
 Возьми_кисть(); 
 окуни_в_ведро_с_краской();
 нанеси_мазок();
 повтори(); 
}

func построй_дворец() {
 ...
 Покрась_стену();
 ...
}

Так понятней?

Да, здесь будет, но только в том случае, если в дальнейшем мы будем манипулировать такими понятиями как построй дворец, построй дом и т.д. А если просто: «покрась стену» «построй дворец» «построй город» - здесь это сущности одного порядка - «do anything».

Императивный подход:

скопируй файл A в директорию B

Декларативный:

В директории B лежит копия файла A

Как можно заметить:

• декларативный подход не обязательно означает меньше кода
• разница с императивным подходом заключается исключительно в выборе точки зрения

Спасибо, очень наглядно.

Насколько я понял, 2 кусок означает, что «под капотом» файл копируется, но мы абстрагированы от этого «грязного действа»?

Вот такой пример еще.

Скопировать A в A1;
Скопировать B в B1;
Объединить A1 и B1 в C;

Файл C это объединение файлов A1 и B1, где A1 - это копия A, B1 - это копия файла B

Принципиальная разница между первым и вторым подходом, в том, что мы не описываем явно control flow, позволя это делать самой среде. Например компилятор может скопировать файлы параллельно. Мы задаем только отношения между входами и выходами.

Декларативный: В директории B лежит копия файла A

Это не декларативное программирование, а самовнушение.

Декларативный код должен отвечать на классический вопрос: «Что делать». Императивный - на вопрос: «Как делать».

Чем дальше читаю этот тред, тем более отчетливо ощущается приближение Первомая. :)

С праздником, коллеги.

XSLT — вполне себе декларативный ЯП

Декларативный код должен отвечать на классический вопрос: «Что делать»

шаг 1: Что делать? Скопировать A в A1;
шаг 2: Что делать? Скопировать B в B1;
шаг 3: Что делать? Объединить A1 и B1 в C;

Это по-Вашему декларативный код? А что же тогда вот это:

Файл C это объединение файлов A1 и B1, где A1 - это копия A, B1 - это копия файла B

Xml - декларативный, не Тьюринг-полный.

Зато XSLT Тьюринг-полный %)

переносите это в лолксы сразу, засрут как обычно
и да, на прологе напиши уже чегонить, перестанешь задавать глупые вопросы
зы, я видел этот тред на 1 странице

Это по-Вашему декларативный код?

А почти любой код на каком-то уровне декларативен. Например:

foo = bar(0);

этот фрагмент можно считать декларативным кодом, ставящим цель «занести значение функции bar от аргумента 0 в переменную foo». Как это будет сделано - отдается на откуп компилятору: он может вызвать bar, может подставить тело функции в место вызова, может сам на этапе компиляции посчитать значение.

И, естественно, этот же фрагмент можно считать обычным исперативным кодом, изменяющим значение переменной foo.

Этот код можно считать декларативным, но он не отвечает на вопрос «как делать», он, как раз отвечает на вопрос «что это?» (что такое foo?).

Этот код можно считать декларативным, но он не отвечает на вопрос «как делать»,

Декларативный код вообще не отвечает на вопрос «как?».

как раз отвечает на вопрос «что это?» (что такое foo?).

Не отвечает, но это нерелевантно.

шаг 1 ... шаг 3 - Это по-Вашему декларативный код?

По-моему, каждый шаг декларативен. А их последовательность - императивщина.

А что же тогда вот это: Файл C это объединение файлов A1 и B1, где A1 - это копия A, B1 - это копия файла B

Это определение. Чтобы его превратить в декларативную программу надо указать (пусть неявно), что делать с файлом С. Если еще добавить последовательность действий, то получим императивную программу.

Нет, я к тому, что вы сказали, что приведенный Вами код можно рассматривать двояко: как им императивный (что делать? — присвоить) или как декларативный (что это? - значение bar()). Я с этим не спорю. Но я отвечал на:

Декларативный код должен отвечать на классический вопрос: «Что делать». Императивный - на вопрос: «Как делать».

Как делать? — этот вопрос к вашему коду вообще никак не клеется. С этой точки зрения он по-любому декларативен.

Я говорил про то, что «что делать?» — это не признак декларативности. ИМХО, декларативность - это как раз констатация факта, lovesan, ранее правильный пример приводил, демонстрирующий отличие подходов.

каждый шаг декларативен. А их последовательность - императивщина.

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

Как делать? — этот вопрос к вашему коду вообще никак не клеется

См. выше.

См. выше.

Нет, компилятор — это вопрос реализации, к парадигме он отношения не имеет. Юзер ЯП не должен думать, как компилятор «сделает это». Поэтому, еще раз, вопрос «Как?» тут не стоит вообще.

Нет, компилятор — это вопрос реализации

Декларативное программирование (комментарий)

По-моему, каждый шаг декларативен. А их последовательность - императивщина.

ИМХО, в декларативном коде не должно быть последовательности шагов. Например: 1. деревья зеленые

2. кора их — серая

3. крона их — развесистая

Где тут шаги? На уровне реализации — это мож шаги, но не на уровне семантики.

Декларативный код вообще не отвечает на вопрос «как?».

Я бы сказал, что «найди решение задачи ABC по методу XYZ» вполне декларативное задание, хотя вопрос «как» здесь уместен. Чтобы превратить его в императивное, надо явно расписать все шаги метода XYZ.

Я бы сказал, что «найди решение задачи ABC по методу XYZ

Где Вы тут нашли декларативность я хз. Декларативно было бы так: «решением задачи ABC по методу XYZ является...»

Здесь ровно столько же декларативности, как и в запросе:

select * from ABC where f=XYZ

проиграл