Вышел 2-й выпуск журнала «Практика функционального программирования»

> Не нашёл в твоём примере объектов с изменяемым состоянием и разрушающих присвоений. Без этого "императивная" программа выглядит слишком декларативно.

сковородка нагревается, яйца разбиваются, - это мало?

> сковородка нагревается, яйца разбиваются, - это мало?

temperature = f(time)? Этого на самом деле мало.

> temperature = f(time)? Этого на самом деле мало.

Там на самом деле бинарное состояние - нагрета или нет, никаких функций.

> Там на самом деле бинарное состояние - нагрета или нет, никаких функций.

Функция не может давать бинарное значение? Приехали.

> Функция не может давать бинарное значение? Приехали.

Тут, млять, состояние сковороды сохраняется в булеву (или битовую) переменную, какие нахрен функции?

> Тут, млять, состояние сковороды сохраняется в булеву (или битовую) переменную, какие нахрен функции?

Не сохраняется, попробуйте опровергнуть ;)

> Не сохраняется, попробуйте опровергнуть ;)

даже и не подумаю.

omelet' :: Eggs -> State Pan Eggs
omelet' e = do p <- get
               let (o, p') = omelet e p
               put p'
               return o

Можно даже так:

omelet' = mapState (uncurry omelet) . return

> Тут, млять, состояние сковороды сохраняется в булеву (или битовую) переменную, какие нахрен функции?

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

> Данную задачу мы можем реализовать как разрушающее присваивание. А можем поступить и иначе.

Конечно, можем. Только получится тихий ужас, который вы тут написали на хаскелле, в императивщине все получается значительно проще и прозрачнее.

> Я, вот, вижу, как функция возвращает значение двоичного типа.

как оо-адепты везде видят объекты, так фп-адепты везде видят функции.

> как оо-адепты везде видят объекты, так фп-адепты везде видят функции.

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

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

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

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

> Разница в том, что ФП-программист как правило также писал и на ООП, и в рамках императивной парадигмы, примерно представляет границы применимости этих методологий и может выбрать оптимальную в рамках определённой задачи.

Т.е. все-таки фп не всегда подходит :)

> Конечно, можем. Только получится тихий ужас, который вы тут написали на хаскелле, в императивщине все получается значительно проще и прозрачнее.

Ага, плавали, знаем. Вместо higher order map, fold, filter etc. императивщики громоздят пачками переменные, циклы, счетчики и прочую хрень. Очень красивые простыни получаются, только читать их долго и нудно. Про то что некоторые вещи легче/лучше выразить потоками, рекурсией я вообще молчу.

> Ага, плавали, знаем. Вместо higher order map, fold, filter etc. императивщики громоздят пачками переменные, циклы, счетчики и прочую хрень.

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

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

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

> Т.е. все-таки фп не всегда подходит :)

Конечно нет. Серебряной пули не существует. Тебя обманули.

> Конечно нет. Серебряной пули не существует. Тебя обманули.

Что самое забавное, обманули фп-фанбои :)

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

Ясное дело. Зато функциональный язык автоматом заставляет использовать все это добро. Сюда также стоит добавить currying, function composition etc. для того чтобы отделить императивный язык с несколькими плюшками в функциональном стиле от функционального языка. Между ними пропасть. Как говорят те, кто подсел на Haskell (наверняка то же самое можно сказат про OCaml и иже с ними) "попробовав Haskell вы будете считать программирование на "продакшн" языке пустой тратой времени".

> Что самое забавное, обманули фп-фанбои :)

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

> Только получится тихий ужас, который вы тут написали на хаскелле, в императивщине все получается значительно проще и прозрачнее.

Может мы наваяли и не в самом лучшем виде (лично я Хаскелл знаю не так хорошо, как хотелось бы) но для меня код, написанный r, прост и понятен. Ты с синтаксисом Хаскелла знаком? А то конечно, поди пойми, если не знаешь, какие параметры куда передаются, и что там за значки понатыканы.

