>>>Человек не думает в терминах ячеек машинной памяти. х := 5 не
>>>означает "Возьми число 5 и засунь ее в область памяти, к которой я
>>>буду иметь доступ через название x".

Если Вы не хотите мыслить в терминах ячеек памяти, то и не надо. В математике, кроме ламбда-исчисления Черча есть и другие базовые понятия, например, понятие продукции (подстановки), которое, собственно, и является математическим эквивалентом операции присваивания. x:=5 означает, что в дальнейшем контексте всюду, где символ x встречается в составе выражения вместо x надо подставить 5. Например, y := x + 1 надо заменить на y := 5 + 1. Это не сложнее, чем ЛИСП и никаких ссылок на физическое понятие "ячейки" - такая же чистая математика.

А теперь по существу.
Ничего нового в функциональных языках, конечно, нет. Они, как и императивные, выросли из идей 30-х годов, когда математики пытались формализовать понятие вычислимости и алгоритма. В результате появились разные формальные модели.
Наиболее известными стали:
1) Машина Тьюринга и машина Поста
2) Теория рекурсивных функций и ламбда-исчисление Черча
3) Нормальные алгоритмы Маркова (кстати, именно в этой модели ключевым понятием является понятие подстановки (замены))
Фундаментальный результат, к которому пришли математики оказался вполне ожидаемым: все известные формальные модели алгоритмических систем являются эквивалентными - отличаются только по форме.
Это значит. что любую рекурсивную или частично-рекурсивную функцию можно вычислить с помощью программы машины Тьюринга или Поста или с помощью нормального алгоритма Маркова - и, наоборот: все, что вычислимо на машине Тьюринга можно вычислить по методу Черча, - и т.п., и т.д.
Фактически - это означает, что долгая жизнь уготована и императивному, и функциональному подходу - ведь они эквивалентны по своему содержанию. А что касается формы, то здесь на вкус и цвет, сами знаете что. Для одной задачи или для одного программиста удобнее и понятнее одно, для другого - другое. Ведь сами математики до сих пор не могут выбрать среди этих моделей "самую лучшую" - изучают все основные (см. выше).
И последнее, к вопросу о легкости понимания.
Не будем преувеличивать - все зависит от уровня начального образования. Если речь идет о школьнике, то я не уверен, что подход Черча будет ему понятнее, чем подход Тьюринга. Впрочем, готов провести эксперимент. Сажаем в две разные комнаты двух учеников и предлагаем две задачи на вычисление простой функции, например, площади треугольника по формуле Герона. Один пишет процедуру по "старым" канонам, с помощью присваивания. Другой, то же самое на Лиспе. Потом будет интересно сравнить.

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

Ну а что же Вы про Standard ML, столь чтимый в Microsoft Research, запамятовали? http://www.cl.cam.ac.uk/Research/TSG/SMLNET/

А также про реализацию Moscow ML Сергея Романенко из Института прикладной математики им.Келдыша? http://www.dina.kvl.dk/~sestoft/mosml.html

Кто такой Сергей Романенко, можно понять из этих ссылок:

1. http://www.refal.net/romanenko/TheHistoryOfRefalCompiler/index.htm
2. http://www.svoboda.org/programs/sc/2001/sc.040301.asp

Или нет пророка в своем Отечестве? Надо больше по заграницам?

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

Простите совершенно непонятная ремарка. Вы хотели привести пример задачи которую невозможно или трудно решить на функциональных языках ?

Странно Ваше непонимание. Я предполагал, что помимо Лиспа Вы знаете Delphi и/или Оберон и знакомы хотя бы в принципе с конечными автоматами или сетями Петри. Так сравните для себя разницу в реализациях. Речь не о том, можно или нет, а о том, как это выглядит.

Не вижу никакой ужасно сложной и непонятной интеллектуальной эквилибристики.

А вот эти рассуждения уже начинают отдавать агитпропом. Тем более, что "ужасно сложной и непонятной" -- Ваши слова.

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

Скажите, если есть "кульная визуальная среда с рюшечками и компонентами", сколь существенна разница в том, каков целевой язык?

Нашел великолепную подборку высказываний специалистов по поводу распараллеливания программ:

Тиб Брей: "Не влезай - убьет!" http://www.tbray.org/ongoing/When/200x/2004/12/13/Multicore

"But the bottom line is, for application programmers, don't get into this space unless you're pretty sure you know what you're doing and you're willing to wrestle with some seriously difficult debugging."

Уильям де Хора: http://www.dehora.net/journal/2005/12/difficult_v_hard_as_opposed_to_java_v_c.html

"Distributed programming is hard (and with it comes the truly hard matters of cache invalidation and naming)."

Herb Sutter and James Larus: http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=332

