Спасибо папаша😃

🍃Чистота функций

В чем суть чистоты функций, если современные системы выполняют очень много действий, создающих побочные эффекты?

Как я уже писал в посте про основополагающие принципы функционального программирования, при вызове чистой функции её результат зависит только от входных параметров. С одними и теми же параметрами чистая функция возвращает одно и то же значение, никак не влияя на внутреннее состояние системы. Это два свойства чистых функций – детерминированность и идемпотентность соответственно. Функции, нарушающие одно из свойств (или оба), имеют некоторые побочные эффекты, размазывающие результат функции по системе: меняют локальное состояние (например, записывают данные в локальную БД), обращаются к внешним ресурсам, обращение к которым может завершиться ошибкой, или возвращающим переменные данные (HTTP-запросы, обращения к памяти, вывод в консоль, получение timestamp и так далее). В терминологии Haskell для таких операций есть отдельное название – действие ввода-вывода. Но сегодня не будем про Haskell, как-нибудь в следующий раз.

Любая система обращается к внешним ресурсам и возвращает некоторый результат обработки данных. Так зачем запариваться, если побочные эффекты неизбежны?

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

Идеальная архитектура приложения в этом смысле выглядит так:

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

2. Оболочка: Тонкий слой, отвечающий за взаимодействие с внешним миром. Он получает сырые данные "снаружи" (из БД, от API-вызова), прогоняет их через чистое ядро и затем (или перед этим) выполняет необходимые эффекты: запись в БД, отправку ответа, логирование.

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

Такой подход превращает написание кода из хаотичного процесса, где всё связано со всем, в рациональный и упорядоченный, где большая часть системы ведёт себя предсказуемо и поддаётся простому анализу. Это не запаривание ради запаривания, а инвестиция в поддержку, надёжность и скорость разработки проекта в долгосрочной перспективе. Да, приходится подумать лишний раз, но оно окупится с лихвой.

#functional #theory

О чем рассказать в первую очередь? Не знаю, какую написать вперёд - все темы нравятся одинаково

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

https://t.me/chrisonych

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

Я играю на бас-гитаре, и сосед-гитарист пригласил меня играть вместе с ним — вот мы уже ко второму совместному квартирнику готовимся. Если раньше подобранные на слух несложные партии я записывал на бумагу, то сейчас я не знаю, как держать это всё на бумаге так, чтобы можно было разобраться без 100 грамм, просто бегло взглянув на схему. К тому же партии сложные, и держать все в голове достаточно тяжело.
Я нашел в пару сервисов, позволяющих удобно создавать табы. Но ограничение в 15 песен меня смущает😃

Коротко об идее: хочу дойти до self-hosted решения для организации и хранения репертуара и написания табулатуры. В веб-интерфейсе можно будет прописывать табулатуру для гитары и бас-гитары, сохранять её и структурировать в плейлисты. Прямо в редакторе можно будет прослушивать табулатуру в синтезе

Функциональщина никуда не денется, заметки по разработке будут отдельной рубрикой
Может бэк на Haskell написать?..

✍️ Как я учусь

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

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

Я не верю в «сначала вся теория, потом хоть потоп» – это смертный приговор для мотивации. Поэтому я делаю наоборот. Хочу вырезать через ворона из дерева? Беру резец и пробую, царапая заготовку и совершая кучу ошибок, но, в конечном счёте, добиваясь какого-то результата. Решил разобраться с новым фреймворком? Не читаю документацию, а сразу перепечатываю чужой код из туториала, чтобы через пять минут увидеть на экране работающее, хоть и чужое, приложение. Это даёт мощнейший импульс для дальнейшего развития по двум причинам:
— У меня в руках появляется результат работы. Да, корявый, но результат, которого я добился сам, пусть и с туториалом, если говорить в контексте разработки. Это даёт мне большой прилив положительных эмоций и вызывает чувство маленькой, но победы.
— Я могу проанализировать свои ошибки и предположить, что можно было сделать лучше. И вот тут-то и наступает самый важный момент: у меня появляются правильные вопросы. Я больше не листаю документацию как сонный справочник, а целенаправленно ищу в ней ответы на конкретные «как?» и «почему?». Изучение теории становится более продуктивным, поскольку есть практический контекст. Она не просто рассказывает, а объясняет то, с чем я уже столкнулся руками.

После первой попытки я с ощущением «это вы падажжите, я еще доку не смотрел» иду изучать теорию. И только с этим живым интересом и положительными эмоциями я открываю теорию, иначе процесс получения новых знаний будет для меня самой страшной пыткой. После получения необходимого корпуса знаний я иду закреплять полученные знания на практике. Это может быть абсолютно неадекватная и невыполнимая идея вроде «Ну, Hello World я написал, теперь можно бахнуть драйвер для видеокарты». И абсолютно серьезно сажусь изобретать, догугливая необходимые знания на ходу. Да, вероятнее всего я не доведу идею до конца и не получу результат, но на данном этапе мне важен уже не результат, а то, что я получаю в процессе – новые знания. Именно поэтому у меня больше 30 репозиториев на гитхабе (после чистки, до этого их было 64). В ходе этих экспериментов я нахожу свои слабые места, интересные ресурсы и все, что каким-то образом может помочь мне в развитии, и прямо на месте прорабатываю все найденное.

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

