>>>Так что от вашего желания не мыслить в терминах ячеек памяти ничего
>>>не зваисит. Императивные языки заставляют вас это делать.

Может где-то и заставляют, но не в этом случае.
Причем тут какие-то ячейки и какая-то память? Мы говорим об императивных языках высокого уровня, а не об ассемблерах.
Запись присваивания вида <имя> := <выражение>
означает, что значение выражения <выражение> вычисляется и переменная с именем <имя> получает это значение. И все. И если Вы при этом хотите говорить о каких-то ячейках, то это уже Ваше личное желание отразить, что именно скрывается за этим с точки зрения реализации.
Кстати, человек, который сразу начинает программировать на языке высокого уровня, именно так и понимает оператор присваивания - как присваивание переменной нового значения. А об ячейках памяти он может в этом случае вообще не думать.

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

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

Есть такое дело. :))) Вы в ветках про обероны несете что то про light java :))) А я здесь в меру своих сил, тяну одеяло на сторону лиспа.

Java Light -- это, на мой взгляд, полезное восприятие неизвестного (Оберона) через известное (Java). Людям нужны маяки-ориентиры. Без них им трудновато. Хотя, конечно, определенное отношение к пропаганде это имеет.

Вот если бы Вы предложили воспринимать Лисп как Simple C++ или Difficult Basic, агитпропом не назвал бы.

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


А вот тут вы не правы. Понятие продукции не означает "выполни операцию и сохрани результат в этой ячейке"
Оно означает "замени эту операцию на вот эту" т.е.
y := 5 + 1 не будет означать "прибавь 1 к 5 и запомни что это 6"
Это будет означать "замени везде Y на (5 + 1)"

И это кстати именно как работает скажем в таком языке как Хаскель.
В нем конструкция типа y = 5 + 1 не будет выполнена пока y не понадобится где то еще.

Это например позволяет писать не заботясь о последовательности.
т.е.
z = x + y
y = 5 + 1
x = 4 * 2

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

Так что от вашего желания не мыслить в терминах ячеек памяти ничего не зваисит. Императивные языки заставляют вас это делать.

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

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

Ответ на »сообщение 20« (Руслан Богатырев)
___________________________
А вот эти рассуждения уже начинают отдавать агитпропом.
Есть такое дело. :))) Вы в ветках про обероны несете что то про light java :)))
А я здесь в меру своих сил, тяну одеяло на сторону лиспа.

Так сравните для себя разницу в реализациях. Речь не о том, можно или нет, а о том, как это выглядит.

Спасибо мне уже не надо. :)) Да кстати я для той же цели вам привел примеры реализации сетей Петри на лиспе и хаскеле. Сравнивайте, раз уж вы затронули эту тему.


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

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

Ответ на »сообщение 21« (Руслан Богатырев)
___________________________
Я не запамятовал. Реализаций МЛ десятки. Я просто не знаю про все.
Поскольку эта ветка в общем о функциональных языках то я только рад любой информации о них.

>>>Человек не думает в терминах ячеек машинной памяти. х := 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-х ядерные процессоры. Уууу, сливай воду. Грамотно распараллеленная программа на таких процессорах не оставит конкурентам просто никаких шансов.

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

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