"But concurrency is hard. Not only are today's languages and tools inadequate to transform applications into parallel programs, but also it is difficult to find parallelism in mainstream applications, and-worst of all-concurrency requires programmers to think in a way humans find difficult."

И оттуда же в унисон моим страшилкам о новом будущем:

"Concurrency has long been touted as the "next big thing" and "the way of the future," but for the past 30 years, mainstream software development has been able to ignore it. Our parallel future has finally arrived: new machines will be parallel machines, and this will require major changes in the way we develop software."

Повышение интереса с ФП совпало по времени не только с появлением достаточно мощных компьютеров.
Так уж получилось что в это же время мы уткнулись в предел развития процессоров по пути наращивания их быстродействия.
Предел тепловой. Дальнейшее наращивание мощности процессора без переходя на новый материал или принципиально новый процесс невозможен.
Вот тут то оба производителя процессоров - Интел и АМД принимают решение которое в корне изменит подход к программированию во всей индустрии. Они переходят на многоядерные процессоры. Т.е. речь идет о многопроцессорных системах, сделанных в одном чипе.
Уже сейчас можно за 100 баксов с небольшим, купить 2-х ядерный Пентиум. АМД-шные 2-х ядерные Опретоны стоят дороже, но тоже вполне доступно - $300
Причем это не какая то там боковая линейка продуктов. Это самое что ни на есть основное напрваление.
Т.е. оба производителя уходят от однопроцессорных систем. Однопроцессорные системы уходят в прошлое в историю. А в ближайших планах (4-5 лет) уже 4-ч ядерные процессоры.

Ура скажете вы. Значит компьютеры станут еще мощнее, еще быстрее...и ошибетесь.
Компьютеры конечно станут, но вот существующие программы необязательно.
Дело в том что в двух-ядерном пентиуме, каждое ядро работает на тактовой частоте гораздо меньшей чем скажем одноядерный 2.5 Гигагерц процессор (проблемы отвода тепла)

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

Именно с этим сейчас и сталкиваются пользователи. Подавляющее большинство программ просто не распараллеливается !!! Занимает одно ядро и баста.

В чем дело ? Разве на императивных языках нельзя писать распараллеленные, многопоточные  (multithread) программы ?
Можно конечно. Но написание многопоточных программ на императивных языках, дело невероятно трудное.
Как только программист пытается писать многопоточные программы он сталкивается с десятками трудных технических проблем.
Deadlock, starvation, race condition, mutual exclusion, syncronization, semaphores, scheduling - кошмар просто.
А ведь заняться этим придется. Особенно дельфистам, у которых в 99% случаев программа работает в том же потоке что и windows GUI интерфейс. Т.е. там же где все эти формы и компоненты :))) Т.е. для многоядкрных процессоров придется писать программы таким образом чтобы GUI в отдельном треде отрабатывала а логика программы - в отдельном (отдельных). Иначе безнадежно отстанешь от конкурентов. В разы !!!
А через несколько лет подтянутся 4-х ядерные процессоры. Уууу, сливай воду. Грамотно распараллеленная программа на таких процессорах не оставит конкурентам просто никаких шансов.

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

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

Еще пара ссылок для желающих попробовать.

http://www.lsharp.org/ - лисп на dotnet. Предупреждаю, не поддерживает стандарты Common Lisp и Scheme.

http://research.microsoft.com/fsharp/fsharp.aspx - F# диалект ocaml на dotnet.
Разрабатывается в MS.

Ответ на »сообщение 15« (Руслан Богатырев)
___________________________
Понимаете, кому надо было, писали на Лиспе и 10, и 20, и 30 лет назад.
Об этом я упоминал (ИИ)
У меня на это отличный от вашего взгляд. Писали не кому надо на лиспе а кто мог на лиспе.
Т.е. мог благодаря доступу к железу. Т.е. research проекты, или большие финансовые организации (банки, кредитные системы). Так например все до единого кредитные системы (VISA etc) или большие банки с миллионами клиентов, испольуют базы знаний (rule engines) Написать такие базы знаний на чем либо кроме лиспа на сегодняшний день (да и 20-30 лет назад) нереально.
Ну а поскольку без этого никак, то затраты на железо побоку.
Ну а на писюке с 640 килобайтами памяти, побойтесь бога, какой лисп !! :)))

Простая задача -- моделирование дискретных систем средствами таких формализмов, как конечные автоматы или сети Петри. Посмотрите, напр., как это будет выглядеть на Delphi/Обероне и на том же Лиспе.

Простите совершенно непонятная ремарка.
Вы хотели привести пример задачи которую невозможно или трудно решить на функциональных языках ?
Ну что ж вот вам Petri nets на хаскеле http://www.cs.kent.ac.uk/people/staff/cr3/HCPN/
А вот и на лиспе: http://www.informatik.uni-hamburg.de/TGI/pnbib/n/nolan_p_j1.html
http://www.cl-user.net/asp/libs/petri2

