Ответ на »сообщение 10« (Сергей Перовский)
___________________________
Насколько я понимаю, он состоит в том, чтобы принципиально отказатся от понятия состояния

Ошибаетесь. Вы говорите о чистых функциональных языках (Haskell, Clean) в которых исключен императивный подход. Но это не означает что функциональный и императивный подходы взаимно исключаемы.
Такие языки как лисп или оcaml полностью поддерживают как функциональную так и императивную и обьектную парадигму программирования.
Т.е. используя лисп вы не теряете ни присваивания ни циклов, ни состояния ни классов.
Это значит что для каждой задачи вы можете выбирать наиболее оптимальный подход.
По моему это наиболее правильный подход для прикладных задач.
Поэтому для меня неважно как будет называться язык, если он позволяет использовать все функциональные механизмы. Пусть даже этот язык сишарп от МС. :))
Это я к тому что сишарп быстренько так идет в сторону функционального программирования (смотрите версию 3)

Однако лисп - это отдельный разговор.
Лисп это макросы. А это уже не имеет никакого отношения к функциональному программировнаию. Это уже мета-программирование.

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

Например нужен ООП ? Не надо менять язык, как пришлось делать в Си, не надо создавать новые языки (Smalltalk, java) в лиспе классы сделаны в виде библиотеки (CLOS).
Но благодаря макросам, они используются как органическая часть языка, точно так же как в java или в дельфи.

Нужен АОП ? (аспектно-ориентированное программирование). Пожалста!
Никаких новых языков (AspectJ) не нужно годами ожидать пока какой нибудь комитет наконец то решится внедрить новую фияу в язык. Небольшая библиотека и мощный механизм аспектов в ваших руках.

list comprehensions ? Нет проблем, Generics ? Они даже не нужны если у вас есть макросы.
closures ? continuations ? Erlang style multi-processing ? Все что вашей душе угодно!

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

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

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

Я уже говорил что у функциональных языков есть недостаток, они очень далеки от машины, что не дает возможности использовать их на слабых машинах <...> Практически во всех таких задачах ФЯ гораздо лучше. Быстрее, легче в разработке, позволяют охватить и решить гораздо более сложные проблемы.

На мой взгляд, Вы несколько упрощаете ситуацию.

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

Нынешнее возрождение интереса к функциональным языкам напоминает эру конца 1970-х годов, грандиозного японского проекта ЭВМ 5-го поколения и языка Пролог как основы всего и вся. Очень люблю язык Пролог, реализовывал для него компилятор на основе Warren Abstract Machine для комплекса Modula-2/Prolog/Lisp, но, как говорил небезызвестный Портос, скептически разглядывавший курицу, которую ему предложили на обед, "уважаю старость, но не в вареном и не в жареном виде".

Главная проблема функциональных языков -- они далеки от человека. От нормального программиста. Быть может, находятся от него даже дальше, чем от машины. Они непросты в восприятии. И требуют в определенной степени виртуозности абстрактного мышления. Систему надо не только уметь быстро создать. Надо еще уметь контролировать ее сложность. Уметь развивать систему, отчужденную от ее создателей.

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

Ответ на »сообщение 8« (Jack Of Shadows)
___________________________
Прошу прощения, я видимо неточно сформулировал.
Я не про состояние дел и конкретный инструмент, я про идеологию.
Давайте говорить не о функциональном языке, а о функциональном подходе.
Насколько я понимаю, он состоит в том, чтобы принципиально отказатся от понятия состояния (тем самым исчезает необходимость в переменных, это состояние хранящих). Для решения большого количества математических задач и задач обработки текстов может быть очень эффективным.
Но если моя задача описывается наиболее адекватно, например, в понятиях теории конечных автоматов, где понятие состояния является базовым, боюсь функциональный подход породит массу проблем.
Вот я и хочу нащупать водораздел. Какие математические теории хорошо отображаются в функциональное программирования, а какие будут упираться.

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

Прошу прощения за отсутствие ссылок. Ща че нибудь набросаем для начала.

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

1. Курсы на Intuit.Ru
Это курсы весьма авторитетных экспертов в данной области, преподающих в наших ведущих вузах:

1.1. http://www.intuit.ru/lector/40.html
Основы функционального программирования.
Л.В.Городняя (НГУ, ИСИ СО РАН им. Ершова)

1.2. http://www.intuit.ru/department/se/tppfunc/
Введение в теорию программирования. Функциональный подход
С.В.Зыков (МИФИ, Microsoft Research)

1.3. http://www.intuit.ru/department/se/progstyles/
Стили и методы программирования
Н.Н.Непейвода (Удмуртский ГУ)


2. Сайт Softcraft.ru -- неповерхностное обсуждение проблем программирования

2.1. http://www.softcraft.ru/paradigm.shtml
Функциональное программирование
Функционально-потоковое параллельное программирование

2.2. http://www.softcraft.ru/forum/viewforum.php?f=2&sid=bcce57581c236fd50e3debcc16a07c26
Форумы по вопросам функционального программирования


Тем, кто читает по-английски, вполне можно начинать и с Wikipedia-статьи по Лиспу (но не в русской версии Wikipedia) -- http://en.wikipedia.org/wiki/Lisp_programming_language
и с Wikipedia-статьи по функциональному программированию -- http://en.wikipedia.org/wiki/Functional_programming