И некоторые вещи мы писали в одну строчку, чтобы скормить интерактивному интерпретатору. Естественно, в программе мы бы писали с отступами.

Да, можешь попробовать реализовать то же самое на своём любимом языке, и сравнить размер кода.

Дайошь lor autumn of code!

>Показать, что задумываемость в твоем определении ортогональна функциональности/императивности.

Что - как только в С# появилась лямбда - лямбда слата ортогональная функциональности - потому что появилась в императивном языке? RLY?

>Т.е. хаскелл нельзя считать черным ящиком, потому что там есть rand?

А в каком месте _язык программирования_ удовлетворял определению черного ящика?

>Для человека естественно наличие состояний - identity и мутабельных объектов, данных

тру

>Для человека естественнено описывать процесс последовательностью действий,

Не тру.

Для человека харатктерно описывать процесс в виде свертывания дерева. Пример в яичнице потому и написан через where а не просто композицией набора функций.

Мне нужно сделать яичницу _для чего_ надо достать яйца из холодильника, разогреть сковороду _для чего надо ее достать, включить плиту, намаслить, и тд.

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

Пример:

x = y + 1
if (y == 1) return x;
else return y;

Оптимизируя этот пример проанализируй свои размышления относительно переноса вычисления X внутрь if. Это отнюдь не императивный пошаговый анализ.

>Скажите, это топик о функциональном программировании? Как мне приготовить яичницу с помидорами?

На хаскеле или на окамле? :) У меня на хаскеле пока пригорает:)

>В императиве это будет очень просто:

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

>Только получится тихий ужас, который вы тут написали на хаскелле, в императивщине все получается значительно проще и прозрачнее.

Нука нука - в студию.

>Вместо higher order map, fold, filter etc. императивщики громоздят пачками переменные, циклы, счетчики и прочую хрень. Очень красивые простыни получаются, только читать их долго и нудно.

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

Endless.seq(db.select(filter)),,, грубо говоря. Мне императивный коллега сказал "непонятно" - надо было двойной вложенный цикл, с кучей переменных и обходом временых значений....

Ага.

>> Скажите, это топик о функциональном программировании? Как мне приготовить яичницу с помидорами?

> На хаскеле или на окамле? :)

В отличие от Ъ-ФП-прогеров, я жарю яичницу на сковородке %)

> Поясни, как это они "заставляют".

Я не такой герой, как r, чтобы активно флеймить при 38+, особенно если там не тупой поиск ошибок, а некоторая концентрация нужна. Так что сорри, дня через 3 оклемаюсь, отвечу.

>Я не такой герой, как r, чтобы активно флеймить при 38+,

У меня теплый плед и антибиотики широкого спектра:)

>В отличие от Ъ-ФП-прогеров, я жарю яичницу на сковородке %)

Та ну нафиг - я тоже вчера пробовал - так нажрался...

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

>r ***** (*) (30.09.2009 18:31:55)

Хорошо сказал, респект!

>Дайошь lor autumn of code!

поддерживаю

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

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

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

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

Ленивые последовательности делаются на раз с помощью лексических замыканий. Да и генераторы с итераторами никто не отменял. Только они нужны не сильно часто.

> Endless.seq(db.select(filter)),,, грубо говоря. Мне императивный коллега сказал "непонятно" - надо было двойной вложенный цикл, с кучей переменных и обходом временых значений....

Твой императивный коллега - дурак.

> А в каком месте _язык программирования_ удовлетворял определению черного ящика?

Т.е. понятие черный ящик иррелевантно нашей дискуссии?

> Потому что яищника - это объект класса яичшниц, для для того, чтобы его создать (сконструировать), нужны объекты других классов - сковородки, мысла, соли.

Роботы среди нас.

> Для человека харатктерно описывать процесс в виде свертывания дерева.

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

> Мне нужно сделать яичницу _для чего_ надо достать яйца из холодильника, разогреть сковороду _для чего надо ее достать, включить плиту, намаслить, и тд.