Может быть вы хотели привести пример красивого кода на дельфи, обероне ? В таком случае вы забыли привести ссылку.


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

Инструмент должен не просто соответствовать задаче. Задаче должна соответствовать связка "программист-инструмент-обстановка".

Я уже говорил о том что лисп прекрасно поддерживает императивный и ООП подходы. Так что эквилибристика в виде макросов или ckosures, continuations, higher order functions - только для желающих.

Для примера могу показать вам на Allegro CL - коммерческую лисп среду www.franz.com
Она внешне выглядит также как и дельфи, т.е. палитра компонент поверху, сбоку окошко свойств, в центре форма на которую бросаются компоненты. Не вижу никакой ужасно сложной и непонятной интеллектуальной эквилибристики. Наоборот, язык который одинаково хорош как для компонентокидателей и простых как утюг крестьян от процедурного кодинга, так и для прогаммистского дворянства. :)))

Достаточно чтобы какой нибудь из денежных мешков типа MS, Sun, IBM, Borland сообразил куда ветер дует и посадил свою когорту программистов за написание кульной визуальной среды с рюшечками и компонентами для лисп, и репутация лиспа  как высоколобого и трудного для понимания языка для интеллектуальных эквилибристов испарится как дым.

Проблема как видите надуманна.

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

Выход железа на приличный уровень, это не просто одна из причин. Это открывающий краник, без которого вода не потечет :)))

Понимаете, кому надо было, писали на Лиспе и 10, и 20, и 30 лет назад. Да и на том же Рефале В.Ф.Турчина. Кстати, не забудьте и про этот язык. Очень полезная вещь.

Писали не всё подряд, но не всё подряд и нужно. Конечно, сейчас стало заметно полегче с производительностью, кто спорит. И всё же -- не это главная причина, на мой взгляд, внимания к функциональному программированию.

Про некоторые недостатки (повышенные требования к железу, отставание в наработанных библиотеках) я уже говорил. Было бы очень интересно услышать какие еще вы имеете в виду.
Если можно на конкретных примерах.

Простая задача -- моделирование дискретных систем средствами таких формализмов, как конечные автоматы или сети Петри. Посмотрите, напр., как это будет выглядеть на Delphi/Обероне и на том же Лиспе.

Это вы совершенно точно подметили. :))) нормального программиста :))) Шикарная оговорка.

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

Инструмент должен не просто соответствовать задаче. Задаче должна соответствовать связка "программист-инструмент-обстановка". Если кто-то прекрасно владеет каким-то инструментом, не особенно и подходящим для данного класса задач, то при благоприятной обстановке (ограничениях/требованиях проекта) он способен добиться лучших результатов в сравнении с тем, кто пользуется вроде бы адекватным инструментом, но плохо им владеет или не очень-то умеет сопрягать его с конкретной обстановкой.

Ответ на »сообщение 11« (Руслан Богатырев)
___________________________
Кстати великолепный пример того что что вы Руслан неправы по поводу того какой подход далек от простого человека - это Эксель (Excel)
Огромное количество народу которое и десяти строк на бейсике написать не сможет тем не менее умудряются делать очень сложные excel-документы с множественными связями, зачастую между разными файлами.
Сложность такой вот конструкции намного превышает сложность написания небольшой процедурной программки, которую они написать не в состоянии.

Для тех кто не в курсе- Эксель ячейки эксель - это частный случай функционаьного программирования (его называют декларативным программированием)

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

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

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

Это вы совершенно точно подметили. :))) нормального программиста :))) Шикарная оговорка.
Вы абсолютно правы. Если взять "нормального программиста". Т.е. выучившегося в императивной школе, и имеющего 20 летний стаж, который вытатуировал такой вод подход у него в мозгах, то да, для такого человека функциональное программирование очень тяжко дается.

Однако для новичка в программировании что тот что этот подход - все одинаково.
Ну а то что обучение велось в подавляющем большинстве случаев на императивных языках, так ведь индустрия пошла по этому пути, погоняемая недостаточностью железа. А индустрия тянет за собой образование, как бы вам не хотелось поменять ситуацию. Лисп, МЛ надолго удалились в высшие учебные заведения типа МИТ, Stanford, Berkley. В основном как инструмент исследований в области ИИ (AI Artificial intelligence)

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

А для этого надо разобраться в его недостатках.
Про некоторые недостатки (повышенные требования к железу, отставание в наработанных библиотеках) я уже говорил. Было бы очень интересно услышать какие еще вы имеете в виду.
Если можно на конкретных примерах.