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

Пару месяцев назад я взяла на себя обязательство по самопросвещению. Есть в иных конторах такая тема — сотрудника, раз в полгода ревьюят и говорят «давай к следующему ревью ты изучишь Spring, паттерны (какие?) и функциональное программирование!» Идея была бы неплоха если бы цели не ставили так размыто. Пропустим пока спринг и паттерны — на выходных я бросилась в атаку на ФП.

Общие-туманные сведения о ФП у меня конечно были — анонимные классы в Java я писать умею — с похожими способностями Python и JavaScript знакома.

Начну с простых упражнений на Scala — решила я. Выбрала Scala поскольку основной рабочий инструмент у нас Java — ну были еще варианты Clojure, Groovy и Java8 (что-то еще?) — но с ними авось попробую потом.

Поставила себе цели (а правильно ли я ФП поняла?):

• Решать задачи в функциональном стиле
• Т.е. по возможности не использовать явных циклов и ветвлений
• А также избегать мутабельных коллекций и т.п.

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

Примечание переводчика. В будущей версии Scala (“Don Giovanni”) анонсирована поддержка типов объединения (union types). Miles Sabin, широко известный в узких кругах как создатель Shapeless, демонстрирует в этой статье 2011 года, как создать типы объединения уже сейчас.
UPD. Представленный в статье подход не позволяет получить настоящих типов объединения и кроме того может существенно повлиять на время компиляции. Типы пересечения (A with B), использованные в статье, также отличаются от классических, поскольку не обладают свойством коммутативности. Подробности об экспериментальном проекте Dotty, в рамках которого будут решены эти и другие проблемы, можно посмотреть в замечательной презентации Дмитрия Петрашко darkdimius — разработчика компилятора Scala в EPFL.

Scala имеет очень выразительную систему типов. Однако она не включает (по крайней мере как примитивы) всех вожделенных элементов. Есть несколько поистине полезных типов, подпадающих под эту категорию — это типы полиморфных функций высшего ранга (higher-rank) и рекурсивные структурные типы. Но о них я расскажу подробнее в следующих постах, а сегодня я собираюсь показать вам, как в Scala мы можем создать типы объединения (union types). В ходе объяснения я пролью немного света на изоморфизм Карри-Ховарда и покажу, как использовать его в наших целях.

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

Я не буду расписывать, что такое монада, я просто покажу одну забавную реализацию монады Maybe (мы же в хабе «Ненормальное программирование»?).

Как должно быть очевидно, одна из целей этого сайта — убедить принимать F# всерьёз в роли универсального языка разработки.

Но в то время как функциональный стиль всё больше проникает в массы, и C# уже получил такие функциональные средства как лямбды и LINQ, кажется, что C# всё больше и больше наступает на пятки F#. Так что, как это ни странно, но я стал всё чаще слышать как высказывают такие мысли:

• «C# уже обладает большей частью инструментария F#, и зачем мне напрягаться с переходом?»
• «Нет никакой необходимости что-то менять. Всё, что нам нужно сделать, так это пару лет подождать, и C# получит достаточно от F#, что обеспечит практически все плюшки.»
• «F# только чуть лучше, чем C#, но не настолько, чтобы в самом деле тратить время с переходом на него.»
• «F# кажется действительно неплох, хоть и пугает местами. Но я не могу найти ему практического применения, чтобы использовать вместо C#.»

Не сомневаюсь, что теперь, когда и в Java тоже добавлены лямбды, подобные комментарии зазвучали в экосистеме JVM при обсуждении «Scala и Closure против Java».

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

Предлагаю читателям «Хабрахабра» вольный перевод статьи «Functional programming in Kotlin». Автор публикации — Mike Hearn.



Те, кто используют .NET, наверняка слышали про F#, универсальный функциональный язык программирования для CLR. Программисты же вне .NET сообщества скорее всего знают про функциональное программирование в связи с языком Haskell.

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

Язык Kotlin (kotlinlang.org) от JetBrains может показаться всего лишь подслащенной Java: синтаксические конвенции, автовывод типов (type inference) и тому подобные мелочи. Но под незамысловатой оболочкой в нем можно найти все самые популярные и прогрессивные конструкции функциональных языков.

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

В статье рассматривается

• Как такая абстракция теории категорий как инвариантный функтор (Invariant Functor), который иногда называют экпоненциальным функтором (Exponential Functor), выражается на Scala.
• Два правила (Identity Law, Composition Law), которым доложен следовать каждый инвариантный функтор.
• Приведен пример инвариантного функтора с состоянием (Value Holder)
• Приведен пример инвариантного функтора-отношения между элементами множества (полугруппа)

Публикация является продолжением FP на Scala: Что такое функтор? в которой были рассмотрены следующие вопросы

• Какая имеется связь между теорией категорий, Haskell и Scala.
• Что такое ковариантный функтор.
• Что такое контравариантный функтор.

Содержание

• Введение
• Что такое Invariant Functor
• Invariant Functor — Identity Law
• Invariant Functor — Composition Law
• Пример #1: Value Holder
• Пример #2: Полугруппа
• Инвариантный функтор в библиотеках

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

