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

Язык не способствует такому стилю.

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

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

А в обероне или паскале или java. Много вы видели функций которые принимают другие функции в качестве параметров или возвращают их в качестве результата ?

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

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

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

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

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

Не только потому, что трудно. А потому, что есть много другого гибридного, похожего на Си, где это удобнее: те же C++, Java, C#.

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

скажем вот кусок кода из моей программы:

(with-db-connection (sirusdb *connection-string*)
    (dolist (row (sql:query (format nil "select wo, dist_locat_id, ord_custcode, bill_custcode
                                          from work_BillingQueue
                                          where userid = ~a order by 1" user-id)
                            :database sirusdb))
      (assert ((make-instance 'dist-locat :wo (first row)
                    :dist-locat-id (second row)
                    :ord-cust-code (third row)
                    :bill-cust-code (fourth row))))))

Как видите with-db-connection написанный мною же, принимает 2 параметра. Это обьект соединения с БД. И кусок кода, просто кусок кода переданный внутрь.
Это настолько легко делать в лиспе. что это делают ВСЕ, ПОВСЕМЕСТНО.
Во всех библиотеках вы найдете одгромное количество функций которые принимаю друго=ие функции или фозвращают их как результат.

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

Ответ на »сообщение 53« (Jack Of Shadows)
___________________________
>>> Я думаю Geo искал что то более практичное и приземленное нежели ваше обьяснение.
Ну почему же, сообщение от AK тоже достаточно понятное. Особенно интересно было узнать еще и про декларативную парадигму (у меня к этому свой интерес).

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

В общем, если я правильно понял предмет, то функциональное программирование и императивное программирование по большому счету конкурентами не являются: задачи есть и для того, и для другого. Хотя есть, конечно, и некоторая область пересечения "сфер интересов".

Ответ на »сообщение 57« (Руслан Богатырев)
___________________________
Провокационный вопрос. Вообразим на минутку, что в Обероне мы пишем так, что модули имеют и экспортируют исключительно процедуры-функции,

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

А в обероне или паскале или java. Много вы видели функций которые принимают другие функции в качестве параметров или возвращают их в качестве результата ?
При этом возможность есть. Но это настолько трудно сделаноЮ что народ просто скатывается к ООП как к поощряемой языком парадигме. Писать в функциональном стиле в императивных языках это все равно что плыть против течения. Можно но трудно. Потому никто этого и не делает.

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

Ответ на »сообщение 55« (Руслан Богатырев)
___________________________
Что Вы могли бы предложить Delphi-программистам, которые хотят оставаться в рамках своего любимого языка и попробовать на зуб эту диковинку под названием "функциональное программирование"?

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

Но тем не менее посоветовать можно конечно. Только не в рамках дельфи.
В конце концов вы уже мало найдете народу который только дельфи и знает (использует)
Практически все посетители форума в какой то мере полиглоты в программировании.

Посоветовать можно скажем веб программирование. Лисп является весьма практичным инструментом, не уступающим java или asp в этой области.
Вот несколько библиотек (frameworks) для веб разработки:

KPAX: http://homepage.mac.com/svc/kpax/index.html
UCW: http://common-lisp.net/project/ucw/
TBNL: http://www.weitz.de/tbnl/
CL-WHO: http://weitz.de/cl-who/
HTML-TEMPLATE: http://weitz.de/html-template/
Aserve: http://portableaserve.sourceforge.net/

Лично я пользуюсь web сервером aserve с встроенным framework webactions
Webactions что то типа jsp + servlets. Т.е. html файлы с вкраплениями лисп кода с расширением .clp и код сервлетов который может либо конструировать html при помощи таких библиотек как htmlgen или CL-WHO либо передавать управление темплейтам .clp

Кстати работа с html и xml гораздо более естественная в лиспе чем в других языках. Потому что xml это те же s-expressions (формат записи кода в лиспе)

Вот например кусок html написанный прямо на лиспе:

(:html
        (:head (:title "Test Table"))
        (:body
          (:table
            (:tr (:td "0") (:td "0"))
            (:tr (:td "1") (:td "1"))
            (:tr (:td "2") (:td "4"))
            (:tr (:td "3") (:td "9"))
            (:tr (:td "4") (:td "16"))
            (:tr (:td "5") (:td "25"))))))))

Генерирует html. То же самое и для xml

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

Т.е. в функциональном программировании отсутствует состояние (state) Функция получающая одни и те же аргументы всегда возвращает один и тот же результат. Отсутствуют побочные эффекты (side effects). Т.е. функция помимо возвращаемого результата не изменяет состояние системы никоим образом. Это основное отличие функционального программирования от императивного.

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

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

(print "Hello World")
Классно правда ? Одна строчка, понятная даже ребенку.


А знаете, как это будет выглядеть на языке APL? Да-да, том самом, что был создан Кеннетом Айверсоном в 1957 г.

'HELLO WORLD'

Еще более классно! Все, забываем теперь про functional programming, переключаемся на array programming. :o)

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

Речь идет о таких вещах, как количество книг, изданных в последнее время

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

При этом нет ни одной (!!!) программы на обероне.

Это Вас не красит. :o) И даже говорит о плохом вкусе. :o) Но давайте все же поменьше про Оберон и побольше про функциональное программирование.

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

Ответ на »сообщение 53« (Jack Of Shadows)
___________________________
Ну вот я так и знал что что то да позабуду.
Сборщик мусроа конечно же яляется необходимым механизмом в любом ФЯ.

Ответ на »сообщение 52« (AK)
___________________________
Я думаю Geo искал что то более практичное и приземленное нежели ваше обьяснение.
Функциональное программирование это парадигма в которой вычисления представляют собой результат работы функций, которые зависят только от принимаемых параметров. Это в противовес императивному программированию в котором вычисления подразумевают изменение состояния системы (state machines) путем последовательного исполнения команд.

Т.е. в функциональном программировании отсутствует состояние (state) Функция получающая одни и те же аргументы всегда возвращает один и тот же результат. Отсутствуют побочные эффекты (side effects). Т.е. функция помимо возвращаемого результата не изменяет состояние системы никоим образом.

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

Кроме того функциональное программирование характеризуется еще набором свойств, которые принято считать неотьемлимой частью ФП.
Вот этот список (я могу кое чего и упустить)

1. Higher Order functions (функции являются данными которые можно передавать в другие функции и получать из них в качестве результата)

2. closures (анонимные функции, которые "захватывают" с собой данные, видимые на момент их создания. Потому и называются closures то, есть закрывающие, обволакивающие собой видимые им данные)
Напомните мне я вам приведу пример того что такое closures. Это очень интересная конструкция.

3. Рекурсия

4 Laziness (отложенность вычислений) Необязательно. Существуют ФЯ этого не поддерживающие например семейство МЛ

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

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

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

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

Сравните например:

Декларативный (функциональный) подход.
1. Небо темно-синее.
2. На Небе звезды
3. Звезды блестят серебрянным светом.

Императивный подход:
1. Покрасить небо в темно синий цвет
2. Вывесить на небо звезды.
3. Покрасить звезды в серебрянный цвет.

В функциональном подходе нет состояния. Вы можете поменять местами любую из строчек - смысл не поменяется, система не поломается.

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

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

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