Мой блог про IT, ML и прочее

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

Мы уже рассмотрели, как принцип разделения интерфейсов из SOLID вполне успешно может использоваться и в ФП. Для убедительности, рассмотрим еще одну букву из знаменитого набора принципов, и попробуем применить принцип “Инверсии управления”, он же Dependency Inversion в функциональном коде.

Функциональное программирование и ООП часто рассматриваются как две абсолютно разные парадигмы разработки программного обеспечения. Казалось бы, эти парадигмы очень далеки друг от друга: в классическом ООП мы имеем дело с объектами, которые определяют состояние системы в текущий момент времени. В ходе работы программы объекты обмениваются сообщениями, изменяя при этом своё состояние. Когда речь заходит о ФП, понятие состояния вообще неприменимо, вместо этого имеем дело с “чистым” преобразованием данных при помощи функций.

Долгое время я очень боялся писать хоть что-то про монады, в силу ряда причин:

• Это сложное понятие из теории категорий
• Про это уже было множество статей, роликов заметок и т.д. и едва ли я скажу что-то новое.
• Все эти объяснения, по крайней пере сами по себе, практически не дали мне никакого внятного понимания.

Да, видимо есть что-то в монадах, что мешает объяснить их по простому, хотя бы для начального понимания. При этом попытки объяснить часто начинаются вообще с разных подходов, нам говорят:

При изучении OOП на Python, Inversion of Control (IoC) является одной важных тем, понимание которой позволяет писать хороший ООП код. IoC это еще один из принципов, который выражает идею о том, что объекты не должны зависеть от конкретной реализации. Если внутри класса создаётся конкретный экземпляр другого, то это явная зависимость – теперь поведение класса зависит от этого объекта, и его корректирование требует явного вмешательства в внутреннее устройство класса. Это наружение классического ООП подхода - “программировать на уровне интерфейсов, а не реализации”. Принцип IoC звучит очень обобщенно, при этом гораздо чаще говоря IoC подразумевается Dependency Injection (DI) – классическое решение описанной выше проблемы.

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

Какой самый низкий уровень, куда может “спуститься” программист?

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

Абсолютно must-watch доклад по функциональному программированию от Скотта Влашина, владельца замечательного сайта F# for Fun and Profit, и автора многих важных книг по функцональному программированию, вроде # Domain Modeling Made Functional (увы, еще не читал).

Ковыраяя различные ресурсы, посвещённые языку OCaml наткнулся на ролик с выступлением Ричарда Хикки, создателя функционального языка Clojure. Это выступление, на мой взгляд, концетрированная выжимка той критики, которую любители функционального программирования обычно подвергают мейнстрим.

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

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

Distrobox - это opensource проект, по сути - большой набор shell-скриптов, который при помощи выбранного бэкэнда (docker, podman, с недавних пор еще lilipod) позволяет запускать контейнеры популярных Линукс дистрибутивов. При этом мы получаем доступ к всему диапазону программных пакетов конкретного дистрибутива, и сам контейнер близко интегрируются с нашей основной системой, позволяя легко пользоваться приложениями внутри контейнера.

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