Это настолько же костыль, насколько библиотека windows forms костыль для C# для работы с окнами. Это просто способ выразить императивную семантику через функциональную. В clean для этого используют объект World
Поинт не в том, на языке или не на языке, а в том, что сама по себе семантика императивная. Мы не создаем ничего и не уничтожаем, мы просто описываем что нам надо. Что нам не надо получается оттуда само и уничтожается или создается при трансляции на нижележащие императивные уровни
С моей точки зрения, это полезное извращение — когда снаружи не видно, что есть данные а что есть алгоритмы для получения каких-то свойств, мы можем менять реализацию гарантированно не затрагивая пользователей
Менять это значит что существует то же самое, но с другим состоянием. Соответственно порождение новой пары (ID, State2) из (ID, State1) семантически эквивалентно «Менять»
Никогда так не пишите статей — автор попробовал реализовать что-то в функциональном стиле на нефункциональном языке, ему стало больно, он об этом написал. Без какого-то анализа причин и альтернативных решений.
На Haskell то, что он написал, выглядело бы примерно так:
Мне кажется, различие только в том, что в императивном мире есть глобальное общеизвестное состояние в объектно-оритетированном мире у объектов есть identity и state, соответственно, есть понятие изменения как для глобального объекта «мир» так и для любого конкретного объекта (а чтобы объяснить, что состояние неизменно, нужны спецухищрения). Причем состояния объектов являются частью состояния мира.
В чистом функциональном мире наоборот, эти понятия вводятся дополнительно и локально: если хочешь использовать глобальное состояние надо явно использовать объект RealWord, возможно обернутый в IO monad, можно вводить локальные состояния через State monad, причем они могут не зависеть от состояния мира и быть множественными. За это платят явной передачей этих аргументов везде, где надо.
> Таким образом все состояние над которым мы производим операции можно протестировать, потому что мы его задаем только в конструкторе
Применительно к ООП мне эта концепция кажется странноватой — разве там не основной принцип, что состояние должно быть вообще абстрагированно и мы не можем получить к нему прямой доступ?
Лада «Сатана» — стелс покрытие, особая форма корпуса как у FA-117 ложные мишени в виде уголковых отражателей чтобы создавать лишние отметки на полицейских радарах
тесто |> месить |> поставитьВДуховку |> влючить
оператор |> берет левую часть и применяет к ней функцию, указанную в правой
allObjects2 = transition(allObjects, objectID)
Т.е. если у нас есть RealWorld и мы его с собой всюду таскаем, то функциональное программирование по свойствам становится эквивалетно имеративному
Вскипевший Чайник ЭТО засвистевший(поставленныйНаПлиту(сНалитойВодой(чайник)))
На Haskell то, что он написал, выглядело бы примерно так:
В чистом функциональном мире наоборот, эти понятия вводятся дополнительно и локально: если хочешь использовать глобальное состояние надо явно использовать объект RealWord, возможно обернутый в IO monad, можно вводить локальные состояния через State monad, причем они могут не зависеть от состояния мира и быть множественными. За это платят явной передачей этих аргументов везде, где надо.
Применительно к ООП мне эта концепция кажется странноватой — разве там не основной принцип, что состояние должно быть вообще абстрагированно и мы не можем получить к нему прямой доступ?