Ответ на »сообщение 249« (hugi)
___________________________
Этот вариант тоже не является по-настоящему функциональным.

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

Ответ на »сообщение 249« (hugi)
___________________________
То есть перебрать элементы списка один за другим, не производя его декомпозицию с помощью операций первый_элемент, остальные_элементы, у Вас называется "работать не напрямую"?

Насчет декомпозиции списка в ФЯ только что говорил: »сообщение 248« :)) Как будто предвидел ваш вопрос. :))

Ответ на »сообщение 247« (Как слышно? Приём!)
___________________________

В визуальных-то языках скелет проекта приложения строится
по описаной выше ... ещё выше ... схеме легко.

Это не имеет отношения к дискуссии ФЯ\ИЯ. Это к проектированию, т.е. к проблемам которые решаются (или проваливаются) одинаковыми методами как в ФЯ так и в ИЯ.
Я помню на базарной площади была ветка посвященная методам и проблемам проектирования.
Думаю ваш вопрос уместен там.

Ответ на »сообщение 243« (Jack Of Shadows)
___________________________
Результат да, но не логику. Логика все также прямолинейна. Т.е. с точки зрения человека, описывающего процесс, разницы нет.
Я человек, и с моей точки зрения разница есть, причём ощутимая.
(Насыпать-в-чай список-ложек)
(Сыпем (первая список-ложек)
(Насыпать-в-чай (остальные список-ложек))
Этот вариант тоже не является по-настоящему функциональным. Т.к. Вы последовательно изменяете состояние кружки с чаем:(Сыпем (...)). Хотя, если последовательность

(operation1 (a)
    (operation2 (b)))

автоматически создаёт и возвращает список, то всё ОК (по части примера, но не модели).
К тому же в этом случае нужно предварительно сформировать список (в реальности этого не происходит, и даже в ФП это необязательно, а в ИП и подавно не нужно).
Просто в ИЯ это делать настолько громоздко, что даже когда у вас есть список данных, вы все равно предпочитаете работать почему то не напрямую с ним, а опосредствованно, через число итераций, типа
i = 0 то list.Count - 1
То есть перебрать элементы списка один за другим, не производя его декомпозицию с помощью операций первый_элемент, остальные_элементы, у Вас называется "работать не напрямую"?

Я думаю пришла пора обьяснить чем же отличается список в ФЯ от списка в ИЯ.
Заметьте я с казал в ФЯ а не в лиспе.
Дело в том что во всех ФЯ внутреннее предсталение спика одинаково, неважно, работаете вы с лиспом или с хаскелем.

Возьмем список (1 2 3 4)
Казалось бы простенький плоский список. Не совем так!
На самом деле это такая вложенная конструкция (как матрешки).
Выглядит она вот так: (1 (2 (3 (4 ())))
Т.е (1 a) где a это тоже спикок (2 b) где б это тоже спикок (3 с) где с это тоже список (4 d) где d это тоже список () т.е пустой список.

Даже список с одним элементом на самом деле имеет два элемента.
Т.е. (1) на самом деле это (1 ()) т.е. первый элемент 1 и второй элемент пустой список.

ОК скажете вы, ну и плевать, мне то что ? Я же записываю плоско (1 2 3 4)
Какая разница, как список предствален внутренне.

Огромная разница, уважаемые. Огромная!!

Благодаря тому что список предствален вложенными парами (tuples или cons в лиспе) их можно обрабатывать 2 функциями
(first spisok) дает вам первый элемент списка.
(rest spisok) дает вам ОСТАЛЬНЫЕ элементы списка. На самом деле он просто дает вам второй элемент из пары.
Но поскольку тот является списком то вы получаете то что хотели.

first и rest (первый и остальные) или в лисповом синтаксисе car и cdr используется во всех без исключения рекурсиях. Именно наличие этого механизма делает возможным, естественным и легким рекурсию.

ОК, но почему бы не работать с first и rest в ИЯ ? Разве нельзя вернуть список в которм убран первый элемент ?
Физически можно. Практически нереально.
Функцию first реализовать в ИЯ легко. А вот rest (остальные) - трудно. Для этого придется каждый раз создавать новый список без первого элемента и передавать его дальше.
Представьет себе обработку списка из миллиона записей. Любой компьютер сдохнет! Никакой памяти не хватит!

А в ФЯ все гораздо легче, ведь rest не создает новый список, просто возвращает указатель на уже готовый.
Поэтому в ФЯ рекурсивная обработка списков практически возможна и по эффективности не уступает итерации.

Когда научишься работать со списками в рекурсивном режиме, это такое удовольствие! Это так естественно для человека, это так легко!! (не нужно помнить обо всех этих временных переменных, о счетчике цикла итд итп)

К сожалению, когда переходишь обратно на ИЯ (работать надо) то приходится возвращаться к циклам.

Циклы (for, while) превращают программирование в скучную и трудную работу.
Рекурсия (там где она практически возможна конечно, т.е. в ФЯ) возвращает вам обратно радость программирования.

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

>>> Вот где настоящий расход памяти.
Приказ же был: "Патронов не жалеть!" Наступило изобилие памяти
и тактовой частоты, ядра раздвояются и прочие чудеса.
Поэтому сравнивать надо скорее ФЯ не с Си подобным императивом,
а с визуальным программированием или конструированием.
Собирать приёмник из транзисторов и прочей рассыпухи это
в прошлом. Микросхемы в ходу.

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

А вот о разработке общей структуры проекта в мануале не вычитаешь.
По мне, общий принцип разработки приложения примерно таков.
1) Выясняем постановку задачи, выясняем то, что хотим получить.
В этом смысле декларации важны, созвучны и органичны, если
ты не кодер - машинистка, а задачу понимаешь широко.
2) Разбиваем большую задачу на относительно независимые куски
до уровня прожевываемости куска за раз. (Может здесь кроется тяга
к модулям) . Устанавливаем связи между ними. Модель готова.
3) Ну и делее.

