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

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

Есть замечательная книга: «Parallel and Concurrent Programming in Haskell». Написана о том, как программируют на Haskell.

Тут надо признать, что обучение языку Haskell студентов часто оставляет желать лучшего. Хорошие студенты углубляются в чтение книг по Си++, когда хотят стать хорошими программистами на Си++. Здесь надо делать то же самое, если хотите понять, как программируют на Haskell. Короче, читайте книги!

То что ты написал это банальная мат индукция: состояние[N] = f (состояние[N-1], состояние[N-2], ...). А реальные задачи занимаются втягиванием энтропии вселенной в эти «состояние». А вот как посчитать вселенную посредством мат.индукции - это уже неразрешимая проблема, если вселенная не является счетным множеством. Так что, выкручивайся как можешь, но заказчик все равно найдет к чему придраться.

это банальная мат индукция: состояние[N] = f (состояние[N-1], состояние[N-2], ...).

Совсем не уверен, что это матиндукция

[N] = f (состояние[N-1], состояние[N-2], ...)

Что за матобъект?

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

https://en.wikipedia.org/wiki/Persistent_data_structure чтобы экономичко получать от старого экземпляра новый

из массового глянь на redux.js и immutable.js

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

Вопрос на засыпку: не проглядывается ли в утверждении очертания систем контроля версий, модно-молодежных блокчейнов и тп?

У тебя в монаде IO есть возможность кодить императивно. Изолированный блок кода, в котором ты и осуществляешь взаимодействие с миром. Монада стейт позволяет писать блок кода, где есть стейт. Этот блок будет заизолирован, а сама функция останется чистой, а функции ниже и выше по стеку не смогут влезть в этот блок (часто это всё-таки нужно и тогда юзают монадные трансформеры). Весь стейт минимизируется и изолируется, и изменяется с помощью чистых функций. Новый стейт = чистая функция от текущего. Эта Чистая функция - 90% кода программы, в идеале. Остальное - алгоритмы скармливания этим функциям данных из IO. Часто - спрятано и можно писать вообще всё декларативно (смотри functional reactive programming)

Это утверждение.

Безосновательное?

Твоя программа - это доказательство по мат. индукции.

Доказательство чего?

google://State monad

Отказаться от иллюзии, что большинство задач связано с изменением состояния, очевидно же.

Не неси херни

У тебя в монаде IO есть возможность кодить императивно.

В монаде IO такой же чистый функциональный код, как и во вне.

Изолированный блок кода, в котором ты и осуществляешь взаимодействие с миром.

А блок с монадой IO можно изолировать? Без читинга с unsafePerformIO.

Что за матобъект?

Это утверждение.

Безосновательное?

Кто-то потерял нить обсуждения. Что такое (мат) индукция и что она делает с утвреждениями мат.объектами?

Твоя программа - это доказательство по мат. индукции.

Доказательство чего?

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

Сам не неси

Не прикапывайся к формулировкам, сам сообрази, в каком смысле он «императивный».

Наверно не понял вопрос... Блок с ио у тебя и так топ-левел. Его можно разбить на функции а->ио б, и внутри них общаться посредством внешего мира с другим ио-кодом, нарушая эээ информационную замкнутость do-блока, но все эти функции как на ладони, с одним ио-клеймом все. А при хорошем дизайне их ещё и мало.

unsafePerformIO юзают, например, когда подключают сторонню библиотеку, реализующую чистые вычисления. В общем, когда мы делаем что-то в ио, но это не может ни на кого повлиять. Иное использование - суть ересь и автор подлежит сожжению со своим кодом.

Надеюсь, ответил

а вообще, похоже что нельзя

но зато у нас такой код отделён от остального

Не прикапывайся к формулировкам

Ну нихера себе. Если в контексте C++ говорят «константная ссылка» про «ссылку на константу», то поправлять такое — прикапываться к формулировкам.

А когда на чистый функциональный код говорят, что он императивный — это не проблема формулировки, это абсолютное враньё.

Блок с ио у тебя и так топ-левел.

Да. Так что никакого изолированного IO у тебя нет, у тебя весь код в IO. Лол.

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

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

Но я не очень понимаю, зачем я всё это говорю. Ты и так знаешь всё это, и наверно даже смог бы это всё сам написать. Ты просто прикопался к формулировкам, потому что тебе кажется, будто о предмете можно мыслить только определёнными формулировками, а другие автоматически не валидны. Это не так. Суть (операционную, семантическу, не важно) можно передать и другими словами, особенно людям не в теме. Поэтому если возражений по существу нет, то предлагаю закругляться. Понимаю, что они в твоём восприятии уже были в том или ином смысле по существу, но додумайся, что я имею в виду, когда говорю «по существу». А то надоело. Это слишком похоже на троллинг - заставить оправдываться по пустякам.

