Это первая статья из небольшой серии, посвященной программированию на 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"

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

Привет!

15 августа состоится FPConf — первая в России конференция по функциональному программированию. В двух потоках однодневной конференции будут доклады о Scala, F#, Erlang, Clojure, Haskell и функциональных подходах в привычных Ruby, Python и Java.

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

Поэтому, мы приглашаем как опытных функциональщиков, так и тех, кто только хочет получить вдохновение и обзор тем для первого изучения :)

Доклады от представителей JetBrains, Лаборатории Касперского, 2ГИС, Mail.ru, Mashine Zone, Luxoft, Sputnik и многих других.
Цена билета сейчас — 7000 рублей. Регистрация тут.


Программа:

Эдвард Кметт, Chair of the Haskell Core Libraries Committee
LENSES AND PRISMS
Functional programming shows us that working with immutable structures makes it easy to reason about parallelism, non-determinism, and other effects, but along the way we lose the familiar notion of a field accessor. «Getters and setters» don't make sense as such in an immutable world. Lenses provide us a way to regain that lost functionality and more besides, acting as a form of «functional reference».
On the flip side, in the process of constructing the lenslibraryfor Haskell, I've found a related notion, that of a Prism, to be equally useful for working with case matching on ADTs, handling extensible exceptions, as well as working with semi-structured data such as JSON, XML and the like. However, surprisingly little has been said about them before now.
This talk will explore the roles each of these abstractions play and why you as a developer should care about them.

Здравствуйте, уважаемые пользователи и посетители Хабра. В первой статье Веб-приложения на Clojure были рассмотрены базовые инструменты и библиотеки для построения веб-проектов на Clojure. А именно Leiningen, Ring, Compojure, Monger, Buddy и Selmer. Здесь же речь пойдет об их практическом применении.

На Хабре не так уж и много статей о Clojure, и это печально, намерен это исправить. Ниже я расскажу об отличном на мой субъективный взгляд инструменте — языке программирования Clojure и его библиотеках для создания веб-приложений.

Я засомневался в своей точке зрения, см. подробнее в одном из UPD.

Хочу поговорить о Wolfram Language (далее WL). Прошу прощения за сумбурность изложения, пост вырос из попытки ответить на этот коммент от Nilis.

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

Лет 6-10 назад, когда я учился в школе, я знал лишь BASIC, Pascal/Delphi, C/C++ и WL. Из ОС имел дело лишь с Windows. Не знал, что такое скриптовые языки (perl, python, bash), не знал самого понятия «скрипт». Думал, что командный интерфейс — это устаревший интерфейс и что единственный правильный интерфейс программы — это графический. Программировал я на Delphi и WL. Программы на Delphi всегда были графическими. За исключением олимпиадного программирования, там в требованиях к программам было, что они должны быть текстовыми, я их писал на Delphi и C++. Когда я узнал о WL, я был им очарован, также как и вы. Потому что код на WL был гораздо короче, чем на Delphi/C++. И вообще, потому что WL был совершенно не похож на Delphi и C++. Потому что там была возможность программировать функционально. Я познакомился с функциональным программированием на примере WL, я не знал, что существуют «стандартные» функциональные языки — Haskell, Lisp и ML.

Перевод поста Джона Маклуна (Jon McLoone) "10 Tips for Writing Fast Mathematica Code".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе.

---

Пост Джона Маклуна рассказывает о распространенных приемах ускорения кода, написанного на языке Wolfram Language. Для тех, кто заинтересуется этим вопросом мы рекомендуем ознакомиться с видео «Оптимизация кода в Wolfram Mathematica», из которого вы подробно и на множестве интересных примеров узнаете о приемах оптимизации кода, как рассмотренных в статье (но более детально), так и других.

---

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

1. Используйте числа с плавающей точкой, и переходите к ним на как можно более ранней стадии.

Самая распространённая ошибка, которую я замечаю, когда разбираюсь с медленным кодом — задание слишком высокой точности для данной задачи. Да, неуместное использование точной символьной арифметики — самый распространенный случай.

