Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге?
Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге?
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге? rfq>Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Тут есть разные точки зрения. Я считаю, что функциональное программирование это когда функция является объектом первого порядка (т.е. может сохраняться в переменную, передаваться в другую функцию в качестве аргумента). И это всё. На примитивном уровне даже в C поддерживается функциональное программирование (см. функцию qsort). Конечно для вящего удобства желательны не просто функции, а хотя бы вложенные функции с доступом к стеку родителя, а ещё лучше вложенные функции, захватывающие переменные и продлевающие их жизнь.
Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП) и никаких ограничений тут нет, сплошные возможности. И они частенько помогают.
Есть точка зрения, что ФП это иммутабельность как минимум, а порой и ленивость. Но я считаю, что это ортогональные понятия. Можно и иперативную программу писать с иммутабельными переменными и рекурсиями.
Иммутабельность это штука не всегда полезная. У неё есть плюсы, есть и минусы. Минусы естественно в производительности (хотя порой они от незнания, а не обусловлены объективно). Плюсы в том, что о программе проще рассуждать со всеми вытекающими. Параллельность да и в принципе удобно, когда 100% знаешь, что твой объект без всяких клонирований никто не тронет где-нибудь в коллбэке. Но всё равно я против поголовной иммутабельности. Мутабельности должно быть место и достаточно важное.
Насчёт ленивости у меня мнения чёткого нет, где-то она удобна (функциональные операции над бесконечными последовательностями), где-то не очень.
Здравствуйте, rfq, Вы писали:
D>>Любишь глобальные переменные?
rfq>Не люблю. Если можно, обхожусь без них. Но если я не использую глобальные переменные, могу я сказать, что программирую в функциональном стиле?
Нет. Я имел в виду другое:
rfq>Какой смысл программировать в условиях искусственных ограничений?
Кому-то и запрет глобальных переменных — тоже искусственные ограничения и скакание на одной ноге.
Здравствуйте, neFormal, Вы писали:
rfq>>Какой смысл программировать в условиях искусственных ограничений?
F>меньше шансов облажаться с изменением состояния.
+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!
Здравствуйте, vsb, Вы писали:
vsb>Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП) и никаких ограничений тут нет, сплошные возможности. И они частенько помогают.
Почему? Мне вот кажется, что другие парадигмы являются расширением ФП.
Здравствуйте, Spiceman, Вы писали:
rfq>>Какой смысл программировать в условиях искусственных ограничений? S>О каких ограничениях идет речь?
например, в некоторых языках нельзя держать вспомогательную переменную за пределами ф-ции.
приходится носить её с собой по итерациям в fold'ах или гонять через рекурсию.
и рекурсия тоже не самый любимый подход в императивщине. под неё надо подстраиваться. это тоже ограничение.
а ещё во многих языках нет банального наследования. нельзя взять и расширить существующий тип(данные+ф-ции), либо приходится это делать крайне ректально.
Здравствуйте, Spiceman, Вы писали:
vsb>>Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП)
S>Почему? Мне вот кажется, что другие парадигмы являются расширением ФП.
В силу собственной неспособности вспомнить хоть какие-то пригодные для гугления подробности притчи о спорящих мудрецах, каждый из которых пытался натянуть сову на свой глобус, скажу просто: ИМХО, вы оба пытаетесь натянуть сову на глобус. "А по-моему, они одинаковые." (c) это ортогональные вещи. Да, и кстати, на этот счёт есть старое, но прекрасное: http://rsdn.ru/forum/philosophy/3149723.1
Здравствуйте, neFormal, Вы писали:
F>а ещё во многих языках нет банального наследования.
Ну это уже проблемы отдельных языков, а не сабжа как такового.
UPD. Наследование — это ООП, а ООП + ФП = мультипарадигменный язык (на других нынче писать довольно глупо).
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге?
ФП подразумевает явное описание зависимостей выходных данных от входных. Конечно, это справедливо и для любых промежуточных результатов. Это сильно облегчает работу компилятора. В теории это даёт ему возможность применять очень крутые оптимизации, в том числе автоматическое распараллеливание. В императивных языках бывает сложно определить зависимости между данными, что ограничивает возможности автоматической оптимизации. Иногда функциональное представление алгоритма понятнее и для человека, особенно если у него математический бэкграунд.
На практике же, компиляторы ФЯ пока не достаточно хороши, а для невычислительных алгоритмов обычно удобнее императивное представление.
Здравствуйте, dimgel, Вы писали:
D>Ну это уже проблемы отдельных языков, а не сабжа как такового.
да, но это распространено.
D>UPD. Наследование — это ООП, а ООП + ФП = мультипарадигменный язык (на других нынче писать довольно глупо).
да пофиг на ООП. мне же реюз написанного кода нужен.
я не хочу раскидывать это по куче разных мест или в каждом новом типе указывать весь список используемых "родителей" и обкладываться ф-циями для использования всех этих возможностей.
Здравствуйте, Mazay, Вы писали:
M>ФП подразумевает явное описание зависимостей выходных данных от входных. Конечно, это справедливо и для любых промежуточных результатов. Это сильно облегчает работу компилятора.
rfq>Какой смысл программировать в условиях искусственных ограничений?
Пилат!
Есть пространство, а есть дуальное пространство.
Пространство -- сами объекты.
Дуальное пространство -- операции над объектами.
Чем больше ограничений, тем уже пространство, но тем (обычно) интереснее дуальное пространство.
Это разве не очевидно??
vsb>>Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП) и никаких ограничений тут нет, сплошные возможности. И они частенько помогают.
S>Почему? Мне вот кажется, что другие парадигмы являются расширением ФП.
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений?
Грамотные ограничения полезны.
Вот законы в государстве, например — типичные ограничения. Не дают разгуляться фантазиям.
rfq>Может, это просто детская забава, типа скакать на одной ноге?
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге? rfq>Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Не знаю что за ограничения и на каком языке вы пишете... но все современные гибридные языки поддерживают ФП в достаточной мере, чтобы использовать его потрясающие возможности и не думать про ограничения. Можно использовать ФП вместе с ООП и обычным процедурным программированием, просто используя в конкретном месте именно то, что там нужно по смыслу.
Вот есть у вас структура данных — какой-то контейнер (на базе списка, дерева и т.п.). И нужно для каждого (или не каждого) элемента выполнить какое-то действие, причем действия могут быть разные и их может быть много. До лямбда-функций приходилось или писать метод на каждое действие (с обходом контейнера) — код обхода дублировался; или придумывать интерфейс визитора, от него наследовать классы, в классе делать метод типа Visit и все это куча кода. С появлением лямбда-функций все упростилось, просто передаешь код в метод ForEach контейнера и все, никакой лишней писанины.
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
