Как стать автором
Поиск
Написать публикацию
Обновить
16.7

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

От Lisp до Haskell

Сначала показывать
Порог рейтинга
Уровень сложности

Управление состоянием приложения с RxJS/Immer как простая альтернатива Redux/MobX

Время на прочтение6 мин
Количество просмотров6K
"Вы поймете, когда вам нужен Flux. Если вы не уверены, что вам это нужно, вам это не нужно." Пит Хант


Для управления состоянием приложения я как правило применяю Redux. Но не всегда есть необходимость в использовании модели Action\Reducer, хотя бы из-за трудозатратности ее применения для написания простейшего функционала. Возьмем в качестве примера обычный счетчик. На выходе хотелось получить простое и практичное решение, которое позволит описать модель состояния и пару методов его меняющие, наподобие такого:


state = {value: 0} 
increase() { 
  state.value += 1 
} 
decrease() {
  state.value -= 1
}

Сходу кажется, что такое решение может обеспечить MobX, так почему бы им и не воспользоваться? Поработав с MobX некоторое время, для себя пришел к выводу, что лично мне проще оперировать последовательностью иммутабельных состояний (наподобие Redux), чем логикой мутабельного состояния (наподобие MobX), да и его внутреннюю кухню я бы не назвал простой.


В общем, захотелось найти простое решение для управления состоянием, в основе которого лежала бы иммутабельность, с возможностью применять его в Angular\React и реализованное на TypeScript. Беглый обзор на просторах github подходящего решения не выдал, поэтому возьмем RxJS/Immer и попробуем сделать свое.

Читать дальше →

Применение принципов функционального программирования при проектировании ERP

Время на прочтение13 мин
Количество просмотров12K
Привет, Хабр!

В этой статье мы попробуем взглянуть на архитектуру учетных систем (ERP, CRM, WMS, MES, B2B, ...) с позиций функционального программирования. Существующие системы сложны. Они базируются на реляционной схеме данных, и имеют огромный мутабельный стейт в виде сотен связаных таблиц. При этом единственным «источником правды» в таких системах является хронологически-упорядоченный журнал первичных документов (отпечатков событий реального мира), которые, очевидно, должны быть иммутабельными (и это правило соблюдается в аудируемых системах, где корректировки «задним числом» запрещены). Журнал документов составляет от силы 20% объема БД, а все остальное — промежуточные абстракции и агрегаты, с которыми удобно работать на языке SQL, но которые требуют постоянной синхронизации с документами, и между собой.

Если вернуться к истокам (устранить избыточность данных и отказаться от хранения агрегатов), а все бизнес-алгоритмы реализовать в виде функций, применяемых непосредственно к потоку первичных документов — мы получим функциональную СУБД, и построенную на ней функциональную ERP. Проблема производительности решается благодаря мемоизации, а объем функционального кода будет вполне соизмерим с объемом декларативного SQL, и не сложнее для понимания. В данной статье мы продемонстрируем подход, разработав простейшую файловую СУБД на языке TypeScript и рантайме Deno (аналог Node.js), а также протестируем производительность сверток на примере типичных бизнес-задач.

Почему это актуально


1) Мутабельный стейт + избыточность данных — это плохо, особенно когда необходимо обеспечивать его постоянную синхронизацию с потоком документов. Это источник потенциальных расхождений учетных данных (баланс не сходится) и трудно обнаруживаемых побочных эффектов.
Читать дальше →

Почему Rust должен стать функциональным языком программирования

Время на прочтение5 мин
Количество просмотров15K
Привет, Хабр!

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

  1. Для императивной реализации — выигрыш от Rust получился всего 20 %. Это означает, что JVM вплотную приблизилась к нативной производительности, и тут уже нечего улучшать.
  2. Для функциональной реализации — Rust оказался быстрее в 4.5 раза, потребление памяти снизилось в 5.5 раза, а отсутствие сборщика мусора сделало программу более стабильной (меньше разброс показателей). Это интересно для тех, кто хочет писать быстрые функциональные программы.
  3. Концепция единственного владельца данных (и единственной мутабельной ссылки), принятая в Rust, очень близка концепции иммутабельности, в результате чего функциональные алгоритмы, основанные на неизменяемости, рекурсии и копировании, легко ложатся на Rust практически без переписывания, тогда как императивные алгоритмы заставляют редизайнить код, учитывать мутабельность ссылок, времена жизни, и т.д.

Вывод — Rust как будто специально создан для ФП, хотя возможности его синтаксиса пока не дотягивают до Scala.
Читать дальше →

Функциональное программирование с точки зрения EcmaScript. Рекурсия и её виды

Время на прочтение4 мин
Количество просмотров12K
Привет, Хабр!

