Случайно прошел мимо интересной новости :)
Компьютерра, 24, 28 июня 2006:
"Разработчики Linux-дистрибутива Lin-spire/Freespire недавно объявили о переходе на функциональный язык Haskell для всех вспомогательных задач (где традиционно используются скриптовые языки типа Perl и bash) - сборки дистрибутивов, проверки зависимости пакетов и т. п. Это означает новый виток развития как дистрибутива, так и языка, а возможно, и прикладного программирования в целом".
Полный текст здесь:
http://offline.computerra.ru/2006/644/275299/

Скажу еще пару слов о близости к человеку :)
Конечно, рекурсия дальше от человека, чем просто повторение. Кто бы сомневался!
И алгебра дальше от человека, чем арифметика. А общая топология, наверно, еще дальше - ее даже некоторые математики не понимают :)))
Но рекурсия дает возможности человеку точно и ясно формулировать свои мысли.

Как "простой" человек может определить строку символов из алфавита 0..9? Как последовательность. А что значит "последовательность"? Ну, например, 000, 123, 123456789, и т.д. Понятно? Конечно, понятно. Но что-то здесь не так. В учебнике математики так не напишешь - такая форма скорее для учебника литературы.

Точное определение может "звучать" только так:
<Символ> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<Строка> ::= <Символ> | <Строка><Символ>

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

>>>Мне первое определение кажется проще. К тому же оно очень естественно
>>>записывется на хаскеле.
>>>factorial n = product [1..n]
>>>Но ведь в нем ни слова о повторении. А попробуйте-ка дать итеративное
>>>определение факториала.

Ничего удивительного!
Ведь умножение - это рекурсивная функция :)
Для целых неотрицательных чисел произведение двух чисел можно определить очень просто:
Произведение(X,0)=0
Произведение(X,Y)=X+Произведение(X,Y-1)
Строго говоря, сложение - это тоже рекурсивная функция.
И вообще, по Черчу-Тьюрингу, Бог дал нам только самые примитивные операции, типа "Сделай нулем", "Добавь 1" или "Выбери предмет номер X".
Все остальное, включая и 4 действия арифметики, человек получил сам.
С помощью рекурсии.
(или итерации :))))

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


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

Мне первое определение кажется проще. К тому же оно очень естественно записывется на хаскеле.

factorial n = product [1..n]

Но ведь в нем ни слова о повторении. А попробуйте-ка дать итеративное определение факториала.

>>>Читаем, как вы и советуете. И вот что вычитали :))

Ага.
А теперь медленно и по слогам - четыре слова в начале второго абзаца.
"... Несмотря на формальную правильность ..."

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

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

Однако и вам придется согласиться со мной что сложность кода при вложениях циклов возрастает непропорционально быстро.
Конечно возрастает. Для устранения этой сложности и применяется рефакторинг "Extract Method". А как сделать такие алгоритмы рекурсивно без выделения дополнительных функций?

Ответ на »сообщение 765« (Антон Григорьев)
___________________________
Кстати, а почему пока не было ни слова о доказательстве кода, которым якобы так сильны функциональные языки?

Ну не якобы а сильны :)) ML был создан как theorem prover
Если вам интересно, можно поднять и эту тему конечно.
Вопрос зачем это прикладникам ?

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

В смешанных языках типа лиспа или окамла отказываться от циклов в пользу рекурсии совершенно необязательно.
Удобнее писать итерацию вместо рекурсии - ради бога.

Но вот в чистых ФЯ - уж извините, итерация персона нон грата.
Если вас отпугивает перспектива жизни без циклов, то чистые ФЯ вам заказаны.
Ну а я пока пригляжусь к хаскелю повнимательнее :))

Ответ на »сообщение 762« (SJ)
___________________________

[QuoteСовет: читайте работы Э.Дейкстры (E.Dijkstra), точные ссылки сейчас не помню, но по контексту их в сети можно найти. Он замечательно дает семантический анализ фундаментальных понятий программирования. В частности показывает смысловую эквивалентность рекурсии и итерации.

Читаем, как вы и советуете. И вот что вычитали :))