корректно отработавшая и завершившаяся программа - доказательство твоего утвреждения, записанного в виде кода программы.

При чем тут матиндукция?

Не при чем. Не хочешь (мат)индукцию, используй дедукцию. Берешь универсальный всемогутор и убираешь ненужное. Что проще, то и используй.

всё просто:

{исходное состояние1} --[функция изменения]-> {конечное состояние2}

из {исходного состояния1} генерируется {конечное состояние2}, т.е. имеем {исходное множество1}, генерируем {конечное множество2}, не изменяя {исходное множество1}, и они теперь существуют изолированно и одновременно, при этом, можно привести аналогию — ориентированный граф, где две вершины-состояния и дуга-вектор перехода

[функция изменения] может быть сложно-составной

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

если у тебя очень развита фантазия, то можешь считать {исходное состояние1} и {конечное состояние2} -- одним объектом в разные моменты времени , однако, ассоциативное мышление не должно мешать различать их

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

про категории и морфизмы читай тут: https://ru.wikipedia.org/wiki/Теория_категорий

А что, сейчас уже не модно Окасаки рекомендовать прочитать? Хотя у него не про вопрос из ОП, наверное.

Как правильно соединять чистый функциональный подход и то, что большинство задач связано с изменением состояния? Какие подходы проектирования/архитектуры использовать?

ах, да, «чистый» подход ограничивает применение — фильтрация/трансформация данных,
остальные прочие применения убивают «чистоту»

А ещё это не совсем правда.

Но даже если так, в этот класс попадает удивительно много вещей, но это может быть не очевидно.

ФРП - убивает чистоту? Лежит ли в области «фильтрация/трасформация данных»?

https://ru.wikipedia.org/wiki/Функциональное_программирование

https://ru.wikipedia.org/wiki/Чистота_языка_программирования

https://ru.wikipedia.org/wiki/Чистота_функции

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

Решил через рекурсивную ф-ю.

Теория категорий пока сложно для меня.

ok

но следует помнить, что у ребят из функционального программирования имеется один козырь (а может, даже, и джокер) — они могут формально доказать корректность своих программ, остальные, в общем случае, так не умеют и математически доказать корректность программ остальным сложно, однако, «для функциональных языков не удается добиться приемлемой эффективности даже с помощью изощренной оптимизации»

если же тебе не нужны доказательства корректности, а нужно «чтоб просто работало», то можешь и не заморачиваться :)

вообще, может быть интересно почитать перевод 2016г. статьи: «Недостатки чистого функционального программирования»

{исходное множество1} --[функция изменения]-> {конечное множество2}

если у тебя очень развита фантазия, то можешь считать {исходное множество1} и {конечное множество2} — одним объектом в разные моменты времени

[a,b,c,d] --[функция изменения]-> [b,c] — ещё можно как-то считать «одним объектом в разные моменты времени», но [a,b,c,d] --[функция изменения]-> [false]? видимо у меня не очень развита фантазия на терминальные объекты.

так ты ничего не поймёшь, почитай лучше про https://ru.wikipedia.org/wiki/Преобразование_Лапласа

или применение конформного отображения:

К. о. применяется с давних пор в картографии, когда требуется часть поверхности земного шара изобразить на плоскости (на карте) с сохранением величин всех углов; примерами таких К. о. являются стереографическая проекция и Меркатора проекция. Более общая задача К. о. произвольной поверхности (или её части) на другую поверхность (или её часть) изучается в дифференциальной геометрии. Особое место занимают К. о. одних областей плоскости на другие; их теория имеет существенные приложения в гидро- и аэромеханике, электростатике и теории упругости. Решение многих важных задач получается без труда, когда область, для которой ставится задача, имеет достаточно простой вид (например, круг или полуплоскость). Если задача ставится для другой, более сложной области, то оказывается достаточным отобразить конформно простейшую область на данную, чтобы получить решение новой задачи из известного решения. Так, например, задача об определении потока несжимаемой однородной жидкости или газа, обтекающего цилиндр с круговым сечением, решается сравнительно легко. Линии тока (т. е. линии, вдоль которых направлены скорости частиц жидкости), для этого случая, здесь представлено течение при наличии циркуляции. Если отобразить конформно внешность кругового сечения цилиндра на внешность поперечного сечения крыла самолёта (профиля крыла), то линии тока для случая круглого цилиндра перейдут, как можно показать, в линии тока при обтекании крыла. Знание отображающей функции z' = f (z) позволяет подсчитать скорость потока в любой точке, вычислить подъёмную силу крыла самолёта и т. д. Именно таким путём шёл Н. Е. Жуковский, создавая теорию крыла самолёта. [источник]

а здесь немного более наглядно про теорию функций комплексного переменного, конформное отображение, обтекание цилиндра и аэродинамический профиль крыла самолёта: Аэродинамика (I)

Это же просто математическое отображение