Ответ на »сообщение 66« (AK)
___________________________
В примере, иллюстрирующем декларативный подход, непонятно, что с этим _описанием_ делать дальше. 

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

Ответ на »сообщение 67« (Антон Григорьев)
___________________________
Всё-таки, где границы этого подхода? Есть же функции, которые принципиально не могут быть реентерабельными - Random, например.
От изменения состояния системы никуда не деться. Хош на лиспе программируй, хош на хаскеле.
Такой задачи никто не ставит. Я уже говорил, что без императивной составляющей любой функциональный язык - это сферический конь в ваккууме :))

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

Недружелюбность императивных языков к функионвльному подходу является достаточным поводом для того чтобы существовали функциональные языки.

Я уже приводил пример кода где я передаю функцию в другую функцию. Это повсеместная практика на лиспе.
Т.е. для меня это самое обычное дело. Я это делаю ПОСТОЯННО.
Однако когда я работаю на дельфи или javа я практически никогда этой техникой не пользуюсь.
Почему ? Потому что трудно. Легче работать с обьектами.

Но я хотя бы по привычке пытаюсь писать функции чистыми (там где это возможно). А возможно это на императивных языках мало где. Опять таки потому что ограничен в технических средствах (не могу передавать функции как параметры и получать их как результат) Не могу потому что трудно а не потому что невозможно.
Я не буду плыть против течения.

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

Ответ на »сообщение 63« (Антон Григорьев)
___________________________

Видимо, самым располагающим к функциональному программированию из компилируемых императивных языков был Алгол, точнее, те его версии, в которых была реализована передача параметра по имени

С этим аргументом трудно не согласиться. Передача по имени (позабытый механизм Алголов) усиливает возможности "трансформации" программ.

Ответ на »сообщение 64« (Jack Of Shadows)
___________________________

Я полагаю вы использовали Пролог по назначению.

Ровно для того чтобы использовать Пролог по назначению, и участвовал в создании связки Modula-2/Prolog/Lisp, где Modula-2 была фундаментом, но при этом поддерживалось двусторонняя связь языков.

Ответ на »сообщение 65« (Jack Of Shadows)
___________________________

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


Всё-таки, где границы этого подхода? Есть же функции, которые принципиально не могут быть реентерабельными - Random, например.

Ответ на »сообщение 53« (Jack Of Shadows)
___________________________

Я думаю Geo искал что то более практичное и приземленное нежели ваше обьяснение.
Да у ж куда приземленней-то? И практичней.

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

Далее, Вы приводите очень интересный пример.

Сравните например:

Декларативный (функциональный) подход.
1. Небо темно-синее.
2. На Небе звезды
3. Звезды блестят серебрянным светом.

Императивный подход:
1. Покрасить небо в темно синий цвет
2. Вывесить на небо звезды.
3. Покрасить звезды в серебрянный цвет.

В функциональном подходе нет состояния. Вы можете поменять местами любую из строчек - смысл не поменяется, система не поломается. А теперь попробуйте поменять местами операции в императивном подходе.
Если вы поставите 1 строчку последней, то вы закрасите звезды синим цветом. Система поломается.
Вы должны обращать внимание на то где и в какой последовательности что выполняется.


В примере, иллюстрирующем декларативный подход, непонятно, что с этим _описанием_ делать дальше. Где здесь объявления и композиция функций (если это функциональный подход)? А если это логический подход, то должна быть фаза вопросов к программе, типа: Небо синее? --> Да. Звезды блестят золотым цветом? --> Нет. И т.д.
Как по мне, Вы смешиваете два подхода. Но об этом чуть позже. Так как идет речь пока о примере, илюстрирующем возможность "поломатости" системы в императивном подходе.

Предложим свой контрпример.

Функциональный (аппликативный):
Предположим, есть две функции
g(x) = x * 3
f(x) = x + 2

Сформируем программу:
h(g(f(x)))
Как видим, никаких переменных, никаких состояний, только объявления функций и их композиция.

Указанная выше функциональная программа эквивалентна императивной программе:
x <- x * 3
x <- x + 2

Например, для значения аргумента X равного 5 получим результат 21.

Но. Вы совершенно точно указываете, что поменяв операторы местами в императивном подходе, мы получим другой результат. В случае того же начального значения аргумента 5 во втором случае получим 17. Но тот же самый результат мы получим, скомпоновав другим образом функции в первом варианте, т.е.
h(f(g(x))).
Как видим, функциональная система "поломалась". Относительно ожидаемого результата, конечно.

Что касается неразличения парадигм в рамках декларативной. Вполне обосновано можно применить термин "декларативный" и к императивным языкам. Просто нужно сказать, что такие языки декларируют операции исполнителя. Хотя некоторые авторы и определяют логический и функциональный подход как разновидности декларативного все-таки я бы различал функциональный(аппликативный)(пример, язык LISP) подход и декларативный(логический)(пример, язык Prolog). В основе указанных подходов лежат разные математические модели и их не следует смешивать. Мне кажется, что в рамках данной ветки логичней употреблять термины "функциональный" и "аппликативный", а "декларативный" отнести все-таки к логической парадигме.
ИМХО.

Ответ на »сообщение 62« (Руслан Богатырев)
___________________________
Дальше. В Обероне есть процедурные переменные, которые есть ничто иное как указатели на процедуры (с контролем сигнатуры-интерфейса допустимых процедур).

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

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

Ответ на »сообщение 62« (Руслан Богатырев)
___________________________
Те, кто писал на Прологе, наверняка знают, сколь навороченным все это общение становится.

Я полагаю вы использовали Пролог по назначению. Писать на прологе программы, это дикое заблуждение эпохи моды на ИИ.
Я вот сейчас кстати использую пролог, наряду с forward chaining rule engine.
Оба написаны на лиспе. Великолепный инструмент надо сказать.
Мы держим на нем базу знаний, и самые обычные программы на дельфи обращаются через http к серверу правил (эдакая экспертная система) чтобы она говорила этим тупым императивным программа что делать.
Отлично работает. Каждой задаче - свой инструмент.

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

var
  SomeGlobalVar:Integer;

procedure SomeProc(name Param:Integer);
var
  Local1,Local2:Integer;
begin
  SomeGlobalVar:=10;
  Local1:=Param;
  SomeGlobalVar:=20;
  Local2:=Param;
  ...
end;

...

SomeProc(SomeGlobalVar+5); {*}

Когда выполняется вызов {*}, переменная Local1 получит значение 15, а Local2 - 25, т.е. при обращении внутри функции к формальному параметру, передающемуся по имени, производится вычисление выражения, переданного в качестве фактического параметра. Реализовывалось это так: для каждого фактического параметра компилятор создавал функцию, вычисляющую соответствующее выражение, и передавал в стек её адрес, а обращение к соответствующему формальному параметру интерпретировалось как вызов функции по этому адресу.

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