Сегодня мы продолжим наши изыскания на тему функционального программирования в разрезе EcmaScript, на спецификации которого основан JavaScript. В предыдущих статьях цикла были рассмотрены следующие темы:

  1. Чистые функции, лямбды, имутабельность
  2. Композиция, каррирование, частичное применение
Читать дальше →

Ненормальное реактивное программирование

Время на прочтение9 мин
Количество просмотров9.7K

Еще одна статья про реактивное программирование. И только не надо на этой строчке закатывать глаза и томным голосом говорить вслух — "Ну что еще ты можешь мне рассказать про реактивное программирование… а?". Она немного отличается от кучи других, написаных словно под копирку, поэтому некоторые вещи в ней могут показаться… странными или даже совершенно неуместными, как сортирный юмор.


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


Будет интересно.

Читать дальше →

Эксперимент VonmoTrade. Часть 1: Биржи и современные технологии

Время на прочтение4 мин
Количество просмотров3K

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


Цели эксперимента:


  • Более глубокое понимание предметной области и улучшение технической экспертизы
  • Выявление сильных и слабых сторон использования функциональных языков и проектов с открытым исходным кодом при разработке торговых систем
    В этой статье представлена мотивационная часть проекта и декомпозиция задачи.
Читать дальше →

Еще один DSL для валидаций

Время на прочтение5 мин
Количество просмотров1.8K

Недавно я написал небольшой гем для валидаций и хотел бы поделиться с вами его реализацией.


Идеи, которые преследовались при создании библиотеки:


  • Простота
  • Отсутствие магии
  • Легкость в освоении
  • Возможность кастомизации и минимум ограничений.

Почти все эти пункты завязаны на первом — простоте. Итоговая реализация невероятно маленькая, поэтому я не отниму у вас много времени.


С исходным кодом можно ознакомиться здесь.

Читать дальше →

Функциональное программирование — это не то, что нам рассказывают

Время на прочтение17 мин
Количество просмотров129K

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



Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:


int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде


int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.


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

Читать дальше →

Стажировка в «Ростелеком-Солар»: качаем Scala-скиллы

Время на прочтение3 мин
Количество просмотров5.3K
Всем привет!

Для тех, кто мечтает стать Senior Developer и готов присоединиться к крутой команде Scala-разработчиков, с 1 по 15 декабря 2019 года мы запускаем отбор на бесплатный курс по обучению Scala. По окончании обучения пятеро лучших стажеров смогут присоединиться к самой солнечной в мире команде.

image

Подробности — под катом.
Читать дальше →

Прагматическое функциональное программирование

Время на прочтение6 мин
Количество просмотров6.4K
Привет, Хабр! Предлагаю вашему вниманию перевод статьи «Pragmatic Functional Programming» автора Robert C. Martin (Uncle Bob).

Переход к функциональному программированию всерьез развился только около десяти лет назад. Мы видим, что такие языки, как Scala, Clojure и F# привлекают внимание. На самом деле это был большой шаг в программировании: “О, круто, новый язык!” — энтузиазм… Видимо там было что-то особенное — ну или это мы так думали.  

Закон Мура гласит нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Данный закон действовал с 1960-х до 2000 годов. Затем он прекратился. Частота достигла 3 ГГц, а затем и вовсе поднялась на плато. Мы достигли скорости света! Сигналы не могут распространяться по поверхности чипа достаточно быстро, чтобы обеспечить более высокие скорости. 

Это привело к тому, что инженеры оборудования изменили свою стратегию. В попытках увеличить пропускную способность, они добавили больше процессоров (ядер). А чтобы освободить место для этих ядер, они удалили большую часть оборудования для кэширования и конвейеризации из чипов. Из-за этого процессоры стали намного медленнее, чем раньше; однако их стало больше. В итоге увеличилась пропускная способность. 
Читать дальше →

Пробуем улучшенный оператор instanceof в Java 14

Время на прочтение6 мин
Количество просмотров27K
Не за горами новая, 14-я версия Java, а значит самое время посмотреть, какие новые синтаксические возможности будет содержать эта версия Java. Одной из таких синтаксических возможностей является паттерн-матчинг по типу, который будет осуществляться посредством улучшенного (расширенного) оператора instanceof.

Сегодня я хотел бы поиграться с этим новым оператором и рассмотреть особенности его работы более детально. Так как паттерн-матчинг по типу ещё не вошёл в главный репозиторий JDK, мне пришлось скачать репозиторий проекта Amber, в котором ведётся разработка новых синтаксических конструкций Java, и собрать JDK из этого репозитория.
Читать дальше →

Монада «Reader» через async/await в C#

Время на прочтение9 мин
Количество просмотров7K


