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

Свойства и законы. Сценарии. Inversion of Control в Haskell.

Совсем немного теории

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

Жесть! Это как программирование через регулярные выражения…
Нет, вы меня не заставите! Больше никогда!

Смотрю на код и чувствую себя идиотом. Это правда не эзотерический язык типа brainfuck? Им кто-то реально пользуется? И эти программы потом читают?

quicksort=: (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

Perl нервно курит в сторонке.

Хабрахабр о J

J — корейский среди языков программирования. Взрыв на фабрике спецсимволов. Куча скобочек, точек, слэшей, и всё это ещё и работает. Не иначе как по велению чёрной магии, а то и самого Сатаны.

Некоторые из тех, кто пишет на J, забывают простые правила написания любого кода в погоне за краткостью или просто увлекшись. Эти правила не новые, но они приобретают критическое значение применительно к APL-подобным языкам, потому как при чтении конструкций вроде ((]i.~[:{.[){([:{:[),]`([:<[$:[:>])@.([:32&=[:3!:0[:>]))"2 0 даже тренированный мозг сворачивается в трубочку.

Итак, простые правила написания читаемого кода на J под катом.

Без словарика под кат лучше не соваться. Вас предупреждали.
И напомню, список полезных ссылок здесь.

Примечание переводчика: Данный текст был написан Майклом Халлс-Муром, математиком и физиком из Лондона, который профессионально занимается биржевой торговлей и является квантом. Майкл основал ресурс QuantStart.com, на котором публикуются разнообразные глубоко технические материалы, так или иначе связанные со сферой финансов.

Люди довольно часто спрашивают о том, какие языки программирования наиболее популярны в финансовой сфере — например на фондовом рынке. Какой из них следует знать, чтобы стать независимым разработчиком финансовых приложений или попасть на работу в какую-нибудь крупную компанию рынка? На этот вопрос нелегко ответить однозначно: C++, C# и Java имеют свои плюсы. Сегодня мы поподробнее рассмотрим каждый из них.

Дорогие любители Scala! Пользуемся последним моментом, чтобы сообщить вам об очередной встрече Scala User Group в Москве. Она пройдет в эту пятницу, 25 апреля на территории НИИ «Восход». Начало в 19:30. Для того, чтобы прийти на встречу, необходимо заполнить форму регистрации: docs.google.com/forms/d/1tYo8unkWNpQYN-lCwoZz4mL7AcvNQGi_Zt1O7TTpknA/viewform (все поля обязательны, ФИО должны вводиться целиком). Последний день регистрации — сегодня, 23 апреля.

Язык J многими, в том числе и на хабре, считается write-only language (что, в общем-то, неправда) или программированием через регэкспы. Важно помнить, что J — это ASCII-версия математической нотации Айверсона, лежащей в основе APL. Точно так же, как невозможно прочесть Хиндли-Милнера, не зная математической нотации, код вроде value =: [:(]`{.@.([:1&=#))[:,[:>[((([:<[)=[:{.])#[:{:])[:>] не может быть понятен человеку, незнакомому хотя бы со словарём языка.

Под катом небольшая подборка учебников и туториалов по теме для заинтересовавшихся. (Внимание: все ресурсы на английском языке)

Восходящее проектирование в ФП. Идея — основа хорошего дизайна. Антипаттерны в Haskell.

Немного теории

В прошлой части мы построили высокоуровневую архитектуру приложения. Мы определили подсистемы и их связи, а также разделили программу на три слоя: Application, Game Logic, Views. По логике, следующий этап — дизайн приложения. По важности этот этап не уступает предыдущему, так как именно в ходе дизайна мы должны поддержать все функциональные требования, определить фактическую структуру подсистем, описать основные технические проблемы, применить какие-либо типовые решения или придумать другие. Но прежде попробуем ответить на вопрос: каков он, хороший дизайн ПО? По каким критериям мы определяем «хорошесть» дизайна?

Когда я писал о разработке игры "Thud!", я уже сетовал на некоторую избыточность полученного описания. Простота языка ZRF имеет свою оборотную сторону — для того чтобы написать на нем что-то более менее сложное, часто, приходится дублировать значительные фрагменты кода. Подобная избыточность, как известно, приводит не только к увеличению объема ручной работы, но и значительно усиливает риск появления в коде разнообразных ошибок (поскольку процесс отладки ZoG приложений весьма не тривиален, это является существенным моментом).

Как можно бороться с подобной избыточностью?

Разумеется, с помощью макросов! Проблема в том, что макросы ZRF недостаточно выразительны для этого. Адриан Кинг, в процессе разработки игр Scirocco и Typhoon, пришел к аналогичному выводу и разработал свой собственный, расширенный язык макросов, работающий как внешний препроцессор. Сегодня, я расскажу о возможностях этого языка и постараюсь, на примере Thud!, показать его использование в процессе разработки ZRF-приложений.

В прошлый раз мы провели ознакомительную встречу. Собралось около 25 человек, мы узнали кто в Москве занимается разработкой на Scala и какие есть интересные проекты. Главной темой выбрали курс по реактивному программированию на Coursera, который как раз тогда подходил к концу.

В этот раз мы соберёмся послушать и обсудить два доклада:

1. Алексей Иванов приедет из Питера и расскажет доклад «Monadic Bakery with Spray and Scalaz»,
   про то почему Spray и ScalaZ — не страшные звери, а хорошие друзья;
2. Владимир Успенский расскажет про теорию типов и тем, как она связана с обычной разработкой в докладе:
   «Теория типов, или как мы занимаемся математикой, программируя на Scala».

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

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

Это статья попытка показать, что сила функциональных языков и в первую очередь Хаскеля — это в том числе и силе функторов и монад.

Введение

В мире функционального программирования есть один большой пробел, а именно почти не освещена тема высокоуровневого дизайна больших приложений. Я решил для себя изучить этот вопрос. Есть ли существенные отличия дизайна приложений в ФП-мире от оного в мире императивном? Что такое «каноничный ФП-код»? Какие существуют идиомы разработки, есть ли смысл вообще говорить о паттернах проектирования в применении к ФП? Эти и другие важные вопросы часто вспыхивают то там, то здесь, но покамест мне не известно ни одной книги, аналогичной книге Банды Четырех. Вероятно, мои изыскания уже кто-то повторил, однако тем лучше: схожие результаты подтвердят правильность, иные — укажут на место в теории, которое необходимо доработать.

Доброй ночи, Хабр! Мы продолжаем изучение Erlang для самых маленьких.

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

А сейчас нужно обязательно дунуть, потому что если не дунуть, то ничего не получится.
—Цитаты великих

И здравствуйте!

Сегодня мы поговорим о неявном в языке Scala. Кто еще не догадался — речь пойдет об implicit преобразованиях, параметрах, классах и иже с ними.Все новички, особенно любители питона с зеновским Explicit is better than Implicit, обычно впадают в кататонический ступор при виде подкапотной магии, творящейся в Scala. Весь компилятор и принципы в целом охватить за одну статью удастся вряд ли, но ведь дорогу осилит идущий?

Добрый день, уважаемое хабрасообщество!

В конце ноября 2013 года мы с коллегой устроили встречу, на которой провели сеанс «интенсивного введения Scala в мозг добровольцев».

Выкладываю на суд общественности наше творчество и краткое описание «эксперимента».

На Хабре много статей по монады с примерами для Haskell (http://habrahabr.ru/post/183150, http://habrahabr.ru/post/127556), но не так много статей, которые описывают, что такое монады с примерами на Scala. По сколько большинство разработчиков на Scala пришли из мира объектно ориентированного программирования, то для них, по началу, сложно понять что такое монады и для чего они нужны, эта статья как раз для таких разработчиков. В этой статье я хочу показать, что это такое и навести примеры использования монады Option, в следующих статьях будут описаны монады Try и Future.

В этой статье мы попытаемся рассмотреть всё разнообразие Алгебраических Типов Данных.

Надо сказать, задача это достаточно неподъёмная, и понять человеку, если он ранее с Алгебраическими Типами не имел дело — не очень просто.
АТД были впервые использованы в языке Hope, но основную популярность они приобрели благодаря языкам ML, такими как Standart ML, OCaml, F#, и языку Haskell.
Ныне АТД в той или иной мере поддерживаются в значительно большем количестве языков: Scala, Rust, Nemerle, Racket,…
АТД — это универсальный тип данных. С помощью него можно представить большинство типов данных.
АТД называются алгебраическими, потому что их можно представить как некую алгебраическую композицию типов его составляющих. Это знание даёт своё преимущество: понимая свойства алгебраической композиции, можно посчитать какой тип необходим для построения тех или иных данных.
Будем рассматривать типы на основе языка Haskell, однако подобного с лёгкими изменениями можно добиться в других языках с поддержкой АТД.

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

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

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

Всем программистам рано или поздно приходится передавать данные. Ни для кого не секрет, что библиотек сериализации в Java существует примерно >9000, а в C++ они вроде и есть, а вроде их и нет. К счастью для большинства, несколько лет назад появился Google Protobuf, который принёс достаточно удобный способ определять структуры данных и быстро завоевал всенародную любовь. Это была фактически первая, доступная широким массам библиотека, позволяющая гонять по сети готовые структуры данных, не связываясь при этом с чем-то вроде XML. На дворе был 2008 год.

Вернёмся немного назад. В 2006 году простой индийский программист (как бы подозрительно это ни звучало!) Анил Мадхавапедди, один из самых известных сейчас в мире OCaml-разработчиков и автор свежевышедшей книги Real World OCaml, защищал в Кембридже кандидатскую диссертацию. Именно о ней я сегодня вам и расскажу.

Анил сразу пошёл дальше, чем Google. Он сразу подумал, для чего люди обычно пересылают по сети какие-то формализованные структуры данных? Чтобы реализовать какой-то протокол. А что такое протокол? Это какой-то конечный автомат. А где мы можем взять хороший пример сложного, хорошо спроектированного и проверенного временем протокола? Да прямо в обычном сетевом стеке! Итак, были взяты набор сетевых структур данных и протоколов: Ethernet frame, IPv4, ICMP, TCP, UDP, SSH, DNS и DHCP и постановка задачи: большая часть этих протоколов (особенно SSH и DNS) реализуются, что называется «руками», а хочется, чтобы не было типичных для C переполнений буфера, все переходы совершались автоматически, это всё можно было верифицировать, и чтобы работало быстро, а не как обычно.

Поскольку никто не будет читать диссертацию, сразу скажу: это более чем удалось. По результатам работы были написаны референсные реализации DNS и SSH-сервера и произведено сравнение с BIND и OpenSSH. OCaml-реализации давали по сравнению с традиционными прирост производительности от незначительного, до почти двухкратного. Кроме того была найдена ошибка в RFC на SSH (рабочая группа была уведомлена и RFC исправлен). О том, что было сделано, и как с этим жить, читайте под катом.

Добрый день, сегодня хотелось бы рассказать, как наша команда работает с базами данных. У нас в компании в основном используется Oracle и в нашей команде много людей, кто умеет хорошо его готовить. Нам изначально хотелось получить полный доступ к его возможностям: иерархическим запросам, аналитическим функциям, передаче объектов и коллекций, как параметров запросов, и, может быть, если не будет другого способа — хинтам. Модель у нас не очень сложная, поэтому сознательно отказались от ORM.

В качестве основы взяли Apache DbUtils и сделали для него простую обёртку на Scala. Ниже я расскажу, как возможности Scala, особенно её последней версии 2.10, помогли упростить работу с базой данных.

А пытливых читателей, кто дочитает до конца, ждёт сюрприз.

Привет Habr! Сегодня мы поговорим о полиморфизме функций, операторах и карринге. Напоминаю, что лекции рассчитаны на новичков, а конспект предпологает сжатую форму изложения. Если все еще интересно…

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

Этот факт находит отражение и в изменении учебных курсов. Сассман, автор SICP, самого известного курса по программирование, сказал: " инженерное дело в середине 90-ых, а уж тем более в 2000-ых сильно отличается от инженерного дела 80-ых. В 80-ых хорошие программисты проводили много времени в размышлениях, а потом писали немного кода, который работал. Код работал близко к «железу», даже Scheme — все было прозрачно на всех стадиях. Как с резистором, достаточно посмотреть на цветную маркировку, чтобы узнать номинальную мощность, допустимые отклонения, сопротивление и V=IR — это все, что нужно знать. 6.001 был задуман как курс для обучения инженеров тому, как из маленьких кубиков, в которых они досконально разбираются, посредством простых техник составлять сложные конструкции, которые делают то, что от них хотят. Но программирование сейчас далеко не то же самое. Теперь вы ковыряетесь в непонятной или несуществующей документацией для софта, даже неизвестно, кем написанного. Вы должны досконально исследовать библиотеки, чтобы узнать, как они работают, пробовать разные исходные данные и смотреть, как реагирует код. Это в корне иная работа, и для нее требуется иной курс обучения."

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