Мотивация

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

Мне не хватало хорошего примера, где бы окупались усилия, потраченные на освоение "матчасти". Для меня одним из самых удачных таких примеров оказались парсеры. Теперь я довольно часто рассказываю про них, когда у меня спрашивают, для каких распространённых задач можно красиво использовать Haskell.

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

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

Привет!

Подумал я тут рассказать вам о том, как в JavaScript с помощью библиотеки Fluture можно создавать и использовать ленивые функции. Это будет краткий обзор на то, как создавать функции, как обрабатывать ошибки и чуть-чуть про параллелизм. Функциональным программированием мозги парить не буду! Обещаю!

Привет, Хабр!

Все любят runtime exceptions. Нет лучшего способа узнать о том, что что-то не было учтено при написании кода. Особенно — если исключения обваливают приложение у миллионов пользователей, и эта новость приходит паническим email'ом с портала аналитики. В субботу утром. Когда ты в загородной поездке.

После подобного всерьез задумываешься о обработке ошибок — и какие же возможности предоставляет нам Kotlin?

Первым на ум приходит try-catch. По мне — отличный вариант, но у него есть две проблемы:

1. Это как-никак лишний код (вынужденная обертка вокруг кода, не лучшим образом сказывается на читаемости).
2. Не всегда (особенно при использовании сторонних библиотек) из блока catch возможно получить информативное сообщение о том, что конкретно вызвало ошибку.

Давайте посмотрим во что try-catch превращает код при попытке решения вышеозвученных проблем.

Автор материала, перевод которого мы публикуем сегодня, говорит, что он, после того, как долго занимался объектно-ориентированным программированием, задумался о сложности систем. По словам Джона Оустерхаута, сложность (complexity) — это всё, что делает тяжелее понимание или модификацию программного обеспечения. Автор этой статьи, выполнив некоторые изыскания, обнаружил концепции функционального программирования наподобие иммутабельности и чистых функций. Применение таких концепций позволяет создавать функции, не имеющие побочных эффектов. Использование этих функций упрощает поддержку систем и даёт программисту некоторые другие преимущества.



Здесь мы поговорим о функциональном программировании и о некоторых его важных принципах. Всё это будет проиллюстрировано множеством примеров кода на JavaScript.

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



Я расскажу о новом подходе к хранению и обработке информации и поделюсь мыслями о создании платформы разработки в этой новой парадигме.

Существуют различные способы обработки ошибок в языках программирования:

• стандартные для многих языков исключения (Java, Scala и прочий JVM, python и многие другие)
• коды статуса или флаги (Go, bash)
• различные алгебраические структуры данных, значениями которых могут быть как успешные результаты так и описания ошибок (Scala, haskell и другие функциональные языки)

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

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

Сразу отбросим использование кодов и флагов, так как этот подход не принят в JVM языках и по моему мнению слишком подвержен ошибкам (прошу прощения за каламбур). Поэтому будем сравнивать исключения и разные виды АТД. Кроме того АТД можно рассматривать как использование кодов ошибок в функциональном стиле.

UPDATE: к сравнению добавлены исключения без стек-трейсов

Давайте пофантазируем на тему функциональной композиции, а так же проясним смысл оператора композиции/пайплайна.

TL;DR
Compose functions like a boss:

Популярные реализации compose — при вызове создают новые и новые функции на основе рекурсии, какие здесь минусы и как это обойти.

Как правило статьи, рассказывающие о проектировании типами, содержат примеры на функциональных языках — Haskell, F# и других. Может показаться, что эта концепция неприменима к объектно-ориентированным языкам, но это не так.

В этой статье я переведу примеры из статьи Скотта Власчина Проектирование типами: Как сделать некорректные состояния невыразимыми на идиоматический C#. Также я постараюсь показать, что этот подход применим не только в качестве эксперимента, но и в рабочем коде.

Открыто голосование по содержанию второй (из восьми) бета-редакции алгоритмического языка Scheme R7RS-large (Tangerine Edition), а также сбор предложений по третьей бета-редакции (Orange Edition).

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

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