В моей предыдущей статье я описал, как реализовать паттерн "Монада Maybe" с помощью операторов async / await. В этот раз я расскажу, как реализовать другой популярный шаблон проектирования "Монада Reader", используя те же приемы.


Этот шаблон позволяет неявно передать некий контекст в иерархию вызовов функции без использования параметров или полей классов, и его можно рассматривать как еще один способ реализации внедрения зависимости (Dependency Injection). Например:

Читать дальше →

Пять вопросов о проектировании языков программирования

Время на прочтение10 мин
Количество просмотров6.4K


Руководящая философия



1. Языки программирования для людей


Языки программирования это то, как люди говорят с компьютерами. Компьютер будет рад поговорить на любом языке, который не будет двусмысленным. Причина почему у нас есть высокоуровневые языки — потому что люди не могут справиться с машинным языком. Суть языков программирования в том, чтобы предотвратить наш бедный хрупкий человеческий мозг от перегрузки массой деталей.
Читать дальше →

Ближайшие события

API для удаленной асинхронной выборки с помощью Apple Combine

Время на прочтение17 мин
Количество просмотров15K


Combine — это функциональный реактивный Swift фреймворк, который недавно реализован для всех платформ Apple, включая Xcode 11. С помощью Combine очень легко обрабатывать последовательности асинхронно появляющихся во времени значений values. Он также позволяет упростить асинхронный код, отказавшись от делегирования и сложных вложенных callbacks.

Но изучение самого фреймворка Combine на первых порах может показаться не таким уж простым. Дело в том, что основными «игроками» Combine являются такие абстрактные понятия, как «издатели» Publishers, «подписчики» Subscribers и операторы Operators, без которых не удастся продвинуться в понимании логики функционирования Combine. Однако благодаря тому, что Apple предоставляет разработчикам уже готовых «издателей», «подписчиков» и операторов, код, написанный с помощью Combine, оказывается очень компактным и хорошо читаемым.

Вы увидите это на примере приложения, связанного с асинхронной выборкой информации о фильмах из очень популярной сейчас базы данных TMDb. Мы создадим  два различных приложения: UIKit и SwiftUI, и покажем, как с ними работает Combine.


Читать дальше →

Что сделало Lisp особенным

Время на прочтение3 мин
Количество просмотров15K
"Величайший из когда-либо созданных языков программирования"
— Alan Kay, «on Lisp»



Когда Маккарти разработал Lisp в конце 1950-х, он радикально отличался от существующих языков, самым главным из которых был Fortran.
Читать дальше →

По следам русского Scala-движа. Часть 3

Время на прочтение19 мин
Количество просмотров3.1K
Это заключительная часть расследования о Scala-движении в России. В первой части я узнал от Романа Гребенникова о воронежском бомонде, C++ и Erlang, а от Романа Тимушева о первой Akka и рождении московских митапов. Во второй части побеседовал с Александром Подхалюзиным и Михаилом Муцянко: знакомство со Scala, 2007-й, Scala Days, Scala Native, переход в Kotlin, чем Scala хороша для банков, первые ивенты в Санкт-Петербурге, Eclipse, Jason Zaugg, IDE и Scala Plugin.



Во время подготовки второй части Владимир Успенский (vuspenskiy) направил меня к Александру Подхалюзину, с которым мы записали огромное интервью. На следующий день я получил от Владимира сообщение, но теперь уже с его личной историей: Qiwi, Scala в Тинькофф, первые встречи, ссылки на старые блоги (отдельное спасибо за это), и функциональщина из 2008 от Rúnar, которая исполняется на Java, — это та еще кровь из глаз как минимум необычно. В дополнение — истории Романа Елизарова, Алексея Фомкина и Николая Татаринова. Особенности найма Scala-разработчиков, курсы на Coursera, «идеальный код», «демоническая» компиляция, дизайн в Kotlin, 10 000 строк кода, интернет-банк Тинькофф, опять Тинькофф, Play Framework, скончавшийся Flash, «Восход» и питерские митапы — обо всем этом в заключительной части трилогии под катом.
Читать дальше →

Превращая FunC в FunCtional с помощью Haskell: как Serokell победили в Telegram Blockchain Competition

Время на прочтение9 мин
Количество просмотров6K

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


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


Но давайте начнем с небольшого погружения в контекст.

Читать дальше →

Три парадигмы

Время на прочтение3 мин
Количество просмотров11K
Привет, Хабр!

Предлагаю вашему вниманию перевод статьи «Three Paradigms» автора Robert C. Martin (Uncle Bob).

image

За последние 40 лет технологии аппаратного обеспечения увеличили вычислительную мощность наших устройств более чем на двадцать порядков. Теперь мы играем в Angry Birds на наших телефонах, которые обладают вычислительной мощностью суперкомпьютера 70-х годов прошлого века с фреоновым охлаждением.