#philosophy

Написал, что не могу провести ни одного дня без изучения чего-то нового, а сам два дня по-черному тюленю😃
Такое редко бывает, хоть пару слов корейских за день да выучу хотя бы. Отдыхать тоже надо, так как, всё-таки, именно во время отдыха мозг строит новые нейронные связи и систематизирует новые знания. Не забывайте отдыхать🙏🏾

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

Сегодня мне приснилось, будто у меня сгорел целый дом, в котором я хранил книги и разные рукописи. Полдня думал, к чему мне это приснилось, и вспомнил, как чуть не отправил в мусорку ~70 проработанных заметок, написанных своими мыслями, не скопипасченных или перепечатанных. Добавил их к своему новому хранилищу, разложил все в новой структуре по полочкам.

Цените знания, даже если они вряд ли вам понадобятся🙏🏾

#philosophy

Статья про RAG в процессе написания. Она получается очень объемной, поскольку я постарался раскрыть тему настолько подробно, насколько это возможно. Будет много схем и картинок, в рамках телеграмного поста сделать это не представляется возможным. Поэтому, для больших сложных постов я буду публиковать ссылки на telegraph для чтения прямо внутри телеграма.

Возможно я переборщил местами, но в целом должно быть интересно

Люблю LaTeX🫣

Сегодня я пробно постримил на на твиче. Причин этого не делать я не нашел, поэтому все заметки по разработке редактора партитур перенесутся в формат стримов с записью. Лайв-кодинг, всё такое😃
Я буду стримить там не только что-то связанное с разработкой — сегодня я стримил, как добиваю 80 уровень шамана в World of Warcraft. Связанные с кодингом стримы я буду отдельно анонсить здесь

Сразу можете оформить подписочку:
https://www.twitch.tv/lsdrfrx

А лайв-кодинг будет очень и очень скоро — я участвую к хакатоне ЛЦТ. Задача предстоит интересная, но об этом я расскажу завтра🤫

Сегодня на стриме разбираем, что такое Backend Driven UI. Лайв-кодим💪🏾

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

Предварительное время начала: 13:00

Кто будет – тыкните реакцию 👀

#frontend #livecoding

Совсем скоро начинаем 👨🏾‍💻

Как и обещал, делюсь дотфайлами:
https://github.com/lsdrfrx/arch-dots

Запись со стрима нужно немного обработать, по готовности залью сюда🫡

Как и обещал, сегодня продолжаем тему Backend Driven UI. Запускаю стрим в 18:20, буду дальше разбираться в том, как это все работает под капотом.

Записи сегодняшнего и прошлого стрима по BDUI выложу завтра — будет что посмотреть на выходных😃

Запускаюсь в 18:20 🎥

Тем временем работаю над большим разбором RAG (Retrieval-Augmented Generation). К субботе планирую запостить статью, в которой без воды и заумностей:
– Объясню на пальцах, что это такое
– Докажу, что это сильно проще, чем кажется на первый взгляд
– Наглядно покажу, как запустить базовый RAG и завернуть его в API
– Разберу, как расширить его возможности с помощью дополнительного контекста
– Расскажу, когда это действительно нужно.
Пишу уже достаточно долго, но усердно. Кто ждёт – покажите это реакцией 🔥

Очень сильно переоценил себя – решил в один момент и пост дописать, и 7 часов отснятых стримов отсмотреть, и ремонт продолжить. Чтобы не закапываться в дела и не пропадать надолго, буду делать немного меньше.

Записи стримов для меня сейчас недоступны (я разобрал стол в процессе ремонта, комп некуда ставить). Пост про RAG ещё не дописан, поэтому анонсы записей и статьи будут немного позже. А сегодня, чтобы не было тишины, я выскажусь о наболевшем – что такое ООП и ФП на самом деле.

Этот канал про мой опыт и ошибки, так что по-честному делюсь – переборщил немножко😃

🧠 Программирование как философия мышления

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

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

Если завернуть абсолютно императивную логику в класс, гвоздями к нему прибить реализацию источника данных, тоже завернутую в класс – это не ООП. Это не про классы, не про интерфейсы, не про SOLID. Это про абстракции, которые позволяют тебе мыслить объектами, взаимодействующими между собой как живые сущности. Объект – это не контейнер для методов и данных, это единица ответственности и поведения, которую ты можешь осознать, описать и изолировать. Когда ООП превращают в "фабрику фабрик", "менеджер менеджеров" и наследование ради наследования – это не ООП, это императивный код в костюме UML.
ООП – это про качество абстракции – про то, чтобы модель кода была зеркалом модели реальности, а не свалкой паттернов.

Абсолютно та же мысль применяется к функциональной парадигме: если писать map вместо for, а вместо function использовать стрелочные функции – это не ФП, а точно такой же императивный код. Функциональное мышление – не про синтаксический фетишизм, а про контроль над изменением, про использование функций как строительные блоки, где каждый из них – как атом, не зависящий от внешнего мира. Данные не меняются, функции не лгут, а побочные эффекты происходят только с разрешения разработчика в строго описанном им месте.

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

#philosophy