Так вот, вопрос. Разбиение на куски и построение системы, здесь,
в ФЯ, - это установление набора функций и связи по их аргументам?
Или как? Скелет проекта смутно представляю как может строиться.
Или к мизинцу на ноге пририсовываем пятку, потом коленку, потом ...,
потом спину и так до макушки.
В визуальных-то языках скелет проекта приложения строится
по описаной выше ... ещё выше ... схеме легко.

Нашёл описалово НА РУССКОМ по лиспу (жаль-pdf) двухтомник 15 и 13 Мб:
http://www.dvo.ru/tech/lisp/index.html
Ссылку проверил - работает.

Ответ на »сообщение 245« (Jack Of Shadows)
___________________________
А во избежание подобных недоразумений можно было бы сопровождать код комментариями, а не просто говорить: "Вот код. Хотите понять? Лезьте в интернет." Мне кажется, это в Ваших же интересах, если Вы действительно хотите привлечь людей к ФП. Тем более Вас никто не принуждает делать подробный обзор Лиспа, достаточно ограничиться краткими пояснениями.

Ответ на »сообщение 242« (hugi)
___________________________
Человеку хочется прежде получить общее представление о предмете, оценить, хотя бы приближённо, все плюсы и минусы, а уже потом с головой погружаться (или не погружаться) в углубленное изучение.

Вы меня извините, но там речь не шла об "общем представлении". Господин Qwerty задавал вопросы о синтаксисе.

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

Как можно обсуждать конкретный код с человеком который не может читать запись ?
Понятно там на уроке лиспа. Но здесь не школа для начинающих программистов.
Мы говорим об общих вещах, о принципах. Но когда речь доходит до иллюстраций, простите великодушно, но хотя бы прочитать одну (не десять!!) строчек, можно взять на себя труд ?
Ведь такое пренебрежение временем других (давай бухти мне про космические корабли, бороздящие большой театр) сильно обременяет тех кто пытается сделать эту ветку интересной.

Работа должна быть обоюдной.

Ответ на »сообщение 242« (hugi)
___________________________
Кстати, для желающих взять быстрый старт и понять, что же такое ФП, и что лежит в его основе (структуры данных и т.п.), настоятельно рекомендую ознакомиться: http://www.roman-dushkin.narod.ru/fp.html
Написано простым понятным языком, примеры... нет, не на Лиспе, на абстрактном ФЯ, похожем  на Хаскель. Трёх первых лекций (очень небольших, кстати) вполне хватит, чтобы войти в курс дела.

Ответ на »сообщение 240« (hugi)
___________________________
Напомню, что в чистых ФЯ, где нет понятия состояние, результат рекурсивных вызовов мы будем получать только про т.н. "обратном раскручивании".

Результат да, но не логику. Логика все также прямолинейна. Т.е. с точки зрения человека, описывающего процесс, разницы нет.

(Насыпать-в-чай число-ложек)
(если число-ложек больше нуля)
    (Сыпем-одну-ложку)
    (Насыпать-в-чай (на-одну-меньше число-ложек))

Однако такой подход не является по настоящему функциональным.
На самом деле правильнее было бы работать не с числом итераций, а с данными, то есть со списком.

(Насыпать-в-чай список-ложек)
(Сыпем (первая список-ложек)
(Насыпать-в-чай (остальные список-ложек))

Просто в ИЯ это делать настолько громоздко, что даже когда у вас есть список данных, вы все равно предпочитаете работать почему то не напрямую с ним, а опосредствованно, через число итераций, типа
i = 0 то list.Count - 1