Это сильнее смахивает на пролог, а не на функциональщину :), хотя кто вас там разберет.

> Оптимизируя этот пример проанализируй свои размышления относительно переноса вычисления X внутрь if. Это отнюдь не императивный пошаговый анализ.

компиляторы такое спокойно оптимизируют, да и - premature optimisation - зло, а вот ленивые вычисления память жрут - как свиньи желуди, неизвестно - понадобится тебе один мегабайт или 800, к тому же вылезет в самом неподходящем для этого месте.

Мои утверждения основаны на том как я думаю. То есть беря сковороду - я знаю что это для яичницы - связь вида яичница = f(сковорода) очевидна. Не совсем понимаю как ты даже помыслить можешь о том чтобы измиенить состояние сковороды еще не догадываясь зачем.

>Т.е. понятие черный ящик иррелевантно нашей дискуссии?

Дискуссии ирелевантны вопросы удовлетворяют ли всякие сущности реального мира (здесь можно перечсислять все что угодно) черным ящикам.

>Это сильнее смахивает на пролог, а не на функциональщину :), хотя кто вас там разберет.

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

> Для этого умные люди придумали structured programming

Жалкая попытка получить лёгкость и изящество ФП в убогих императивных программах.

>> Мне нужно сделать яичницу _для чего_ надо достать яйца из холодильника, разогреть сковороду _для чего надо ее достать, включить плиту, намаслить, и тд.

> Это сильнее смахивает на пролог, а не на функциональщину :), хотя кто вас там разберет.

Такое ощущение, что ты не знаешь, с чем ты не согласен. :)

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

> Такое ощущение, что ты не знаешь, с чем ты не согласен. :)

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

> Со стороны это выглядит так: всё, что я знаю и чем мне удобно пользоваться - это императивщина, а функциональщина - это вовсе не то, про что вы мне тут рассказываете, а какая-то жуткая малопонятная хрень. :)

Я знаю, когда удобно использовать функциональные фишки, но полностью себя ограничивать функциональщиной - это бред, делать ленивые вычисления по умолчанию, хотя они нужны лишь в 10% случаях - неправильно, делать иммутабельные данные по умолчанию - хотя они по большому счету нужны для простого thread-safe программирования (я знаю, что они нужны не только для этого и как часто неявное изменение состояние приводит к багам) - неправильно. Запихивать производимые функцией побочные эффекты в систему типизации - не правильно, в результате на то, чтобы смоделировать задачу уходит больше, чем на решение самой задачи в проблемной области, и рефакторинг проходит очень тяжело. Если уж говорить, про фп - то самый на мой взгляд адекватный язык из фп-образных - ocaml.

> Жалкая попытка получить лёгкость и изящество ФП в убогих императивных программах.

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

>Для меня - это просто "объект", предмет, называйте как хотите, который у меня могут, к примеру украсть, и тогда я останусь без еды,

В каком месте тут императивность? Ты сам то знаешь что такое императивность?

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

Как функциональная так и императивная модель - это всего лишь модели в которых удобно размышлять. Ты говоришь сейчас об объектах и копиях только потому что привык к указателям и прочим мусорным нулам. Ты мыслишь в терминах а-ля Си. Внимание сюрприз - ничего общего с реальностью оно не имеет, это не единственный способ оперировать "обектами" - подумай о термине first class object. И вообще ООП перпендикулярно функциональщине и императивщине. Ты все время скатываешься во всякие "структуры", "объекты". Посмотри на приведенные коды на хаскеле - там полно и cтруктур и объектов. И даже функции передаваемые в map (higher order functions) такие потому что сама функция это first class _object_.

У меня действительно тоже создается впечатление что ты фундаментально не понимаешь что такое императивная парадигма. Дело тут совсем не в мутабельности объектов. В том что основной целью шага алгоритма в императивном подходе является _создание сайд эффекта_. А на читстых функциях можно писать хоть на Си. Но как правильно замечено в одной из статей - нахрена тогда использвать неудобный для этого язык.