У большинства вычислительных программных систем нет такого понятия, как точная арифметика — для них 1/3 это то же самое, что и 0,33333333333333. Это различие может играть большую роль, когда вы сталкиваетесь со сложными и неустойчивыми задачами, однако для большинства задач числа с плавающей точкой вполне удовлетворяют нуждам, и что важно — вычисления с ними проходят значительно быстрее. В Mathematica любое число с точкой и с менее чем 16 цифрами автоматически обрабатывается с машинной точностью, потому всегда следует использовать десятичную точку, если в данной задаче скорость важнее точности (например, ввести треть как 1./3.). Вот простой пример, где работа с числами с плавающей точкой проходит почти в 50,6 раза быстрее, чем при работе с точными числами, которые лишь затем будут переведены в числа с плавающей точкой. И в этом случае получается такой же результат.

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

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

Именно поэтому важно если не постичь глубинную суть этого паттерна, то хотя бы научиться распознавать примеры использования монады в уже существующих, окружающих нас API. Конкретный пример всегда даёт больше, чем тысяча абстракций или сравнений. Именно такому подходу и посвящена эта статья. В ней не будет теории категорий, да и вообще какой-либо теории. Не будет оторванных от кода сравнений с объектами реального мира. Я просто приведу несколько примеров того, как монады уже используются в знакомом нам API, и постараюсь дать читателям возможность уловить основные признаки этого паттерна. В основном в статье пойдёт речь о Java, и ближе к концу, чтобы вырваться из мира legacy-ограничений, мы немного коснёмся Scala.

Недавно, просматривая интересные репозитории на github в поисках вдохновения я наткнулся на проект Elm — функциональный реактивный язык программирования, созданный для веб, потомок ML и Haskell. У меня нет большого опыта в функциональном программировании, но посмотрев посадочную страницу, я увлекся этим творением на несколько часов, позабыв о работе и окружающем мире. Меня сразу вдохновила та простота, которая, как мне казалось раньше не присуща функциональным языкам программирования.
Еще раз повторюсь, что я не силен в функциональном программировании, плохо знаком с математическими концепциями, на которых оно строится и изучению Elm удлелил, пока что, не очень много времени. Я считаю, что лучше бы эту статью написал кто-то другой, более осведомленный, но, таковых не нашлось, а до тех пор, я решил возложить эту ношу на себя, быть может, моя статья поможет кому-то открыть для себя прелести функционального программирования для веб, или по новому взглянуть на, казалось бы привычные вещи. Большинство материалов, представленных в статье взяты из официальной документации и переведены в довольно свободной форме. Всех страждующих, прошу под кат.

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

Часть 1
Часть 2

Что вы сделаете, если завтра выиграете в лотерею? Купите спортивную машину, бросите работу и поедете в турне по США? А может быть станете основателем собственной компании, приумножите состояние и купите личный самолёт?

Мы все любим делать планы, и чаще всего они опираются на наше финансовое состояние. Такие планы могут быть описаны функцией. К примеру, план покупки машины это:

pair<Car, Cash> buyCar(Cash cashIn)

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

template<class A>
using Plan = function<pair<A, Cash>(Cash)>;

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

template<class A>
Plan<A> got_it(A a)
{
    return [a](Cash s) { return make_pair(a, s); };
}

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

Часть 1
Часть 2

Иногда программисты на С++ просят привести пример задачи, которая не может быть решена без использования монад. Начнём с того, что этот вопрос неверен сам по себе — это всё-равно, что спрашивать, существует ли задача, которая не может быть решена без циклов. Очевидно, если в вашем языке есть поддержка оператора goto, вы можете обойтись без использования операторов цикла. Что монады (и циклы) могут сделать для вас, это упростить ваш код и помочь лучше его структурировать. Как использование циклов превращает спагетти-код в нормальный, так и использование монад может превратить ваш код в императивном стиле в декларативный. Эта трансформация может помочь легче писать, понимать, поддерживать и расширять ваш код.

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

  s e n d
+ m o r e
---------
m o n e y

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

Введение

Я люблю функциональные языки за их простоту, ясность и предсказуемость. Пишу в основном на Elixir / Erlang / OTP, пробовал другие языки, но Erlang с его акторами пока мне гораздо ближе чем например Lisp или Haskell. Как известно Erlang == web, а у чего-либо написанного для веба порой бывает клиентский веб-интерфейс: html, css, js — содержимое. Увы js это стандарт современного веба, для него есть библиотеки почти под любую задачу почти на все случаи жизни, да и это более-менее единственное доступное средство что-то выполнить в браузере на стороне клиента. Поэтому нам всё-таки нужен js. Сперва мне подумалось «Лямбды и функции высшего порядка есть, значит писать на js будет просто. Выучу синтаксис и буду писать так же как пишу в Erlang/Lisp/Haskell». Как же я ошибался.