• Functional C#: Immutability
  
• Functional C#: Primitive obsession
  
• Functional C#: Non-nullable reference types
  
• Functional C#: работа с ошибками
  

Третья статья в серии «Функциональный C#».

• Functional C#: Immutability
  
• Functional C#: Primitive obsession
  
• Functional C#: Non-nullable reference types
  
• Functional C#: работа с ошибками
  

Специалист, приступающий к изучению функционального программирования, сталкивается как с неоднозначностью и запутанностью терминологии, так и с постоянными ссылками на «серьезную математику».

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

• ко-вариантный функтор
• контра-вариантный функтор

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

• Exponential (Invariant) Functor, BiFunctor, ProFunctor
• Applicative Functor, Arrow, Monad / Co-Monad
• Monad Transformers, Kleisli, Natural Transformations

Объяснено происхождение категориальной терминологии, указана роль языковых механизмов в реализации категориальных абстракций и рассмотрено несколько ковариантных (Option, Try, Future, List, Parser) и контравариантных (Ordering, Equiv) функторов из стандартной библиотеки Scala.

Первая статья в «категориальной серии»:

1. FP на Scala: что такое функтор?
2. FP на Scala: Invariant Functor

Если Вы желаете сильнее погрузиться в мир Scala, математики и функционального программирования — попробуйте онлайн-курс «Scala for Java Developers» (видео + тесты, всего за 25% цены!).

• Про языковые механизмы абстракции
• Про теорию категорий и Haskell
• Что такое ковариантный функтор
• Примеры ковариантных функторов
• Ковариантный функтор: Identity Law
• Ковариантный функтор: Composition Law
• Ковариантный функтор: используем для оптимизации
• Что такое контравариантный функтор
• Примеры контравариантных функторов
• Контравариантный функтор: Identity Law
• Контравариантный функтор: Composition Law
• Что дальше?

Это вторая статья из миницикла статей про функциональный C#.

• Functional C#: Immutability
  
• Functional C#: Primitive obsession
  
• Functional C#: Non-nullable reference types
  
• Functional C#: работа с ошибками
  

Это первая статья из небольшой серии, посвященной программированию на C# в функциональном стиле. Серия не про LINQ, как можно было бы подумать, а про более фундаментальные вещи. Навеяно F#-ом.

• Functional C#: Immutability
  
• Functional C#: Primitive obsession
  
• Functional C#: Non-nullable reference types
  
• Functional C#: работа с ошибками
  

Пару месяцев назад Apple выпустила мажорный апдейт своего нового детища — Swift 2. Выпустило оно его, что называется apple-way, причем не тем way, который «все очень хорошо и вам не нужно ни о чем думать, просто пользуйтесь», а другим. «Мы знаем, что так лучше, а раньше было хуже, поэтому бросайте все ваше раньше и начинайте пользоваться» — то есть язык с заметными проблемами с обратной совместимостью — начиная от того, что штатный инструмент миграции работает довольно таки нестабильно, и заканчивая, собственно, тем, что вы, определенно, не сможете разрабатывать на новой версии языка, не обновя весь инструментарий разработчика до пока еще не очень стабильного последнего — и, что самое страшное, в обратную стророну тоже. Но речь пойдет не об этом. Речь пойдет о том, что мне нравится Swift 2. К сожалению, так как язык все еще не признан сообществом как production-ready, то подавляющее большинство материалов о нем можно отнести к двум категориям — документация Apple и «я вот тут поигрался вечерком и у меня получилось прикольно». Исключения, конечно, есть, но их не хватает, поэтому я и попробую немного осветить этот язык именно с позиции работы с ним и на нем.
В этой статье, мне бы хотелось поговорить о стандартной ORM задаче десериализации JSONа — то есть о том, как из объекта NSDictionary словаря [String: AnyObject] получить некоторую десериализованную структуру. Что изменилось с появлением Swift 2? Как оно было раньше? Кроме того, мы будем рассматривать эту задачу с точки зрения около-функционального подхода, что налагает определенные ограничения — такие, как иммутабельность единожды созданных данных, например. Поэтому рассматриваемое решение может быть несколько сложнее других — но ну и ладно.

Перевод поста Стивена Вольфрама (Stephen Wolfram) "There Was a Time before Mathematica…".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе.

---

Через несколько недель [пост был написан 6 июня 2013 г. — прим. ред.] будет двадцатипятилетний юбилей: 23 июня 1988 года — день, когда была выпущена Mathematica.

Поздней ночью мы все ещё записывали дискеты и упаковывали их. Однако уже в полдень 23 июня я был в конференц-центре в Санта-Кларе, впервые показав публике Mathematica:



Да, именно таким был загрузочный экран, и да, Mathematica 1.0 работала на маках и различных рабочих станциях на Unix; PС тогда не хватало мощности.

