Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2132 19-03-2007 11:34 | |
Ответ на »сообщение 2129« (Сергей Перовский)
___________________________
>>> Функция возвращает вам НОВЫЙ список шаров с новыми координатами.
Собственно функция меня и интересует :)
По ходу дела нужно определить моменты соударений, т.к. они меняют траектории шаров и ДАЛЬНЕЙШИЕ расчеты нужно вести по другому. Без явного введения в модель времени нам не обойтись. В императивном мире тут есть два подхода - тактовый и событийный. В функциональном нам придется использовать один из них, видимо предпочтительнее событийный.
А чем Вас тактовая модель не устраивает?
Ленивые списки, которые хранят в своих элементах состояние мира модели, приходящееся на некие такты этого самого модельного мира...
№ 2131 19-03-2007 10:12 | |
Ответ на »сообщение 2127« (Руслан Богатырев)
___________________________
Давайте попробуем разобрать модель ФП с позиций императивщика...
Напомнило отрывок из поэмы "Три дервиша" некоей Феаны .
Просьба помидорами не кидаться и на себя эту поэму не проецировать! :о))
*****
Итак, пошёл наш Як-баба искать дорогу.
Он раньше спрашивал: - Живёт ли здесь мудрец?
Теперь - страну для Дураков… Один отец
Спустя три месяца направил, дал подмогу.
И он нашёл свою страну для Дураков,
Где удивительные вещи происходят!
Но, как ни странно, солнце всходит и заходит,
И ночь темна, и светел день, и нет замков…
Вот он идет и… видит, женщина несёт
Дверь… на себе! И он спросил её об этом.
- Да, уходя, мой муж порадовал советом:
Не поздоровится тебе, коль кто войдёт
Вот в эту дверь! - и мне пора идти уж дальше.
- Я объясню тебе, как тяжесть не таскать.
- О, нет, не надо, мне пора уже бежать…
А то мой муж вернётся к дому часом раньше.
Идёт он грустный. Видит люди у дороги
Дрожат от страха, взгляд направлен на арбуз.
- Какое чудище! Спаси нас, бог Иисус!
Оно убьёт нас. Как же боги стали строги!
А дервиш Як им говорит: - Я объясню!
Толпа кричит в ответ: - Не будь же дураком!
Мы не желаем знать. Убей его тайком!
А он арбуз ножом разрезал и вкусил!
Крестьяне в ужасе: - Уйди, не возвращайся,
Чтоб не убил и нас как монстра тем ножом!
А Як-баба подумал: - Нужно дураком
Стать, как они, чтоб их понять, не обольщайся…
Так он учил их много лет и, наконец,
Достиг он Знания Великой Глубины…
И стал святым для обитателей страны,
Где называли все его “Наш Як - мудрец”!
И даже Книгу Бытия о нем создали,
Как о Великом Покорителе арбузов,
О просветлённом, разъяснившем тайну грузов.
И с той поры уж Книгу в школах изучали…
*****
№ 2130 19-03-2007 08:44 | |
Ответ на »сообщение 2119« (Geniepro)
___________________________
>>>Посмотрите на Функциональное Реактивное Программирование
То, что обработчики событий удобно писать в функциональном стиле мне объяснять не надо: сам стараюсь по возможности так делать.
Я пытаюсь донести простую мысль, что в сложных системах события возникают не только от взаимодействия с пользователем, но и от взаимодействия частей программы, как их не называй. К сожалению это сложно показать на простых примерах. В результате получаем интенсивный поток событий, обрабатываемых относительно простыми функциями. В такой конфигурации важнее, чтобы язык позволял наиболее простую работу с объектами и событиями, чем с функциями.
№ 2129 19-03-2007 08:10 | |
Ответ на »сообщение 2114« (Jack Of Shadows)
___________________________
>>>Функция возвращает вам НОВЫЙ список шаров с новыми координатами.
Собственно функция меня и интересует :)
По ходу дела нужно определить моменты соударений, т.к. они меняют траектории шаров и ДАЛЬНЕЙШИЕ расчеты нужно вести по другому. Без явного введения в модель времени нам не обойтись. В императивном мире тут есть два подхода - тактовый и событийный. В функциональном нам придется использовать один из них, видимо предпочтительнее событийный. Придется построить три функции: вычисление времени до ближайшего соударения, вычисление положения( и скорости) через заданное время при отсутствии соударений и вычисление изменений скорости при соударении.
И вызывать их придется последовательно, т.е. императивность будет возникать не только в моменты ударов - взаимодействие с пользователем, но и в моменты соударений - взаимодействие между объектами. Рекурсия в данном случае нисколько не упрощает алгоритм, а накладные расходы увеличивает.
№ 2128 19-03-2007 06:39 | |
Ответ на »сообщение 2118« (Geniepro)
___________________________
Ответ на »сообщение 2111« (Руслан Богатырев)
___________________________
Я не хочу использовать модули как объекты - для хранения какого-то изменяемого состояния.
Роль объектов должны играть объекты или временные переменные, явно передаваемые через параметры функциям.
Речь идет не о "каком-то изменяемом состоянии", а о выстраивании динамических связей между модулями. В ИП для этого можно применить, например, инсталлируемые объектные разъемы - на основе переменных модуля.
В ФП можно подумать о введении какого-либо рода декларативных слотов, по которым можно формировать динамические связи между модулями. И присваивания, и переменных не нужно. Однако все равно этот механизм является синхронным, то есть, изменяющим некоторое состояние во времени (какой модуль с каким связан).
В текущем варианте "модули" в ФП - это всего лишь пассивные пакеты, поддерживающие сокрытие информаци, не более. На большее они не способны.
№ 2127 19-03-2007 05:22 | |
Давайте попробуем разобрать модель ФП с позиций императивщика. Представим себе, что перед нами стоит задача реализовать run-time для какого-то ФЯ.
Итак есть функции без побочных эффектов. Т.е. это почти те же процедуры-функции, что и в случае ИП, только подчиняющиеся определенным ограничениям:
1. Функция имеет доступ к контексту вызова внешней функции -- инициатора вызова, причем только на чтение.
2. Функция не может изменять свои формальные параметры.
3. Функция возвращает результат в виде функции или атома/списка.
Создаваемые в результате работы сущности носят "одноразовый" характер. Как только произошла их конкретизация (из состояния UNDEFINED), другие значения приниматься не могут. Сущности заводятся в динамической куче с автоматической сборкой мусора. Подавляющее большинство сущностей носит временно-вспомогательный характер и уничтожается за ненадобностью.
Если функция (обычно унарная) уже вызывалась с конкретными параметрами, то ее значение может быть занесено в "мемоизированную" память (кэширование), чтобы потом не вычислять по новой. В ФП используется карринг (currying) -- сведение обработки функции от n-аргументов к конкатенации n-функций от одного аргумента. Кроме того, есть closure ("герметик") -- контекст вызываемой функции, который принадлежит инициатору вызова -- вызывающей функции. Функция может попользовать внешние данные как read-only. В ФП различают прямые и отложенные (ленивые) вычисления. Прямые требуют непосредственного вычисления, отложенные -- по мере надобности.
Для очищения ФП от "инопланетных" императивных вещей (обычно связанных с общением ФП с внешним миром) используется такое понятие, как монады (monads). Монады вбирают в себя сугубо последовательные вещи (напр., ввод-вывод), а также изменения в состояниях без использования языковых конструкций с побочными эффектами. Это "свободные экономические зоны" (если кому-то больше нравится -- "гетто"), имеющие жесткие границы (ограничения) с миром чистого ФП.
Ничего существенного не забыл?
№ 2126 19-03-2007 04:11 | |
Ответ на »сообщение 2124« (Max Belugin)
___________________________
>>>Логически продолжите эту мысль, и, думается, Вы придете к тому же подозрению, что возникло у меня: в ФП состояние "всплывает наверх".
Наверх, это куда?
Туда. (AVC машет рукой в неопределенном направлении.)
Это не совсем шутка.
Я действительно не знаю, куда функциональщики "прячут свое состояние" в чистом ФП.
Сначала я предположил, что состояние всплывает наверх и оседает где-то "на глобальном уровне".
Меня вежливо поправили (и здесь, и на RSDN), сказали что это не так.
Вместе с тем, если состояние программной системы меняется в результате вычислений (она "учится" :) ), то изменения должны где-то накапливаться.
Проблема?
№ 2125 19-03-2007 04:04 | |
Ответ на »сообщение 2118« (Geniepro)
___________________________
Если честно, то я просто не вижу каких-то проблем с модульностью в ФП.
Это меня и настораживает. Особенно в свете того, что если функция и класс -- законченные сущности (получилось двусмысленно, но не обижайтесь), то модуль -- это полуфабрикатный контейнер. Без вещей другого уровня (процедур, конструкторов типов) он как горшочек без меда. Разве что в руках покрутить. Модуль в модульном программировании -- это не только область видимости, но и область существования. Поскольку память в ФП весьма своеобразная и ей противопоказано иметь на борту модулей какие бы то ни было переменные, то тут не все так очевидно.
В ФП есть функция. В ИП тоже есть функция. Но это, мягко говоря, разные вещи (хотя и родственные), называемые одним словом. С модулем, похоже, ситуация обстоит аналогично.
№ 2124 19-03-2007 03:53 | |
Ответ на »сообщение 2123« (AVC)
___________________________
Логически продолжите эту мысль, и, думается, Вы придете к тому же подозрению, что возникло у меня: в ФП состояние "всплывает наверх".
Наверх, это куда?
№ 2123 19-03-2007 03:45 | |
Ответ на »сообщение 2122« (Max Belugin)
___________________________
>>>В чистом ФП нет не состояния а побочных эффектов. То есть состояние является всегдя явным аргументом и только той функции которой оно нужно и только состояние того куска мира, которая нужна функции. Насколько я понял.
Логически продолжите эту мысль, и, думается, Вы придете к тому же подозрению, что возникло у меня: в ФП состояние "всплывает наверх".
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|