LINUX.ORG.RU

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

 , , ,


1

0

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

Центральная тема второго выпуска журнала — демонстрация применения функционального программирования в реальных, а не академических проектах.

Первые четыре статьи — Дмитрия Зуйкова, Дмитрия Астапова, Сергея Зефирова в соавторстве с Владиславом Балиным, и Алексея Отта — вытаскивают на поверхность «кухню» нескольких компаний. Статьи демонстрируют, что функциональные языки находят применение в промышленном программировании в самых разных нишах. Конечно, использование «нестандартных» языков накладывает на проекты некоторые сложно оценимые риски, и далеко не все из них рассмотрены в статьях. Но если статьи этого номера позволят развеять хоть часть сомнений, мифов и предрассудков и поднять дискуссию о применимости функциональных языков в промышленном программировании на новый уровень, мы будем считать свою задачу выполненной.

Статья Александра Самойловича рассматривает создание на языке Erlang игрушечного, но практичного проекта — рекурсивного многопоточного обходчика сайтов. К третьему выпуску журнала мы планируем подготовить ещё несколько статей про Erlang.

Завершающая статья Романа Душкина в большей степени ориентирована на теорию: она познакомит вас с концепцией алгебраических типов данных (АТД) в Haskell и других функциональных языках.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 1)

Ответ на: комментарий от ugoday

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от pitekantrop
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

pitekantrop ★★★
()
Ответ на: комментарий от anonymous

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

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

pitekantrop ★★★
()
Ответ на: комментарий от anonymous

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

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

тру

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


Не тру.

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

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

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

Пример:

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

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

r ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

Ага.



r ★★★★★
()
Ответ на: комментарий от r

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от pitekantrop

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

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

r ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

r ★★★★★
()
Ответ на: комментарий от r

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

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

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

anonymous
()
Ответ на: комментарий от r

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

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

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

anonymous
()
Ответ на: комментарий от r

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

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

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

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

anonymous
()
Ответ на: комментарий от r

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

ugoday ★★★★★
()
Ответ на: комментарий от r

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

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

r ★★★★★
()
Ответ на: комментарий от anonymous

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

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

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

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

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

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

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

anonymous
()
Ответ на: комментарий от ugoday

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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


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

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

r ★★★★★
()
Ответ на: комментарий от r

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от r

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от r

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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


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

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

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


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

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


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

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


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

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

heat Pan Cold = Pan Hot
heat x = x

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

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


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










r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.