Haskell *

Всем привет!

Идея 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 операций, а лишь принимающие на вход некоторые данные и возвращающие их в преобразованном виде. Такого рода чистые блоки по сути представляют из себя функции в математическом смысле слова, принимающие аргумент и возвращающие значение функции, и напоминают программы зари компьютерной эры, когда данные с перфокарт загружались в программу в самом начале её работы, после чего некоторое время обрабатывались, и по итогу работы программы выводила на печать итоговый результат расчётов, при этом в ходе работы программы не предполагалось никакого интерактивного взаимодействия с ней.

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

В этой статье я разберу монаду ContT, и покажу как вернуть return и другие control-flow операторы из императивных языков программирования, которых мне так нехватало, когда я начинал изучать хаскель.

В статье рассматривается 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 и то, какие проблемы он помогает не просто решить, а устранить как явление.

Кликбейтный заголовок, риторический вопрос и обещание раскрыть тайну! Не самый лучший набор, но нормального названия для статьи мне в голову не пришло. Что же здесь все таки будет? Речь пойдет о реализации символьного программирования в Wolfram Language (WL). Я не буду рассказывать про отличия от других парадигм. А также здесь точно не будет общих определений. Вместо этого я попытаюсь ответить на несколько вопросов исходя из своего личного опыта и наблюдений.

Внимание! Я не математик и не знаю haskell и lisp! И буду рад если меня поправят настоящие математики, которые с ними знакомы.

Эта статья первая из цикла, в котором мы будем создавать crackme для linux amd64. В crackme будут реализованы шифрование каждой функции отдельным ключём и наномиты для противодействия отладке. В данной статье мы рассмотрим алгоритм встраивания ключа шифрования в код для усложнения расшифровки функций пользователем. Если стало интересно, прошу под кат.

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

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