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

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

За долгие годы работы с кодом я привык слышать от среднего уровня разработчиков (и от тех, кто выбрал языки, которым требуется бесконечная генерация бойлерплейта): «Продуктивность программиста напрямую зависит от IDE». При том, что я всегда производил в несколько раз больше самого сложного в компании кода, используя vim с минимумом плагинов. Подсветка синтаксиса мне помогает, тут (как, впрочем, и почти везде) я с Пайком не согласен. Автодополнение — уже нет, я его иногда включаю «еще раз попробовать, вдруг это со мной что-то не так», и когда читаю курсы — но в основном мне мешают выскакивающие окошки: отвлекают, распыляют внимание, наталкивают на ложный путь.

TL;DR: Нет. Хорошо спроектированный язык в развитии не нуждается.

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

Более того, ниже я постараюсь уложиться в нескольких абзацев, чтобы рассказать, какие требования лично я предъявляю языку программирования в 2025 году, и почему этому «идеалу» просто некуда «развиваться».

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

Наверно, читающие мой блог знают, что последние несколько лет я время от времени экспериментировал с OCaml, и я могу с уверенностью сказать, что он стал одним из моих любимых языков программирования наряду с Ruby и Clojure. Недавно работа с OCaml привлекла моё внимание к F# — это разработанный компанией Microsoft ML (Meta Language) для .NET , функциональная копия объектно-ориентированного (по большей мере) C#. Самый новый ML-язык…

Все современные средства разработки — практически без исключения — наделены двумя родовыми травмами. Они не дают доступа к чуть более низкому софтверному уровню (синтаксическому дереву) без помощи сторонних хаков и ориентированы на синхронное исполнение.

Прежде, чем продолжить, я сразу оговорюсь: я не имею в виду узкоспециализированные задачи, типа написания драйверов, программирования контроллеров и прочей околожелезной разработки; там другие правила. Я говорю про мир приложений: от инди-игр до энтерпрайза. Языки высокого уровня, на которых сегодня ведется более (оценка навскидку) 98% всей разработки продуктов для конечного пользователя, лишены примитивов представления AST и параллельного (не путать с асинхронным) исполнения.

Эта статья рассказывает о интеграционных пакетах AI от Effect – наборе инструментов для упрощения работы с крупными языковыми моделями (LLM) в современных приложениях. В ней подробно описывается, как можно использовать универсальные сервисы для разработки AI‑функционала, не привязываясь к конкретному провайдеру, что позволяет сократить объем «клейкого кода» и снизить технический долг.

Авторы делятся опытом создания системы, в которой взаимодействия с LLM становятся максимально удобными и гибкими. Рассматриваются вопросы тестирования, параллельного выполнения запросов, стриминга ответов и мониторинга производительности – всё это делает интеграцию с AI не только мощным, но и надежным решением для разработки сложных приложений.

Данная статья будет полезна разработчикам, стремящимся внедрить передовые технологии AI в свои проекты без лишних сложностей. Она показывает, зачем нужен подход, независимый от провайдера, и почему использование Effect может значительно упростить жизнь при работе с различными поставщиками LLM.

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

Книги делятся на две категории: 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 в пилюлях».
Для удобства читателей, собрал ссылки на все двадцать глав в одной публикации — здесь.