F# *

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

В предыдущем посте мы открыли Аппликативный функтор, а если точнее, изобрели функцию apply. С ее помощью мы решили проблему валидации полей кредитной карты. Функция apply позволила легко объединить результаты каждой функции, отдельно проверяющей одно поле - номер карты, срок действия и CVV - в объект типа Result<CreditCard>, который представляет финальный результат проверки всех данных кредитной карты на корректность. Возможно, вы также помните, что в случае если у нас есть несколько ошибок валидации, мы решили пойти простым путем и просто возвращать первую из них.

В прошлой части мы разобрали базис тестового фреймворка Expecto. В этой рассмотрим основные подходы написания тестов в контексте Expecto и постепенно перейдём к обобщённым преимуществам-следствиям концепции “тест-объект”. Часть выводов по ходу статьи могут быть полезны и не F#-истам. Однако, как говорилось в первой части, изначально это был монолитный текст, что был разделён почти механически, и я не берусь оценить усвояемость данного материала в отрыве от первой части.

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

Expecto — фреймворк для тестирования, написанный на F# и для F#. Он довольно хорошо известен в рамках F#-сообщества, и у разработчиков, сумевших отгородиться от C# в достаточной степени, используется как платформа для тестов по умолчанию. Новички в F#, а также мимо проходящие C#-еры, как правило, не обращают внимания на данный фреймворк до первого красного теста. А после знакомства впадают в лёгкий аналитический паралич. Ибо то, что со стороны выглядит как ещё один @"{Prefix}Unit" фреймворк для тестирования, на практике оказывается переосмыслением привычных практик.

В данной статье я попробую широкими мазками описать онтологический аппарат Expecto и показать наиболее естественный путь его подчинения. Это не рулбук, а одноразовое введение, которое я предпочёл бы видеть вместо (или до) существующего README.md в официальном репозитории. Также я постараюсь обойтись максимально локальными примерами кода, дабы текст можно было прочитать, не слезая с самоката.

Это перевод статьи из целого цикла постов "Грокаем функциональное программирование" Мэта Торнтона. Я позволил себе немного поменять порядок постов. В оригинале, функторы идут после монад, что мне показалось неверным. Всякая монада - это функтор, но не всякий функтор - это монада. Также я убрал дублирование из поста про монады и добавил необходимые пояснения. Мне нравится практическая направленность материала. Он довольно подробно останавливается на базовых вещах, так что скорее предназначен для тех, кто только знакомится с функциональным программированием.

В этом посте мы постараемся разобраться, что такое функтор собственноручно переизобретая его на рабочем примере.

В предыдущем посте мы переизобрели Монаду на рабочем примере. У нас получился базовый механизм в виде функции andThen для типа option, но мы еще не достигли нашей конечной цели. Мы надеялись, что получится написать код, так же как если бы нам не нужно было обрабатывать значения option. Мы хотели писать в более "императивном" стиле. В этой части мы увидим как достичь этого при помощи технологии computation expressions языка F#, а также углубим наше понимание Монад.

Всем привет. Среди многих интересных концепций, имеющихся в F#, меня привлекли Discriminated Unions. Я задался вопросом, как их реализовать в C#, ведь в нем отсутствует поддержка (синтаксическая) типов объединений, и я решил найти способ их имитации.

Discriminated Unions - тип данных, представляющий собой размеченные объединения, каждый из которых может состоять из собственных типов данных (также именованных).

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

Для создания своих Discriminated Unions будем использовать эту мысль

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

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

Задачу я встретил, решая упражнения из книги Структура и Интерпретация Компьютерных Программ).

Раздел 2.3 посвящён цитированию в LISP и символическим вычислениям.

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

Что может быть лучше десятка пары часов проведенных с дженериками и compile time safety в C#?

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

Вы можете быть новичком в .NET или опытным разработчиком C#/VB.NET, который хочет расширить свои горизонты. В любом случае, F# -- отличный язык для изучения.

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

Если вы хотите изучить F#, сейчас идеальное время -- у нас есть много свежих видео, курсов и многого другого, чтобы помочь вам начать работу уже сегодня.

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

Теперь в AngouriMath есть инструменты работы с матрицами, улучшенный парсер, много новых функций, практически полностью переписанный пакет Interactive (для работы в Jupyter) и многое другое.

Эта статья повествует о большом обновлении в FOSS библиотеке символьной алгебры для .NET

Этот пост служит для того, чтобы освежить в памяти, а некоторых познакомить с базовыми возможностями функционального программирования на языке Python. Материал поста разбит на 5 частей:

Главная задача этого поста – показать один мало применяемый на языке Python архитектурный шаблон под названием «функциональное ядро - императивная оболочка», в котором функциональный код концентрируется внутри, а императивный код выносится наружу в попытке свести на нет недостатки каждого из них. Известно, что функциональные языки слабы при взаимодействии с «реальным миром», в частности с вводом данных пользователем, взаимодействием с графическим интерфейсом или другими операциями ввода-вывода. В рамках такого подхода весь императивный код выталкивается наружу, и внутри остается только функционально-ориентированный.

Спустя 210 дней, 600 коммитов, десятки дебажных ночей и тысячи сообщений в обсуждениях проекта, я таки выпустил релиз AngouriMath 1.2.

Это небольшая опен-сорсная библиотека символьной алгебры для C# и F#, но вдруг кому-нибудь интересно?

Сегодня я хочу рассказать вам о таком замечательном инструменте как "dotnet interactive". Я покажу на своём примере как и для чего я начал его использовать, и вкратце опишу с чего начать.

Предисловие

Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков — отрицание, — C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось — и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var — но как сделать то, что я хотел?

Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.