Но за те же 40 лет технологии программного обеспечения практически не изменились. В конце концов, мы все так же применяем операторы if, while loops и операторы присваивания, которые мы использовали еще в 60-х годах. Если бы я взял программиста из 1960 года и привел его сюда, чтобы он посидел за моим ноутбуком и написал код — ему понадобилось бы 24 часа, чтобы оправиться от шока, но он смог бы написать этот код. Принципы не так сильно изменились.

В процессе написания программ изменились три вещи. Я говорю не об оборудовании, не о скорости компьютера и не о невероятных инструментах, которые у нас есть. Я имею в виду сам код. Три вещи изменились в коде. Можно их назвать парадигмами. И все они были «открыты» за одно десятилетие более 40 лет назад.
Читать дальше →

Краеугольные камни уничтожения медленного кода в Wolfram Language: ускоряем код в десятки, сотни и тысячи раз

Время на прочтение77 мин
Количество просмотров13K
Скачать файл с кодом и данные можно в оригинале поста в моем блоге

Картинка к вебинару и посту взята не просто так: в определенном смысле символьное ядро Wolfram Language можно сравнить с Таносом — если бы его мощь была бы направлена в правильное русло, он мог бы стать самым мощным и полезным «добряком». Так же и с символьным ядром Wolfram — его чудовищную мощь нужно правильно использовать, а если это делать не так, оно может стать настоящим «злом», замедляющим все очень сильно. Начинающие разработчики не знают многих важнейших парадигм, идей и принципов языка Wolfram Language, пишут код, который на самом деле дико неэффективен и после этого разочаровываются, хотя тут нет вины Wolfram Language. Эту ситуацию призвана исправить эта статья.

Мне довелось работать с Wolfram Language начиная с (уже довольно далекого) 2005 года (тогда еще была версия Mathematica 5.2, сейчас уже 12-я). За эти почти 15 лет произошло очень много: добавились тысячи новых встроенных функций и областей, в которых они работают (машинное обучение, точная геометрия, работа с аудио, работа в вебе, облачные возможности, глубокая поддержка единиц измерения, интеграция с базами данных Wolfram|Alpha, географические вычисления, поддержка работы с CUDA, Python, распараллеливание операций и многое многое другое), появились новые сервисы — облако Wolfram Cloud, широко известная система вычислительных значeний Wolfram|Alpha, репозиторий функций, репозиторий нейросетей и пр.

Книга Алана Тьюринга и загадочная записка — Научный детектив

Время на прочтение30 мин
Количество просмотров11K

Оригинал перевода в моём блоге

Как ко мне попала эта книга?


В мае 2017 года я получил электронное письмо от моего старого учителя средней школы по имени Джордж Раттер, в котором он писал: «У меня есть копия большой книги Дирака на немецком языке (Die Prinzipien der Quantenmechanik), которая принадлежала Алану Тьюрингу, и после того как я прочел вашу книгу Создатели идей (Idea Makers), мне показалось само собой разумеющимся, что вы именно тот человек, которому она нужна». Он объяснил мне, что получил книгу от другого (к тому времени умершего) моего школьного учителя Нормана Рутледжа, о котором я знал, что он был другом Алана Тьюринга. Джордж закончил свое письмо фразой: «Если вам нужна эта книга, я мог бы вручить ее вам в следующий раз, когда вы приедете в Англию».

Спустя пару лет в марте 2019 года я действительно прибыл в Англию, после чего договорился с Джорджем о встрече за завтраком в небольшом отеле в Оксфорде. Мы ели, болтали и ждали, пока еда уляжется. Затем настал подходящий момент для обсуждения книги. Джордж сунул руку в портфель и вытащил довольно скромно оформленный, типичный академический томик середины 1900-х годов.



Я открыл обложку, размышляя, не может ли на ней быть с обратной стороны надписи: «Собственность Алана Тьюринга» или чего-то в этом духе. Но, к сожалению, это оказалось не так. Тем не менее к ней была приложена достаточно выразительная записка на четырех листах от Нормана Рутледжа к Джорджу Раттеру, написанная в 2002 году.

Я знал Нормана Рутледжа, когда еще был учеником средней школы в Итоне в начале 1970-х годов. Он был учителем математики по прозвищу «Чокнутый Норман». Он был приятным во всех отношениях преподавателем и рассказывал бесконечные байки о математике и о всяких других занимательных вещах. Он был ответственным за то, чтобы школа получила компьютер (программируемый с помощью перфоленты шириной с парту) — это был самый первый компьютер, который я когда-либо использовал.
Читать дальше →

Вклад авторов