Ответ на »сообщение 2« (Сергей Перовский)
___________________________
для каких областей функциональные языки не годятся и почему.

Нельзя говорить ни о функциональных ни о императивных языках что они годятся или не годятся для каих то областей. Есть специальные языки, заточенные для определенной работы (помните 4GL языки типа Clipper, Foxpro) и есть языки общего назначения (паскаль, дельфи, java, lisp, ocaml, haskell)

Я уже говорил что у функциональных языков есть недостаток, они очень далеки от машины, что не дает возможности использовать их на слабых машинах. Но если взять достаточно сильную машину. Т.е. любой современный писюк с процессором в 2 Гигагерца и более и памятью 1 Гб и более, то нет никакой высокоуровневой задачи (т.е. задачи не связанной напрямую с управлением железом) в которой императивные языки были бы лучше функциональных. Наоборот. Практически во всех таких задачах ФЯ гораздо лучше. Быстрее, легче в разработке, позволяют охватить и решить гораздо более сложные проблемы.

Есть еще один недостаток ФЯ, который временно может может перетянуть чашу весов в сторону популярных языков. Отсутствие наработанных библиотек. Например для создания GUI под windows? ничто не сравнится с дельфи или VS. Поэтому если стоит такая задача то лучше выбрать их.
А вот если речь идет о GUI под Линукс, то уже ситуация равная. На лиспе можно пользоваться теми же GUI библиотеками что и на Си или java. Т.е. GTK, Tk/Tl, Motif и так далее.
Если например надо сделать кроссплатформенную GUI чтобы работала и на windows и на линукс и на MacOS? то скажем у лиспа уже преимущество перед ktmab или dotnet.

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

А выход многояерных процессоров только подстегнет это движение. О чем чуть позже. :))

Ответ на »сообщение 1« (AVC)
___________________________
В каком смысле функциональные языки "близки человеку"?

1. Функциональные языки не имеют типов, заточенных для экономии байтов или ускорения работы.
Человек не должен думать сколько места занимает информация в компьютере и сколько тактов требуется компьютеру чтобы ее обработать. Ближе к человеку - дальше от машины.

2. Чистые Функциональные языки (Haskell, Clean) не имеют присваивания. Человек не думает в терминах ячеек машинной памяти. х := 5 не означает "Возьми число 5 и засунь ее в область памяти, к которой я буду иметь доступ через название x".
Кстати поспрашивайте учителей программирования. Эта одна из дтрудных для понимания тем, которую им приходится преодолевать. Она слишком машинная, неестественная для человека.

3. Функциональные языки основанны на математической модели lambda calculus (Alonso Church). Т.е. для человека, знакомого с математикой, хотя бы на уровне алгебры, ФЯ гораздо понятнее, ближе, чем императивные языки, основанные на модели машины тьюринга.
Кстати раз уж я упомянул обоиз, вот вам интересный факт.

Примерно в то же время когда Алонзо Черч написал свои работы по lambda calculus, Алан Тьюринг независимо от него написал свою работу по машине Тьюринга. Научное сообщество быстро выяснило что обе работы эквивалентно описывают работу компьютера. И Тьюринг приехал в Принстон чтобы обучаться там у Алонзо Черч в 1936 - 1938.

4. Функциональные языки очень легко могут распараллеливаться без участия человека. В то время как в императивных языках, человек должен явно создавать и регулировать распределенные процессы. Задача неимоверно трудная для человека.

Можно еще много чего сказать на эту тему. Я думаю другие любители и знатоки ФЯ добавят и свои мысли.

Ответ на »сообщение 4« (Как слышно? Прием!)
___________________________
Прошу прощения за отсутствие ссылок. Ща че нибудь набросаем для начала.

Хорошая бесплатная среда разработки языка shceme для windows: http://www.drscheme.org/
Еще одна бесплатная среда (Common Lisp) для windows: http://www.gigamonkeys.com/lispbox/

Отличная книга для обучению программированию на scheme: http://www.htdp.org/
Книга Practical Common Lisp: http://www.gigamonkeys.com/book/

Если нужны какие нибудь конкретные билиотеки (web разработка, XML, базы данных, графика, GUI, opengl) спрашивайте. Все это в наличии, как для lisp так и для scheme.

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

http://lambda-the-ultimate.org/


и вот тут несколько ссылок
http://npj.ru/belugin/funkcionalnoe_programmirovanie

PS. а вообще можно вики завести

Уважаемый Jack!
Вы всегда славились дельными ссылками,
но при организации своей темы что-то расслабились.
Что надо почитать по теме, чтобы врубиться?
Желательно по-русски и подоходчивее.
Лично я перепутал сначала Лисп с Лого, увы мне.
Ясно, что надо бы погуглить, но лучше за ручку.
Скачать что - фри или триал поменьше для пробы.

Функциональные языки слишком близки к человеку и слишком далеки от машины.
К какому человеку?
Сдается мне, что конструкция =СУММЕСЛИ(F5:F64;"=1";$C5:$C64) в Excel ничуть не проще для понимания, чем цикл с условием. По крайней мере для того, кто умеет производить такие вычисления на листе бумаги.