Многие оказались под впечатлением от того, что может делать Mathematica. И были очень приятные речи о перспективах Mathematica от различных лидеров компьютерной индустрии, в числе которых был и Стив Джобс (тогда он был в NeXT'е), который был весьма любезен, чтобы прийти, хоть он и не появлялся на публике в течение некоторого времени. А кто-то на этом мероприятии был достаточно дальновиден, чтобы попросить всех выступающих расписаться на книге о Mathematica, которая только поступила в продажу в тот день в книжных магазинах по всей стране:

Привет!

Конференция FPConf уже завтра, сегодня последний шанс купить билет и присоединиться! Регистрация — тут.

Накануне мы решили задать нашим спикерам один довольно неоднозначный вопрос. Большая часть ответов была опубликована вчера — тут

А сегодня мы получили ответ от нашего гостя Эдварда Кметта. Пока публикуем без перевода, обновим пост после конференции.



Вопрос был такой:

В объектно-ориентированных языках есть широко известный список паттернов проектирования (design patterns) от «Банды четырех» (Gang of Four). В функциональных языках такого известного списка не существует. С вашей точки зрения, почему так?
Подобные паттерны не нужны при программировании на функциональных языках или просто их канонический список еще не сложился?

Привет!

Конференция FPConf уже в эту субботу, нас аж 160 и еще не поздно заскочить в последний вагон. Регистрация — тут.

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



В объектно-ориентированных языках есть широко известный список паттернов проектирования (design patterns) от «Банды четырех» (Gang of Four). В функциональных языках такого известного списка не существует. С вашей точки зрения, почему так?
Подобные паттерны не нужны при программировании на функциональных языках или просто их канонический список еще не сложился?

Clojure (произносится как closure) — современный диалект Лиспа, язык программирования общего назначения с динамической типизацией и поощряющий функциональное программирование. Автор языка Рич Хикки впервые представил своё творение в 2007 году, с тех пор язык заматерел и достиг версии 1.7, вышедшей 30 июня 2015 года.

Одна из основных концепций языка — это работа на какой-либо существующей платформе. Рич Хикки решил не писать свою среду выполнения, свой сборщик мусора и т.п. — это потребовало бы больших трудозатрат, проще использовать уже готовые платформы, такие как JVM, .NET, JavaScript. На сегодняшний день два самых активно развиваемых направления: Clojure на JVM (именно он достиг версии 1.7 не так давно) и ClojureSrcipt — подмножество языка, которое компилируется в JavaScript для работы в браузере и на Node.js. Версия для .NET развивается не так активно и отстаёт от JVM имплементации. Я поискал в интернете и нашел ещё несколько мёртвых реализаций Clojure: на Go, на PHP, на Python и на Perl.

В этой статье я хочу рассказать о Clojure, показав примеры в сравнении с PHP, основываясь на серии скринкастов на английском From PHP to Clojure.

Механизм лямбда-выражений, представленный в Java8, стал такой фичей, которая чётко разделила код до нее и после (кажется, такое же может случится с Java9 и модульной системой, но в плохом смысле). В Java8 стало больше функциональных трюков, разнообразная обработка больших массивов данных стала значительно проще и теперь занимает куда меньше места. Однако, касательно рационального использования лямбда-выражений существует много вопросов таких как: насколько рационально часто их использовать? существенна ли потеря производительности теряется при переходе от обычного цикла в `forEach()` с лямбда-выражением и так далее. Большинство курсов (даже курс Oracle) игнорируют эти вопросы. В этом посте будет описан как раз один из, наверное, наименее популярных вопросов, но не менее интересный чем остальные:

Как работать сериализация лямбда-выражений в Java и как её можно использовать?

«Инструкция создания функционального приложения», часть 1.

«Мне кажется, что понимаю функциональное программирование на базовом уровне, и я даже писал простые программы, но как мне создать полноценное приложение, с реальными данными, с обработкой ошибок и прочим?»

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

От переводчика:
Это вольный перевод статьи «Purify code using free monads» Габриэля Гонзалеса, посвященный использованию свободных монад для представления кода как синтаксического дерева с последующей управляемой интерпретацией.
На хабре имеются другие статьи Габриэля — «Кооперативные потоки с нуля в 33 строках на Хаскеле» и «Чем хороши свободные монады».
Для прочтения этой статьи необходимо знать, что такое свободная монада и почему она является функтором и монадой. Узнать об этом можно в указанных двух переводах или в статье, на которую ссылается сам автор.
Все замечания переводчика выделены курсивом.
По всем замечаниям, связанным с переводом, обращайтесь в личку.

Опытные программисты на Хаскеле часто советуют новичкам делать программы настолько чистыми, насколько это возможно. Функция называется чистой, если она детерминированная (возвращаемое значение однозначно определяется значениями всех формальных аргументов) и не имеет побочных эффектов (то есть не изменяет состояние среды исполнения). В классической математике, λ-исчислении и комбинаторной логике все функции чистые. Чистота предоставляет множество практических преимуществ:

• можно формально доказать какие-то свойства написанного кода,
• кроме того, можно легко обозревать код и сказать, что он делает,
• наконец, можно прогнать через QuickCheck.

Для демонстрации я буду использовать такую простенькую программу echo:

import System.Exit

main = do x <- getLine
          putStrLn x
          exitSuccess
          putStrLn "Finished"

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