Haskell *

Мотивацией для написания этого поста стали два года собеседований JS/TS-инженеров. Я интересуюсь языками и функциональным программированием, поэтому всегда «разбавлял» технические вопросы разговором о парадигмах. И заметил любопытную асимметрию.

Об ООП кандидаты рассуждали уверенно — но в основном на концептуальном уровне, не вдаваясь в то, как именно ООП реализовано в JavaScript. С FP картина была другой: уверенности меньше, зато критика — конкретная и повторяющаяся: «иммутабельность дорогая по памяти», «рекурсия небезопасна из-за стека». Что характерно — эти аргументы почти всегда были сформулированы через опыт работы с JS, а не с Haskell, Clojure или Scala.

Это важная деталь. Любая парадигма существует на двух уровнях: концептуальном (идеальная модель) и имплементационном (как конкретный язык эту модель выражает). Судить о FP по JS — примерно то же самое, что судить об ООП по bash-скриптам с глобальными переменными.

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

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

Именно так устроен мир программирования. Проблема очевидна любому, кто хоть раз пытался написать инструмент для анализа кода. Допустим, вы создали превосходный анализатор цикломатической сложности для Python. Он великолепен: находит вложенные условия, считает точки ветвления, рисует графы потоков управления. Затем к вам приходит коллега и спрашивает: «А для Ruby сделаешь?» И тут выясняется, что весь ваш труд – все эти обходчики деревьев, все эти паттерн-матчинги над питоновским AST – нужно переписать заново. С нуля. Для другого дерева, с другими узлами, другой семантикой и другими подводными камнями. А потом придет третий коллега и попросит то же самое для Haskell.

История о том, как я выпустил популярный ORM в 2012 году… потом похоронил его… потом осознал, что база данных должна быть единственным источником правды. И к чему это привело.

Эта статья, по сути, родилась как развёрнутая версия комичной зарисовки, которую вы видите выше.

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

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

Всем привет!

Идея LensDB родилась с простого поста моего друга. он делился своим опытом создания Shared Memory кэша для своего пет-проекта на C#. В этом посте он написал:

Многие мои собеседники "стопроцентно" уверяли меня, что сама суть функционального программирования заключается в повсеместном использовании map, filter и reduce; что эти функции превосходят циклы for во всём, настолько, что их нужно запихнуть в каждый возможный язык безо всякого анализа затрат и выгод, потому что выгоды настолько несравненно потрясающие, что затраты просто не могут иметь значения. А само сомнение в этих затратах уже доказывает, что я ничего не понял. Поэтому пора задать главный вопрос: действительно ли именно они (map, filter и reduce) и есть ядро функционального программирования?

К чёрту теорию; давайте посмотрим на практику. Давайте взглянем на реальный проект на Haskell. Я знаю два крупных проекта на Haskell, которые вышли за пределы хаскель-экосистемы и стали полезными программами, которые люди скачивают: xmonad и pandoc. Но xmonad - странная программа: она делает массу привязок к библиотекам C и взаимодействует со всевозможными системными сервисами…Что, конечно, неплохо, как говорится, но из-за этого она не очень типична. А вот pandoc - это чистейший Haskell: парсинг, работа с абстрактным синтаксическим деревом, его трансформация и генерация; т.е., по сути, огромный компилятор для документов. Более «хаскельским» код быть не может. Давайте посмотрим на него.

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

Разберем пример: напишем простой валидатор и посмотрим каким образом пригодится Applicative.

Определим пользователя:

Писать код, который достаточно бегло просмотреть — не менее важно, чем писать код, который в принципе можно прочитать. Давайте немного поговорим о «форме» кода — такой, чтобы по структуре кода можно было быстро понять, для чего он, и сократить время работы с кодовой базой.

В этой статье я хотел рассказать об интересном подходе к построению программ, описанному в книге Sandy Maguire, Algebra-Driven Design. Подход позволяет строить программы на основе абстрактных математических структур и законов. Это позволяет разработать обобщенные подходы к их созданию и тестированию. Но потом я понял, что в этом мало смысла без объяснения, почему такой подход в принципе имеет право на существование. В книге для примеров используется Haskell - ленивый, чистый функциональный язык, имеющий крайне мало отношения к языкам, которые широко применяются на практике. Распространено мнение, что приемы, используемые в Haskell, существуют в основном для преодоления его же недостатков и в других языках не нужны. Например, про монады пишут, что это оторванная от реальной жизни абстракция, которую не встретить в повседневной работе. Нет ничего более далекого от истины.

Монады - это не костыль, а мощная абстракция, которая позволяет выявить связь между такими непохожими языками, как C и Haskell, и свести к одному знаменателю такие далекие друг от друга концепции как асинхронные функции и глобальные переменные. Так что в этой статье я ограничусь описанием алгебраического программирования на примере монады. Я по шагам пройду путь от классической, сравнительно бесполезной в динамически типизированных языках монады, до Freer монады, которая обладает настолько удивительными свойствами, что может найти применение даже в императивном языке. Вы убедитесь, что алгебраический подход применим в обычных языках и дает превосходные результаты.

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

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

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

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

Haskell входит в число наиболее востребованных функциональных языков программирования. Для него характерна полная, строгая и статическая типизация и поддержка так называемых «ленивых» вычислений. Первоначально язык применялся в качестве инструмента для сугубо научных математических изысканий, но постепенно стал одним из наиболее востребованных на практике языков.

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

В статье описывается механизм создания собственного модифицированного варианта монады IO в Haskell, с ограничениями операций ввода-вывода.

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

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

В статье рассматривается Continuous Deployment для БД с бесшовными релизами за счёт обратно-совместимых обновлений и автоматизации проверок совместимости с помощью подхода DB-First.

Можно ли внедрить в Haskell постфиксный калькулятор?

begin push 1 push 2 add end
begin push 1 push 2 push 3 add mul end

На первый взгляд такой код на Haskell не может работать. Функция begin должна иметь произвольное количество аргументов, а Haskell является языком со статической типизацией. Но на самом деле, для написания вариативных (polyvariadic) функций достаточно полиморфизма.

На уходящей неделе мне попалась симпатичная, хоть и не новая мини‑серия статей на Дзен‑канале @zdgzdgzdg про процедурную генерацию лабиринта методом «коллапса волновой функции». Пока я читал эти статьи и знакомился с кодом, меня осенило: ведь это же вычисления в комонаде, погружённые в монаду! Я не издеваюсь, действительно, речь идёт о композиции двух паттернов функционального программирования: комонады Zipper, превращающей локальные правила в глобальное состояние, и монады Random, позволяющей генерировать случайные объекты.

И вот, в качестве баловства на выходных, я решил реализовать этот «квантовый» алгоритм генерации лабиринтов на Haskell, используя и комонады и монады, и вообще, ни в чëм себе не отказывая. И хотя язык программирования Haskell нужен не только для извращений, но именно для них он подходит идеально!

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

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