Функциональное программирование *

Книги делятся на две категории: fiction и non-fiction. Технические книги — внезапно — не исключение, и поддаются точно такой же классификации. Между учебником по научной дисциплине, начинающегося с аксиоматики и продолжающегося доказательствами теорем, — и практически любой современной литературой по «Computer Science» — лежит пропасть. Что происходит, когда люди долгое время оказываются рабами одной-единственной книги (с продолжениями), нам хорошо известно из истории. Возникает религия.

99% процентов литературы по ООП — это талмуд. Вероятность того, что вам подойдет «паттерн» — примерно 50%. Как встретить динозавра на Невском. Знание паттернов полезно в той же степени, что и теология, — и примерно тем же по специальности людям. Всегда полезно уметь отличать по запаху Пана от простого фавна, но практических применений такой эрудиции — не существует.

Зайду с козырей: КДПВ этой заметки имеет прямое отношение к тексту.

Если вы сфокусируете взгляд на синей рамке, вы увидите растопырившего лапы Амбидиректуса с вытянутой шеей и маленькой головой, развернутой влево. Перефокусируясь на красную рамку, вы познакомитесь с его приготовившимся нырнуть в стену справа Alter Ego, с плотно ввинченной в шею головой и замершими во взмахе назад передними конечностями.

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

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

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

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

Я решил опубликовать перевод этой статьи после публикации моего варианта, в котором объясняю, что такое эффект.

Привет, Хабр!

Вот варюсь я в этом айти уже долгое время. Почитываю Хабр, ищу работу, работаю, потом снова ищу работу. Посмотрел разные компании изнутри, крупные и не очень. Сходил за свою жизнь на 25+ собеседований, еще до времен удаленки и на на ней.

Я честно, не знаю как в других профессиях, но в программировании, как мне кажется, собеседования — это чистая лотерея. Мое видение этого возможно подтверждает рынок труда — накрути себе опыта побольше, примени нейросеть, расскажи красиво о себе и вот работа (зарплата) мечты уже твоя. Следствием этого — по 300 отзывов на вакансию. Но, к слову, вакансии эти висят месяцами. Ты просто попадаешь в огромную кучу кандидатов, которых работодатель хочет отсеять и выбрать лучшего из вас. По каким критериям (по всем кроме трудовой книжки) вас будут сортировать одному Нео известно. Так‑же имел личный опыт, когда я отвечал полностью на все вопросы в течение часа. Получив оценку своим знаниям на 5+, заветную работу (зарплату) мечты я так и не получил.

Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.

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

Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

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

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

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

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

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

Я подробно описываю, как моя реализация решает сложности AWS SDK и делает его использование более надежным.

Буду рад узнать ваш подход к работе с ошибками, пишите в комментарии. Спасибо!

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

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

Современный React все больше соответствует идеалам функционального программирования.

Ежедневно мы пользуемся подходами из мира ФП, зачастую даже не подозревая об этом.

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

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

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

Честно говоря, я не планировал создавать свой язык, это случилось само собой. Ещё со времен моего знакомства с программированием, больше всего меня волновала именно сложность, присущая любой предметной области и способы борьбы с оной. Чтобы найти такие ответы, которыми смогут воспользоваться и другие люди, я потратил около 10 лет.

Прагматичное функциональное программирование в Java при помощи монады XResult<T>, которая сочетает в себе свойства Optional<T>, Result<T> и Either<L,R>

Завершён перевод книги Люка Бруно «Nix в пилюлях».
Для удобства читателей, собрал ссылки на все двадцать глав в одной публикации — здесь.

Финальная глава! Люка Бруно рассказывает о секретном оружии Nix — хуках. Их используют, когда больше ничего не помогает, в частности, для кросс-компиляции.

Эта глава посвящена деривации stdenv, благодаря которой собирается большинство пакетов из репозитория nixpkgs. Она поддерживает инструментарий GCC, GNU make, autotools и другие распространённые системы сборки.

Для того, чтобы различать пакеты разных версий, Nix хранит их в каталогах с именами, которые содержат хеш. В главе 18 мы разберёмся, как вычисляется этот хеш для файлов, каталогов и tar-архивов.

Знакомимся с интересным трюком, который позволяет функциональному языку Nix делать то, то, что в императивных пакетных менеджерах делается с пол-пинка.
У них там, правда, dependency hell, а в Nix всё чинно и благородно.

Вы начинаете сборку вашего пакета не на пустом месте. Репозиторий nixpkgs, куда входит ваш пакет, при запуске скрипта сборки передаёт ему параметры. В этой главе мы поговорим о двух основных параметрах: system и config.

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

Летом 2023 года к к нам обратилось предприятие химической промышленности крупного Российского холдинга. На нем  много лет использовалась SCADA-система Wonderware InTouch. Из-за санкционных наложений, иностранный вендор расторг контракт на обслуживание и техподдержку. Более того, была предпринята попытка удаленно остановить производство путем отключения серверов SCADA. Последствия удалось минимизировать, изолировав промышленную сеть, однако функционал системы снизился на треть, а ее развитие и масштабирование оказалось невозможным. Нам было необходимо решить следующие проблемы:

1.     Отсутствие возможности обслуживания данной системы. Ввиду того, что данную SCADA систему разрабатывала и обслуживала иностранная компания, после начала СВО все контракты по обслуживанию и технической поддержке были расторгнуты. 

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