softwarerОписание задачи обязательно содержит (хорошо описанную) цель и (необязательно) может содержать (обычно краткое и неполное) описание решения. Описание задачи сосредотачивается на вопросе "ЧТО СДЕЛАТЬ". Описание решения обязательно содержит (хорошо описанный) алгоритм или другое методическое изложение действий и (необязательно) содержит (обычно кратко сформулированное) описание цели. Описание решения сосредотачивается на вопросе "КАК СДЕЛАТЬ".
Да-да, рассуждения "ЧТО сделать" vs. "КАК сделать" весьма популярны, но к сожалению толку от них методологически никакого. В примере с женитьбой это хорошо видно (см ниже).

Что касается наличия алгоритма в описании решения, то по этому критерию запрос SQL вполне декларативен, т.к. в запросе формально алгоритма нет (алгоритм есть в реализации запроса), а цель определена очень чётко: получить такое-то отношение. Боюсь, это сильно подрывает представление участника ViPRos о "полном отсутствии в SQL декларативности".

softwarerЕсли я правильно Вас понимаю, Вы хотите "волшебный критерий" для чёткого отнесения произвольного текста к той или иной группе, имея в виду пример текста с хорошо описанной целью и хорошо описанным решением. Я хочу? Это участник ViPRos утверждает, что определение декларативности сводится к отличению описания задачи от описания её решения. Так я всего-то хочу, чтобы он пояснил, как он отличает первое от второго.

softwarerЕвгений Мирошниченко aka mirВопрос 2 (пример). "Женись до конца года". Это описание задачи или способа решения задачи?
Недостаточно информации. Это может быть как описание задачи (как хочешь, но женись!), так и описание решения (как мне получить налоговый вычет?)О том и речь, о том и речь.

ViPRosЕвгений Мирошниченко aka mirпропущено...
Вопрос 1 (общий). Как формально отличить описание задачи от описания способа её решения, чтобы выполнить следующее: смотрим на некоторое описание и заключаем "это описание задачи" или "это описание решения задачи"?

Вопрос 2 (пример). "Женись до конца года". Это описание задачи или способа решения задачи?

Заметьте, я не спрашиваю, кто вы такой, как вы сделали в отношении меня. Я прошу дать конструктивное определение декларативности , и прошу это ещё с первой страницы данного обсуждения.

Готов удовлетвориться ответом только на второй вопрос, который пример про женитьбу. Challenge accepted?
1. Очень сложный вопрос и я не готов экспромтом на него ответить (а может и не смогу и подумав)
А как же вы без этого с невероятной лёгкостью определили, что в запросе на SQL ну нисколечко декларативности нет? Выходит, что мнение-то ничем не обосновано.
ViPRos2. Это постановка задачи. (если принять что постановщик и озадаченный присутствуют и постановщие имеет полномочии, т.е. имеется нужный контекст).А вот и неверно. Как выше подсказывают опытные товарищи, это вполне может быть как постановкой задачи, так и описанием решения совершенно другой задачи .

Например так. По завещанию вы получите деньги, только будучи женаты к 30 годам. Вам 29 лет. Задача: получить деньги по завещанию .
Способы решения:
1. Женись до конца года .
2. Подкупи поверенных.
3. Сделай фальшивое свидетельство о браке.
...

Я обещал вам дать пояснения. Так вот, вопрос "данная система является описание задачи или описанием решения" -- штатный вопрос системной инженерии. Только там он формулируется следующим образом: "система -- это функция или это конструкция?" Стандартный ответ таков: система это одновременно и функция, и конструкция. Этоот дуализм лучше всего отображается моделью гамбургера от Wim Gielingh (Extended GARM) (см. например http://dot15926.livejournal.com/14735.html )

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

Следовательно, понятие декларативности ровно в той же мере относительно. Невозможно говорить о декларативности в абсолютных терминах, как вы пытаетесь делать, типа декларативно/недекларативно. Можно лишь идти по уровням иерархии, тогда верхний уровень будет по отношению к текущему уровню более декларативным. А если две системы не находятся на однозначно разных уровнях иерархии, сравнивать их по степени декларативности просто бессмысленно.

Ну и, соответственно, высказывания типа "SQL абсолютно недекларативен" -- ни о чём.

ViPRosЕвгений Мирошниченко aka mir,

ты мне лапшу не вешай , а внимательно читай мой ответ
я "КОНТЕКСТ" е просто ввел, так что можешь не рассусоливать про наблюдателя и уровни декомпозиции

решение задачи =
1. Свести задачу к уже решенной задаче (женись, подкупи и т.д. в твоем случе принмаем за ЗАДАЧИ с имеющимся решениями)
2. Свести к нерешаемой задаче.

воти вес гамбургер

FROM, JOIN ON, UNION - явные императивы (и это при том, что они вычислимы, если добавить унифицированный механизм типизации)Во-первых, не тыкайте незнакомому человеку. Во-вторых, брякнуть слово "контекст" -- это ни о чём. Речь шла о конкретных определениях, а вы пишете практически на уровне "на деревню дедушке". Влт опять же пишете "Свести задачу к тому-то". Родной, "свести задачу" -- это набор слов, который без конкретики ничего не значит. И вот так у вас всё время.

И ваш ответ на пример с женитьбой показал , что понимания у вас нет. Ответили-то вы неверно. А когда человек не желает "рассусоливать про наблюдателя и уровни декомпозиции", это просто показатель теоретического уровня. И с эдаким-то уровнем вы собрались мега-теоретически вопросы обсуждать? Декларативность SQL отвергать? Не смешно.

Вот вы пишете "бардак в башках", только о чём? Что вы не понимаете умных слов, которые уважаемые дяденки вам говорят (я не о себе, о Гилинге, Левенчуке и т.д.)?

softwarerЕвгений Мирошниченко aka mirно к сожалению толку от них методологически никакого.
Отчего же? Оттого, что это общие слова, которые при соприкосновении с реальностью теряют смысл. "Женись" это ЧТО или КАК? От контекста зависит.

softwarerЕвгений Мирошниченко aka mirВ примере с женитьбой это хорошо видно (см ниже).
В примере с женитьбой видно, что такое плохая постановка задачи (и почему она плохая). Соответственно, он доказывает всего лишь, что надо делать нормальные постановки.Нормальная чёткая постановка. Показывает, что одно и то же описание может быть на одном уровне функцией (ЧТО сделай), а на другом конструкцией (КАК сделай).

softwarerЕвгений Мирошниченко aka mirБоюсь, это сильно подрывает представление участника ViPRos о "полном отсутствии в SQL декларативности"
Ну об этом Вы беседуйте с Сахаватом, не со мной. ?

softwarerЕвгений Мирошниченко aka mirТак я всего-то хочу, чтобы он пояснил, как он отличает первое от второго.
А как Вы отличаете букву "ч" от цифры "4"? Я сказал Вам, как их отличает нормальный человек с нормальными человеческими способностями. А Вы, такое ощущение, просите алгоритм для безмозглого робота.А вы предлагаете все постановки делать на уровне "два лаптя по карте"? Или в инженерии есть место и потребность в несколько большей строгости?