> В каком месте тут императивность? Ты сам то знаешь что такое императивность?

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

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

> Как функциональная так и императивная модель - это всего лишь модели в которых удобно размышлять.

Да, но императивная естественнее для человека.

> Ты говоришь сейчас об объектах и копиях только потому что привык к указателям и прочим мусорным нулам. Ты мыслишь в терминах а-ля Си.

Я мыслю терминами Сасмена и Абельсона.

> Внимание сюрприз - ничего общего с реальностью оно не имеет, это не единственный способ оперировать "обектами" - подумай о термине first class object. И вообще ООП перпендикулярно функциональщине и императивщине.

Да.

> Ты все время скатываешься во всякие "структуры", "объекты".

Слово объект в прошлом посте я использовал в его прямом лексическом значении, без связи с ооп.

> Посмотри на приведенные коды на хаскеле - там полно и cтруктур и объектов.

да, только все они - сюрприз функции :), даже числа - это функции (черчевские числа).

> И даже функции передаваемые в map (higher order functions) такие потому что сама функция это first class _object_.

object - здесь в прямом значении, а не в ооп значии.

> У меня действительно тоже создается впечатление что ты фундаментально не понимаешь что такое императивная парадигма.

Объясни это вышеупомянутым Sussman and Abelson, они-то уж точно не понимают, что такое функциональное програмиирование :)

> Дело тут совсем не в мутабельности объектов. В том что основной целью шага алгоритма в императивном подходе является _создание сайд эффекта_.

Также, как и абсолютно функциональной программе.

> А на читстых функциях можно писать хоть на Си.

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

> Но как правильно замечено в одной из статей - нахрена тогда использвать неудобный для этого язык.

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

У меня действительно тоже создается впечатление что ты фундаментально не понимаешь что такое императивная парадигма. Дело тут совсем не в мутабельности объектов.

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

Соответственно, программирование, в котором присваивание не спользуется (как у нас в первых двух главах этой книги), известно как функциональное программирование (functional programming).

В противоположность функциональному программированию, стиль программирования, при котором активно используется присваивание, называется императивное программирование (imperative programming).

ЗЫ. И этот человек защищает функциональное программирование - ты хоть узнай, что это такое, лол.

>Я уже много раз писал, что такое императивность - задание алгоритма в виде последовательного списка шагов, каждое из которых несет за собой изменение окружения программы, т.е. там, где есть деструктивное присваивание, состояние, identity и прочее. (

Дык вот - ключевая фраза тут - "изменение состояния", а не "список шагов".

>Императивность тут при том, что при выполнении параллельно двух процессов у них есть общее окружение, которое можно изменять, и изменения будут влиять на ход их работы.

Ответь на простой вопрос - разбитые яйца - это состояние целых яиц или отдельный объект? А потом на тот же вопрос - если ты их не разбивал?

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

>В жизни все не так - выполнение процесса вора моей яичницы - она имеет побочный эффект - изменение ее состояния

Это ты придумал ей состояние. Намек - изменение координат отлично описывается функциями - это даже дети в школе учат - геометрия называется. Но никому в голову не приходит идея деструктивного присваивания для линейной алгебры. Догадайся почему.

>В функциональном мире все не по-другому - процесс вора не получит ссылку, pointer, reference на яичницу

Нету никаких поинтеров и референсов в реальном мире. Кончай видеть мир через С++.

>он получит _новый_ объект

Понятие нового и старого - то же самое понятие из С++.

Пример из ранее написаннного:

heat Pan Cold = Pan Hot
heat x = x

В первом случае это "новый объект" а во втором нет? Серьезно? А какая между ними разница? Разница только в твоем сяшном видении что там происходит. Нету никаких референсов. Нету никаких поинтеров. Ты в руках держишь не яйцо в вариабельном состоянии разбитые - ты держишь _скорлупу_. Без всяких деструктивных присваиваний полей объектов через поинтер.

>Да, но императивная естественнее для человека.

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