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

Введение

Лисп — второй по старшинству из ныне живых высокоуровневых языков программирования (после Fortran) и первый функциональный язык. Он был разработан в 1958 году и сильно изменился с тех пор, породив множество диалектов и оказав значительное влияние на развитие других языков. На данный момент наиболее известные диалекты: Common Lisp, Scheme, Racket и Clojure.

Слева: Лисп-машина в музее MIT.
Справа: Лисп-машина Symbolics 3640, фото Michael L. Umbricht и Carl R. Friend (Retro-Computing Society of RI)

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

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

Мы в Typeable любим и применяем функциональное программирование, а влияние Лиспа на функциональные языки всё ещё сильно, поэтому нам стало интересно разобраться в этом вопросе.

Важный дисклеймер

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

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

«Не думайте, что я сейчас буду развивать эту концепцию, а затем разочаруюсь в ней. Такой драматургии не будет. Я изначально уже в ней разочарован.»
Роман Михайлов

Ещё хочется заметить, что далее все примеры кода будут приводиться на Haskell. Но в конце я покажу, как можно некоторые из них повторить на Scala.

Что такое HKD

Конечно, прежде, чем писать этот раздел, я полез в интернет, чтобы посмотреть, как этот термин определяют другие люди. Чёткого определения я не нашёл.
Грубо говоря, HKD — это то, что предоставляет возможность держать в одном типе данных сразу несколько представлений. Давайте посмотрим на примеры.

Привет! Это вторая часть рассказа о том, как мы поддерживали язык Frege в IntelliJ IDEA. Первую часть читайте здесь. Сейчас мы поделимся, как сделали автодополнение, систему сборки, интерпретатор и систему типов. И как все это тестировали.

В этом посте мы расскажем, как реализовывали плагин для поддержки функционального языка Frege в IntelliJ IDEA. Если вам интересно, как IDE от JetBrains работают внутри, или вы хотите поконтрибьютить в языковые плагины (а может даже написать свой!), эта статья для вас. Мы пройдемся по этапам создания языкового плагина для IDEA, расскажем, с какими трудностями столкнулись, и как подружили этот язык с JVM-миром.

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

Эта статья является переводом материала «Immutable architecture».

В этом посте автор оригинала хотел бы показать общий подход к внедрению иммутабельности в кодовую базу на архитектурном уровне.

Прежде всего, термин «Иммутабельность», применяемый к структуре данных, такой как класс, означает, что объекты этого класса не могут изменяться в течение их жизненного цикла. Существует несколько типов иммутабельности со своими нюансами, но это не являются для нас существенным. По большей части мы можем сказать, что класс является либо изменяемым, что означает, что его экземпляры могут изменяться тем или иным образом, либо иммутабельным (неизменяемым), что означает, что как только мы создадим экземпляр этого класса, мы не сможем изменить его позже.

Автор статьи: klntsky

Что такое Property-Based Testing?

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

PBT-подход был популяризован библиотекой QuickCheck, написанной на Haskell, и в этой статье будет показано, как пользоваться этим инструментом эффективно.

Эта статья является переводом материала «What is functional programming?».

В этой статье Владимир Хориков попытается ответить на вопрос: что такое функциональное программирование?

Итак, что такое функциональное программирование? Этот термин возникает довольно часто, и каждый автор, пишущий о нем, дает собственное объяснение. На взгляд автора оригинала, самым простым и в то же время точным определением является следующее: функциональное программирование - это программирование с математическими функциями.

Математические функции не являются методами в программном смысле. Хотя мы иногда используем слова «метод» и «функция» как синонимы, с точки зрения функционального программирования это разные понятия. Математическую функцию лучше всего рассматривать как канал (pipe), преобразующий любое значение, которое мы передаем, в другое значение

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

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

Альтернатива: в функциональном стиле динамически задаются конверсии, из них строятся pipeline-ы, далее конверсии генерируют ad-hoc код функций, реализующих заданное преобразование, используя библиотеку convtools.

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

Пригодна ли Java (Scala) и ее библиотеки для задач вывода 3D и анимации? Я попробовал это выяснить на примере библиотеки org.fxyz3d и хотел бы поделиться самой программой и выводам по итогам ее запуска.

Привет, Хабр! Меня зовут Баранов Михаил, работаю программистом более 20 лет. Эта статья о том, как сделать в ЦФТ, то что мы привыкли делать в Бисквите. Начинал я ее писать только для себя, чтобы упорядочить свои знания. Однако потом оказалась, что эта тема важна для всех разработчиков, которые переходят на ЦФТ и не только с Бисквита. Именно поэтому я решил разместить ее на Хабре.

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

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

...на Kotlin разумеется. В комментариях к предыдущей статье было задано несколько вопросов, как сделать конвертацию в tsv, почему утилита собрана в Docker образ и предложение использовать нативный образ GraalVM.

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

Вместо тысячи слов... Хотели бы вы обрабатывать json в терминале таким образом?

Часть 1

Часть 2

Часть 3

Всем привет! В новой части мы рассмотрим использование JSFFI.

Как-то прочел на Хабре статью «Перевозим волка, козу и капусту через реку с эффектами на Haskell», которая так понравилась, что решил написать фреймворк для всего класса задач о переправах, используя мультипарадигменное проектирование. Наконец удалось найти время, и вот, спустя почти год, фреймворк готов. Теперь персонажи, их взаимодействия и описание искомого результата задаются через domain-specific language, который позволяет решать любые головоломки подобного рода с пошаговым выводом. Ниже приводится поэтапный разбор реализации DSL. Статья подойдет тем кто изучает язык Kotlin или просто интересуется примерами его использования. Некоторые малозначимые детали (вроде импортов и вывода) для кратости опущены.

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

Дисклеймер

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

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

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

И здесь, и в других местах в Сети есть масса статей, пропагандирующих автоматическое тестирование вообще и unit-тесты в частности. В статьях расписываются преимущества тестирования, использование его для устранения хрупкого кода, увеличения качества, миграции со старых систем на новые, рефакторинга. И, одновременно, нигде почти не упоминается об их недостатках, а ведь в инженерии нет "серебряных пуль"!

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

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

Почему функциональное программирование? Так тестируем же мы почти исключительно функции.