"... семантику конструкции повторения можно описать с помощью рекуррентных отношений между предикатами, тогда как для описания семантики общей рекурсии требуются рекуррентные отношения между преобразователями предикатов. Отсюда совершенно очевидно, почему я считаю общую рекурсию на порядок более сложной конструкцией, чем простое повторение; и поэтому мне больно смотреть, как семантику конструкции повторения while B do S определяют как семантику обращения whiledo(B,S) к рекурсивной процедуре <...>.

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

Цитата взята с пятой страницы книги Дейкстры "Дисциплина программирования" http://www.osrc.info/files/downloads/decstra.pdf

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

Я не против рекурсии и часто и с удовольствием её использую (а утверждения Jack'а о том, что императивщики рекурсию пратически не используют, вызывает у меня сильное удивление). Но смотрите, что я вижу в этой ветке: по производительности рекурсивные алгоритмы в разы (а иногда и на порядки) медленнее итеративных. Кроме того, их нормальная работа требует дополнительных усилий от компилятора по оптимизации хвостовых вызовов, а то стек переполнится (это тоже, видимо, как-то сказывается на производительности). Эти алгоритмы нередко сложнее для понимания (что бы там ни утверждали сторонники ФЯ) и в реализации. Вопрос - а на фига оно надо? Зачем я должен усложнять себе жизнь, реализуя неудобные в простых случаях рекурсивные алгоритмы? Пока есть только один удовлетворительный ответ: возможность автоматического распараллеливания. Но цифрами это никто не подтвердил. А на потерю производительности предлагается просто забить - типа компьютеры мощные, всё равно посчитают за приемлемое время. Ну да, помню свой диплом - компьютер считал без остановки четыре месяца, и то не хватило данных. Потеря производительности даже вдвое для меня была бы абсолютно неприемлема.

Кстати, а почему пока не было ни слова о доказательстве кода, которым якобы так сильны функциональные языки?

Ответ на »сообщение 763« (Артем)
___________________________
А какой у вас опыт СЕРЬЕЗНОЙ работы на ФЯ?
Два года работы в конструкторском бюро на лиспе вас устраивает ?
Да и сейчас я опять вернулся к работе с лиспом. Вот уже практически полгода как мы купили Lispworks.

А у вас какой опыт ФЯ ?

Главное, что у меня совершенно нет желания изобразить тупым стадом талантливейших программистов, 

Blah, blah, blah. Об исторических причинах выхода на первый план ИЯ здесь уже много раз говорилось.
Повторяться не буду.

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

Ответ на »сообщение 757« (Jack Of Shadows)
___________________________
Меня переубеждать не надо. У меня за плечами более 17 лет профессионального программирования на ИЯ и на ООП.
Вот видите, на ИЯ и ООП. А какой у вас опыт СЕРЬЕЗНОЙ работы на ФЯ? – мы, кажется, уже об этом говорили (институт – не в счет, мы все там учили какой-нибудь ФЯ).


Это не меня, это вас с hugi надо убеждать, нет даже не принять ФП или отказаться от ООП. Всего лишь перестать гнать пустую демагогию, и перейти к практике. И уже постом, имея за плечами опыт ФП, ругать его.
Я уверен он не новичек в программировании, и наверняка прекрасно знает ООП.
Но он не позволяет себе судить о вещах о которых понятия не имеет. В отличие от вас и hugi, которые спорят здесь о ФП, не имея даже одного года опыта работы на функциональных языках.

Послушайте, если вы позволяете себе делать умозаключения о моем опыте работы, то я позволю себе сделать и свои.
Ваши утверждения об ущербности ООП и подавляющем превосходстве ФП относятся к тому же разряду утопий, как и мысли о технологической сингулярности. Это, извините, сплошной иллюзион.
Я, в свою очередь, интересуюсь декларативным программированием не для того, чтобы выбросить ООП на помойку, а для того, чтобы дополнить его новыми возможностями.
Главное, что у меня совершенно нет желания изобразить тупым стадом талантливейших программистов, вложивших свою душу в развитие ООП. То же относится и к программистам на ФЯ.
А что касается пустой демагогии, то этим периодически грешите вы, и спор  с вами часто напоминает диалог с глухим.  На сим я пока и удаляюсь. Развлекайтесь!  :)