Как сделать функции на Python еще лучше
Поскольку очень не хотелось оставлять в тексте важный термин латиницей, мы позволили себе перевести слово «docstring» как «докстрока», обнаружив этот термин в нескольких русскоязычных источниках.

От Lisp до Haskell


Представляю вашему вниманию перевод статьи Scott Wlaschin "Designing with types: Making illegal states unrepresentable".
В этой статье мы рассмотрим ключевое преимущество F# — возможность "сделать некорректные состояния невыразимыми" при помощи системы типов (фраза заимствована у Yaron Minsky).
Рассмотрим тип Contact. В результате проведённого рефакторинга он сильно упростился:
type Contact =
{
Name: Name;
EmailContactInfo: EmailContactInfo;
PostalContactInfo: PostalContactInfo;
}Теперь предположим, что существует простое бизнес-правило: "Контакт должен содержать адрес электронной почты или почтовый адрес". Соответствует ли наш тип этому правилу?
Нет. Из правила следует, что контакт может содержать адрес электронной почты, но не иметь почтового адреса, или наоборот. Однако в текущем виде тип требует, чтобы были заполнены оба поля.
Кажется, ответ очевиден — сделать адреса необязательными, например, так:
type Contact =
{
Name: PersonalName;
EmailContactInfo: EmailContactInfo option;
PostalContactInfo: PostalContactInfo option;
}Но теперь наш тип допускает слишком многое. В этой реализации можно создать контакт вообще без адреса, хотя правило требует, чтобы хотя бы один адрес был указан.
Как же решить эту задачу?

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

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

Привет! Завтра в 16:00 (UTC) стартует ICFP Contest 2018 — ежегодное 72-часовое командное соревнование для программистов, посвящённое решению единственной, но интересной и заковыристой задачи.

Картинка, вызывающая ностальгию у участников ICFPC 2017.
Уже участвовали в ICFPC? Тогда вам и объяснять ничего не надо. Вы уже собрали любимую команду или нашли новую, подписались на твиттер, IRC-канал и репозиторий организаторов, поучаствовали в перекличке на Reddit и запланировали хорошенько выспаться перед пятницей.
Ни разу не участвовали? Тогда самое время проделать всё вышеперечисленное, потому что участие в ICFP Contest — это лучшее, что может с вами случиться в ближайшие три дня. Если сомневаетесь, то у меня для вас кое-что есть:


1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение
Данный пост завершает серию статей о функциональном программировании под названием "Мышление в стиле Ramda".
В последние восемь постов мы говорили о JavaScript библиотеке Ramda, которая предоставляет функции для работы с JavaScript в функциональном, декларативном и иммутабельном стиле.
В течении этой серии статей, мы узнали, что Ramda имеет несколько основных принципов, которыми движется её API:
Эти два принципа позволяют нам писать очень чистый функциональный код, который объединяет базовые строительные блоки в более мощные операции.
1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение
Данный пост — это восьмая часть серии статей о функциональном программировании под названием "Мышление в стиле Ramda".
В шестой и седьмой частях мы изучили, как читать, обновлять и трансформировать свойства объектов и элементы массивов в декларативном и иммутабельном стиле.
Ramda также предоставляет более общий инструмент для выполнения данных операций, который называется линзами.
1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение
Данный пост — это седьмая часть серии статей о функциональном программировании под названием "Мышление в стиле Ramda".
В шестой части мы говорили о работе с объектами JavaScript в функциональном и иммутабельном стиле.
В данном посте мы поговорим о подобной работе с массивами.
При слове ТРИЗ, часто вспоминают тезис "идеальная система — та, которой нет (а ее функция при этом выполняется)". Как хороший админ, который не появляется в офисе, а все при этом исправно работает.
Функция и система — критически важные понятия в ТРИЗ, говорят даже о функциональном стиле мышления. Правда при этих словах лично у меня сразу возникает ассоциация с функциональными языками программирования.
Попробуем посмотреть, насколько органично идеи функционального мышления ТРИЗ отображаются на Haskell, одном чистых функциональных языков общего назначения.

1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение
Данный пост — это шестая часть серии статей о функциональном программировании под названием "Мышление в стиле Ramda".
В пятой части мы говорили о написании функций в стиле бесточечной нотации, где главный аргумент с данными для нашей функции не указывается явным образом.
На тот момент времени мы не могли переписать все наши функции в бесточечный стиль, потому что у нас не было некоторых необходимых для этого инструментов. Настало время для того чтобы изучить их.