От Lisp до Haskell
Время от времени мне нужно выполнить примитивный сценарий в терминале, но каждый раз это заканчивается очередным гуглежом «bash iterate each file» или «bash file has string». А что если скрипты в терминале можно было бы писать прямо как поток декларативных мыслей?
TL;DR: Затем, что с ним код чище, читаемее и предсказуемее ;)
Старый объектно-ориентированный или императивный подход к программированию несёт в себе множество проблем, которые решает функциональное программирование. Даже в современной среде все до сих пор считают, что объектно-ориентированное программирование — правильное программирование, а функциональное — «для математиков и задротов», или вообще даже для варваров, которые даже не слышали об объектной и императивной «цивилизации».
Привет, Хабр!
Парсер‑комбинаторы и синтаксический анализ в целом — очень интересные темы. Однако материалов со сравнительно низким порогом входа маловато, а в существующих статьях на читателя сразу обрушивается поток терминов и формальностей.
Эту статью я позиционирую как введение в парсер‑комбинаторы «для чайников» (или «для самых маленьких» — как вам больше нравится). Цель: попытаться рассказать простым языком и с примерами так, чтобы Вы могли после прочтения написать свой парсер без какого‑либо предварительного опыта и знаний в области синтаксического анализа.
Приятного чтения!
Программирование прямо сейчас переживает сдвиг в подходе к работе.
Если раньше основной процесс выглядел как «сел и пишешь код руками», продумываешь архитектуру, разбираешься с документацией и часами ищешь ошибки, то теперь всё чаще сценарий другой: ты формулируешь задачу, а реализацию на себя берёт ИИ.
Это и называют вайбкодингом.
Ты не работаешь на уровне синтаксиса — ты работаешь на уровне идеи. Задаёшь направление, описываешь поведение, уточняешь детали, а модель превращает это в код и структуру проекта.
Но здесь важно не попасть в иллюзию. Это не автоматическая разработка и не кнопка «сделать всё». Это инструмент, который даёт ускорение, но только если ты контролируешь процесс и понимаешь, что происходит.
TypeScript прочно закрепился в роли основного языка для типизированной разработки на JavaScript. Его система типов предоставляет множество мощных инструментов: дженерики, условные типы, продвинутый вывод типов – всё это позволяет строить надёжные и масштабируемые приложения. Однако даже в таком гибком языке есть ограничения. Одно из них – отсутствие нативной поддержки типов высшего рода (Higher-Kinded Types, HKT). Эта концепция, хорошо знакомая разработчикам на Haskell или Scala, позволяет абстрагироваться не только от конкретного типа (например, string или number), но и от типа-конструктора (например, Array, Promise, Set). Несмотря на то, что запрос на добавление HKT в TypeScript остаётся открытым уже много лет (issue #1213), сообщество научилось эмулировать эту возможность с помощью существующих средств. В этой статье мы разберём, что такое HKT, зачем они нужны в реальных проектах, и как их можно реализовать в TypeScript уже сегодня.
У меня двадцать лет в IT. Большую часть этого времени я проектировал и эксплуатировал инфраструктуру на PostgreSQL. Сейчас работаю архитектором: Go, Python, Postgres, Redis, ClickHouse, мониторинг на десятки тысяч баз. До этого писал на Ruby, пробовал Rust. Классический бэкенд-инженер со всеми вытекающими привычками: императивный код, мутабельное состояние, постоянные if err != nil { return err }.
А потом я начал писать бэкенд на Gleam — молодом функциональном языке на BEAM (Erlang VM), который появился в стабильной версии только в 2024 году. Навык ещё в разработке, но бэкенд уже работает, и я не жалею. Путь был... познавательным.
Эта статья — не туториал и не рекламный буклет. Это честный рассказ о том, почему я выбрал Gleam, какие шишки набил, что мне понравилось настолько, что я не хочу возвращаться, и что до сих пор бесит.
В этот раз мы рассмотрим операции своеобразного «деления функторов». Начнём с обобщения задачи поиска сопряжённых функторов, но потом убедимся, что расширения Кана являются фундаментальной абстракцией, лежащей в основе множества полезных инструментов.
Добро пожаловать в чистилище препроцессора — место, где здравый смысл уступает место макросам. Сегодня мы заставим C++ притвориться Haskell-ем и внедрим do-нотацию, за которую любой адепт «чистого языка» предаст нас анафеме.
Программисты на C++ делятся на два типа: те, кто боится препроцессора, и те, кто познал сие древнее чудо с сишных времён.
Сегодня мы перейдем черту. Функциональное программирование манит своими абстракциями, но когда дело доходит до цепочек вычислений в монадах, C++ встречает нас бесконечными лямбдами и вложенностью, от которой рябит в глазах. В Haskell эта проблема решена элегантным do-синтаксисом. А что, если я скажу, что мы можем получить то же самое в C++, используя лишь тёмную магию макросов, простые шаблоны и полное пренебрежение здравым смыслом?
Приготовьтесь: мы будем дорабатывать парсер и превращать ваш код в нечто, что заставит коллег вызвать экзорциста. Это история о том, как затащить чистую красоту монад в суровый мир C++.
Доброго здоровья!
Предполагается, что статья будет интересна тем, кто любит четкие контракты в своих проектах, строгость и чистоту в инкапсуляции, новые подходы в ООП. А также тем, кто уважает функциональное программирование.
Эти темы и затрагиваются в предлагаемом «Elvis-модификаторе доступа», реализованным через Roslyn Analyzer. Все исходники и nuget пакеты прилагаются.
Effect-фреймворк, который никого не может оставить равнодушным. Читая комментарии к другим постам, я заметил, что добрая часть хабра считает, что эффект это избыточно сложная и не особо нужная технология. В своей статье я обозначаю 10 причин, почему эту технологию стоит попробовать, даже если вы дико предвзятый разработчик, а также даю экскурс по базам фреймворка.
Python славится своей гибкостью. Мы можем передавать функции как аргументы, возвращать их из других функций и даже "записывать" внутрь них состояние. Но как это работает под капотом? И при чем тут странное слово nonlocal?
В этой статье мы проследим эволюцию: начнем с глобальных переменных, разберемся с замыканиями (closures), поймем магию nonlocal, а затем соберем всё это вместе, чтобы понять, как работают декораторы — один из самых элегантных механизмов Python.
Hobbes - это функциональный язык программирования со статической типизацией, написан на С++ и включает JIT-компилятор на базе LLVM. Похож на Haskell, но совсем не такой же революционный и гораздо менее известен. Я немного расскажу, что это за язык и как он устроен внутри.
В этот раз мы проанализируем различные способы факторизации монады на сопряжённые функторы. Прежде всего рассмотрим два полярных варианта, раскрывающих наиболее важные аспекты факторизации. Это даст более глубокое понимание самого понятия монады и послужит мотивацией для построения операции факторизации произвольного функтора.
Всем привет! Меня зовут Сергей и последнее время я занимаюсь backend-разработкой на Scala. Вообще, мой опыт асинхронного программирования на Scala и C# составляет более десяти лет, и за это время сложилось вполне достаточное понимание этой темы. Во всяком случае, тогда мне так казалось…
Но недавно в беседе с коллегами обнаружились большие проблемы в моём «понимании», что мотивировало детально разобраться в этом вопросе.
В мире Python есть особый вид функций — невидимки. У них нет имени, документ-строки и даже нормального тела. Они живут одну строку и умирают, сделав свое дело. Это лямбда-функции.
Многие новички считают их бесполезной игрушкой или, наоборот, пытаются запихнуть всю логику в одну лямбду, превращая код в нечитаемое месиво. В этой статье мы разберемся, где проходит эта грань. Мы не просто выучим синтаксис lambda x: x, мы поймем, как они устроены внутри, как их использовать с инструментами вроде map, filter, sorted, и главное — когда от их использования стоит категорически отказаться.
Работа с переменными в Python кажется очевидной до тех пор, пока код не начинает вести себя неожиданно. Ошибки с UnboundLocalError, странное поведение замыканий или некорректная работа global и nonlocal - всё это следствие непонимания области видимости.
В Python действует чёткое правило разрешения имён - LEGB. Разберёмся, как оно работает и какие ловушки скрываются под капотом.
В статье рассматривается реальная ограниченность современных больших языковых моделей (LLM) при разработке сложных электромеханических систем, включающих аналоговые и цифровые датчики, шаговые и серво‑приводы, а также различные исполнительные устройства. Показано, что хотя нейросети способны быстро генерировать черновые схемы, фрагменты кода и шаблоны технической документации, они не обладают знанием физического контекста, параметров компонентов, нормативных требований и бизнес‑целей проекта. Поэтому без участия инженера‑генератора идеи и программиста‑интегратора полученный результат остаётся непроверенным и потенциально ошибочным. Приведены практические примеры из реальных проектов (генерация драйверов для шаговых двигателей, автоматическое написание тест‑скриптов, составление ТЗ и подбор компонентов), где LLM выступали лишь ускоряющим инструментом. Описаны рекомендации по эффективному использованию нейросетей: чёткое ТЗ, разбиение задачи на небольшие блоки, обязательная верификация и сохранение контекста. Делается вывод, что нейросети сейчас являются полезными помощниками, но не заменой человеку в роли идеи и интеграции.
Два месяца назад я писал на Хабр о первом релизе Funxy — гибридного языка программирования. Тогда это был эксперимент по созданию своего языка с выводом типов, императивного, с функциональными возможностями.
С тех пор вышло несколько релизов. Мы исправили много ошибок, переписали рантайм и добавили недостающие инструменты. Хочу рассказать, что изменилось.
Стабильность: десятки багфиксов — падения на валидном коде, рекурсия, edge-кейсы VM
Рантайм: tree-walk интерпретатор → стековая VM (быстрее, легче по памяти)
Язык: const, return, лямбды (\x -> x + 1), list comprehensions, block syntax для DSL
Типы: strict mode, flow-sensitive typing
Тулинг: LSP и дебаггер
Embedding: встраивание Funxy в Go-приложения как скриптовый движок
Здравствуйте, меня зовут tmaxx, и я алкоголик понял что такое монады. И, естественно, рассказываю об этом всем вокруг, в том числе и вам. Конечно, это Далеко Не Первая Статья О Монадах на Хабре, но ещё один альтернативный взгляд на проблему, думаю, не помешает.
«Монада», как известно, это «моноид в моноидальной категории эндофункторов», что дает примерно ноль информации несведущему человеку. В программировании, можно попробовать определить монаду как «штуку, реализующую вот такие методы»:
(>>=) :: forall a b. m a -> (a -> m b) -> m b return :: a -> m a
Не понятно на Хаскеле? Вот примерный эквивалент на Java:
<A, B> Monad<B> bind(Monad<A> ma, Function<A, Monad<B>> famb);
<A> Monad<A> ret(A a);
Все равно остались вопросы? Почему именно такая сигнатура? Что в ней такого особенного, что она используется абсолютно во всех реальных программах написанных на функциональных языках? Попробуем разобраться.
В Python код является данными. Функции, классы, модули и даже стек вызовов можно исследовать во время выполнения программы. Этот механизм называется интроспекцией.
Интроспекция активно используется во фреймворках, логировании, тестах, dependency injection контейнерах и отладчиках. При этом многие разработчики пользуются ей неосознанно.
Разберем, что это такое, зачем нужно и как применяется на практике.