В сети гуляет интересная задача, которую задавали на собеседовании в Twitter.
Представьте, что вы смотрите на стенки различной высоты в профиль. Идет дождь, где-то вода остается, где-то перетекает за края стенки из-за разницы в высоте. Задача состоит в том, чтобы определить, какой объем воды остался между стенками.
Привет.
Итак, в прошлый раз мы эмпирически доказали, что на хаскеле можно довольно легко написать этакий игрушечный wc, который при этом существенно быстрее реализации wc из GNU Coreutils. Понятное дело, что это не совсем честное сравнение: наша программа не умеет ничего, кроме подсчёта байт, строк и слов, тогда как настоящий wc куда мощнее: он имеет ещё несколько статистик, поддерживает опции, умеет читать из stdin… Короче, у нас действительно получилась всего лишь игрушка.
Сегодня мы это исправим. Наша главная цель — позволить пользователю выбирать конкретные статистики для подсчёта, при этом не считая то, что пользователю не нужно. А самое главное — мы будем стремиться к модульности, выделяя каждую статистику в отдельный изолированный юнит.
Действительно, если мы посмотрим на C-версию — ну, лично я бы не назвал это образцом читаемого и поддерживаемого кода, так как там всё происходит в одной большой функции на 370 строк. Мы будем стараться этого избежать.
Основная функция С-версии не влезла на 4k-экран в портретной ориентации 4-м шрифтом.
Кроме этой модуляризации мы, среди прочего:
Привет! Меня зовут Рома, я работаю iOS-разработчиком в Exness. А кроме того, пишу на Clojure и инвестирую.
Сегодня я расскажу о том, как оценивать опционы. Это вводная статья и заработать миллион, используя предложенный способ, вряд ли получится. Тем не менее, это хорошая основа для понимания более сложных методов оценки.
В основе работы с матрицами (в данной статье мы будем рассматривать только двумерные матрицы) лежит мощная математическая теория из области линейной алгебры. Одно определение или действие следует из другого, одна функция вызывает другую. Поэтому для программной реализации функционала математических операций над матрицами функциональные языки подходят очень хорошо. В рамках данной статьи мы рассмотрим конкретные примеры на языке F# и дадим подробные комментарии, как это работает. Так как F# входит в семейство .NET, то полученный функционал можно без каким либо проблем использовать в других императивный языках, например C#.
Матрицы являются базовой и важнейшей частью линейной алгебры. Матрицы часто используются в программировании, например в 3D-моделировании или гейм-девелопинге. Разумеется, велосипед уже давно изобретен и необходимые фреймворки для работы с матрицами уже готовы, и их можно и нужно использовать. Данная статья не ставит своей целью изобретение нового фреймворка, но показывает реализацию базовых математических операций для работы с матрицами в функциональном стиле с использованием языка программирования F#. По мере рассмотрения материала мы будем обращаться к математической теории матриц и смотреть, как ее можно реализовать в коде.
Читать полностью »
Привет! Представляю вашему вниманию перевод оригинальной статьи «Your C# is already functional, but only if you let it» автора Igal Tabachnik.
Несколько дней назад я написал в Твиттере фрагмент кода C#, реализующий FizzBuzz, используя некоторые из новых «фичи» в C# 8.0 . Твит “стал вирусным”, несколько человек восхищались его лаконичностью и функциональностью, в то время как другие спрашивали меня, почему я не написал его на F#?
Прошло уже более 4 лет с тех пор, как я в последний раз писал на C#, и то, что я обычно использую функциональное программирование, явно повлияло на то, как я пишу код сегодня. Фрагмент, который я написал, кажется очень аккуратным и естественным, однако некоторые люди выразили опасения, что он не похож на код на C#.
«Он выглядит слишком функциональным.» – писали мне они.
В зависимости от того, кого вы спрашиваете, «функциональное программирование» означает разные вещи для разных людей. Но вместо того, чтобы обсуждать семантику, я хотел бы предложить объяснение того, почему эта реализация FizzBuzz кажется функциональной.
Читать полностью »
Мне нравятся разговоры на тему «мне раньше в школе/институте/родители говорили, а теперь я узнал». Если по счастливой случайности я оказываюсь хоть немного компетентен в обсуждаемом вопросе, то такие разговоры обычно сводятся к одному из трех вариантов: «где вообще ты раньше слышал такую чушь?» (если собеседник прав), «а с чего ты взял, что это так?» (если он не прав) и «ты прав, только это не противоречит тому, что тебе говорили раньше» (в подавляющем большинстве случаев). Нравятся такие разговоры мне по следующей причине: обычно их инициатор не обременен излишним предварительным знанием вопроса, что в некоторых случаях позволяет ему указать на некоторые моменты, которые принимались как очевидные, на самом деле таковыми не являясь. И одной из тем для подобных бесед оказалось функциональное программирование.
Вообще про ФП написано и сказано столько, что вроде бы все вопросы о его применимости, крутости, производительности и т.п. обглоданы до костного мозга. И все-таки такого рода вопросы поднимаются снова и снова, и всегда найдется желающий рассказать о том, что вы все неправильно поняли, а на самом деле оно эвано как. Пожалуй, сегодня я примерю на себя эту неблагодарную роль, поскольку недавно попались на глаза несколько постов на эту многострадальную тему. В первом и втором в очередной раз рассказано, что ФП — дрянь и изучать его — только портить свою карму будущего специалиста. Другие (раз и два) куда более адекватны, в них автор ставит целью объяснить, что все эти ваши лямбды, комбинаторы, категории — не более, чем пыль в глаза, а само ФП — штука простая, понятная и приятная в быту.
На сколько это соответствует истине?
Читать полностью »
Привет! Меня зовут Ильдар. Мне 29 лет. Программирую с 2003 года. За свою жизнь создал 4 фреймворка и язык программирования. В этом посте я поделюсь своим опытом, инсайтами, которые я получил при разработке языка программирования BAYRELL Language. Заранее прощу прощения за возможные синтаксические и пунктуационные ошибки в тексте и отсутствие картинок.
В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам Фаулер пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).
Сейчас же я хочу рассказать, что такое монады на самом деле, чем они полезны для обычного практикующего разработчика, и приведу примеры, почему недостаточная поддержка их в распространенных языках приводит к копипасте и ненадежным решениям.
Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?
Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки. кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.
Получается, что первые обычно полезны тем, кто и так знает обсуждаемую тему, а вторые даже не знаю на кого рассчитаны: сколько я их не прочитал, ничего полезного понять из них мне не удалось.
Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.
Если вы работаете с одной базой данных которая поддерживает транзакции вы даже не задумываетесь о консистентности — база все делает за вас. Если же у вас несколько баз, распределенная система или даже к примеру MongoDB до 4 версии — все не так радужно.
Рассмотрим пример — мы хотим сохранить файл в хранилище и добавить ссылку на него в два документа. Конечно же мы хотим атомарности — либо файл сохранен и добавлен в документы либо ни то ни другое (тут и далее используется cats-effects IO):
saveDataToFile(data) // (1)
.flatMap { file =>
addFileRef(documentId, file) // (2)
.flatMap { result =>
addFileRef(fileRegistry, file) // (3)
.flatMap { result =>
??? // (4, 5, ...)
}
.handleErrorWith { error =>
// revert (2)
removeFileRef(documentId, file).attempt >> IO.raiseError(error)
}
}
.handleErrorWith { error =>
// revert (1)
removeFile(file).attempt >> IO.raiseError(error)
}
}Уже непросто? Легко представить как количество операций растет и образуется Pyramid of doom.
Но мы же программисты! Давайте обобщим проблему и напишем код, который позволит избежать ненужной сложности и возможных ошибок.
После прочтения "Побиваем С программой в 80 строк на Хаскеле", которую я нашел на ХакерНьюс, я решил, что D может и лучше. И я написал wc на D.
Прим.пер. Я предложил вышеупомянутую статью перевести 0xd34df00d, но он предпочел сделать по мотивам свою «Побеждая C двадцатью строками Haskell: пишем свой wc». И теперь статьи множатся как перепевы «чеканной монетой».
Состоит из одного файла — 34 строки и 712 символов.
import std.stdio : writefln, File;
import std.algorithm : map, fold, splitter;
import std.range : walkLength;
import std.typecons : Yes;
import std.uni : byCodePoint;
struct Line {
size_t chars;
size_t words;
}
struct Output {
size_t lines;
size_t words;
size_t chars;
}
Output combine(Output a, Line b) pure nothrow {
return Output(a.lines + 1, a.words + b.words, a.chars + b.chars);
}
Line toLine(char[] l) pure {
return Line(l.byCodePoint.walkLength, l.splitter.walkLength);
}
void main(string[] args) {
auto f = File(args[1]);
Output o = f
.byLine(Yes.keepTerminator)
.map!(l => toLine(l))
.fold!(combine)(Output(0, 0, 0));
writefln!"%u %u %u %s"(o.lines, o.words, o.chars, args[1]);
}