Легкая прогулка от функтора через монаду к стрелке


    Давайте совершим прогулку по цепочке Pointed, Functor, Applicative Functor, Monad, Category, Arrow, в процессе которой я попытаюсь показать что все это придумано не для того что бы взорвать мозг, а для решения вполне реальных проблем, притом существующих не только в haskell. Большая часть кода написана на C#, но думаю и без его знания можно будет понять что к чему.

    Примеры


    Хотя в примерах используются примитивные операции над int, при желании, в место них можно придумать что нибудь более жизненное, например в аппликативном функторе, можно рассмотреть такой вариант
    Maybe<int> userId = UserService.GetUserId(email)
    Maybe<int> productId = ProductService.GetProductId(productCode)
    Maybe<int> discount = Maybe<int>.Nothing;
    if(userId.HasValue && porductId.HasValue)
        discount = new Maybe(DiscountService.GetDiscount(userId.Value, productId.Value));
    


    Введение


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

    	public class Maybe<T> {
    		public static readonly Maybe<T> Nothing = new Maybe<T>();
    		public T Value { get; private set; }
    		public bool HasValue { get; private set; }
    
    		private Maybe() { }
    
    		public Maybe(T value) {
    			Value = value;
    			HasValue = true;
    		}
    
    		public override string ToString() {
    			if (HasValue)
    				return Value.ToString();
    			return "Nothing";
    		}
    	}
    
    

    Пример

    Maybe<User> GetUserById(int id){...}
    

    Что есть класс Maybe<A>? Можно считать его функцией над типом, которая все обычные типы A переводит в специализированные типы Maybe<A>, int -> Maybe<int>, будем называть их уровнями, а преобразование — переходом между ними.

    Pointed


    Проблема номер один: нам необходима функция которая позволит сделать переход A -> Maybe<A>, напишем ее.
    
    	static class Pointed {
    		public static Maybe<A> Pure<A>(this A value) {
    			return new Maybe<A>(value);
    		}
    	}
    


    Для тех кто не знаком с C#, ключевое слово this позволяет использовать функцию через точку после объекта

    Пример

    	void Pointed() {
    		int x = 1;
    		Maybe<int> y = x.Pure();
    	}
    


    Теперь мы можем все что угодно поднять на уровень Maybe.

    Функтор


    Хорошо, поднять мы подняли, но у нас осталось куча функций которая работает для предыдущего уровня, то есть все функции вида A → B, и просто так мы их уже использовать не можем. Что же делать? Очевидно, можно каждый раз проверять есть ли в Maybe что либо, и если есть, применять функцию к тому что в нем содержится, если нет, возвращать Nothing, собственно тот сценарий который используется в случае проверки на null. Что бы придерживаться DRYйя поместим эту логику в отдельную функцию.

    	static class Functor {
    		public static Maybe<B> Map<A,B>(this Maybe<A> maybe, Func<A,B> f) {
    			if(maybe.HasValue) return f(maybe.Value).Pure();
    			return Maybe<B>.Nothing;
    		}
    	}
    


    Пример

    	void Functor() {
    		Func<int, int> inc = y => y + 1;//обычная функция int -> int
    		var x = 1.Pure();//получаем переменную на уровне Maybe
    		var r = x.Map(inc); //применяем обычную функцию к переменной на новом уровне, r == Some(2)
    	}
    
    


    Таким образом мы подружили старые функции с новым уровнем.

    Аппликативный функтор


    Функции одной переменной нам покорилась, что делать с функциями принимающих несколько параметров (A,B) → C? Очевидно map нам тут особо не поможет. Решение есть, но для начало вспомним что такое каррирование — это преобразование функции таким образом что бы ее возможно было частично применить и получить на выходе новую функцию. add(x,y) = x + y; inc = add(1); inc(10) == 11;
    Напишем вспомогательную функцию для перевода Func к такому виду.

    	static class CurryFunc {
    		public static Func<T1,Func<T2,R>> Curry<T1,T2,R>(this Func<T1,T2,R> f) {
    			return x => y => f(x, y);
    		}
    	}
    

    Пример

    	void Curry() {
    		Func<int,int, int> add = (y,z) => y + z;
    		var inc = add.Curry()(1);
    		var r = inc(1); // r == 2
    	}
    


    И напишем метод apply который поможет решить нашу первоначальную проблему.

    	static class Applicative {
    		public static Maybe<B> Apply<A,B>(this Maybe<Func<A,B>> f, Maybe<A> maybe) {
    			if(f.HasValue) return maybe.Map(f.Value); // если функция есть, значит применяем ее с помощью Map
    			return Maybe<B>.Nothing;
    		}
    	}
    


    Пример

    	void Applicative() {
    		Func<int, int, int> addF = (y,z) => y + z;
    		var add = addF.Curry();
    		var x1 = 1.Pure();
    		var x2 = 2.Pure();
    		var r = add.Pure().Apply(x1).Apply(x2); // Скаррировав функцию и подняв до уровня Maybe мы можем ее применить,  r == Some(3)
    		Func<int,int,int> f = DiscountService.GetDiscount;
    		var discount = f.Curry().Pure().Apply(userId).Apply(productId); //Пример из самого начала
    	}
    


    Подход работает для любого количества переменный, достаточно иметь соответствующую функцию curry.
    Func<int, int, int, int, int> addF = (a,b,c,d) => a + b + c + d;
    addF.Curry().Apply(x1).Apply(x2).Apply(x3).Apply(x4);
    


    Монада


    С обычными функциями окончательно разобрались, но раз у нас есть два уровня, то значит возможны и функции вида A → Maybeнапример тот самый GetUserById :: int -> Maybe<User>
    Решить с помощью map не выйдет. так как в результате получим Maybe<Maybe<B>>, поэтому нам нужна еще одна функция

    	static class Monad {
    		public static Maybe<B> Bind<A,B>(this Maybe<A> maybe, Func<A,Maybe<B>> f) {
    			if(maybe.HasValue) return f(maybe.Value);
    			return Maybe<B>.Nothing;
    		}
    	}
    

    Пример

    	void Monad() {
    		Func<int, Maybe<int>> solve = y => y == 0 ? Maybe<int>.Nothing : (y + 1).Pure();
    		var x = 1.Pure();
    		var y = 0.Pure();
    		var r1 = x.Bind(solve); // r1 == Some(2)
    		var r2 = y.Bind(solve); // r2 == Nothing
    	}
    
    


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

    Категория


    Давайте перейдем к вопросу композиционного стиля программирования. Посмотрим какие здесь нам ставить проблемы Maybe и как их можно решить.
    Что такое композиционный стиль? Подход когда мы вместо того что бы применять функции одна за другой к результату вычисления, объединяем их в некое подобие конвейера который образует в свою очередь новую функцию, например
    f = length . filter (>3) . map (+1) . skip 3  
    

    (.) оператор композиции в хаскеле.
    f - функцию пропускает первые три элемента, прибавляет 1 ко всем остальным, фильтрует все что больше трех и возвращает длину полученного списка.
    Стиль отличается удобством и наглядность, поэтому достаточно популярен в хаскеле.

    Полагаю у вас в подсознии уже начал мелькать образ теории категорий, и это не с проста. Давайте вспомним о чем там идет речь. У нас есть некий класс объектов, для каждой пары из которого задано множество морфизмов. Эти объекты с ихними морфизмами и являются категорией. Для простоты можно представить как направленный граф, где объекты это узлы, а морфизмы это ребра. Так вот для морфизмов как раз и определено понятие композиции, f: A → B, g:B → C получаем f compose g: A → C. Можно определить категорию для языка программирования, где объекты это простые типы, а морфизмы это функции.

    Вернемся к композиционному стилю. У обычных функций с ним нет никаких проблем.

    	static class Category {
    		public static Func<A,C> Compose<A,B,C>(this Func<B,C>f1, Func<A,B> f2) {
    			return x => f1(f2(x));
    		}
    	}
    

    Пример

    	void Category() {
    		Func<int, int> f1 = y => y + 1;
    		Func<int, int> f2 = y => y * 2;
    		var fr = f2.Compose(f1);
    		var r = fr(1);// r == 4
    	}
    


    Однако у функций вида A → Maybe<B>, B → Maybe<C> проблема есть и заключается она в том что выход одной не состыкуется с входом другой.

    Так как у нас сейчас пойдет много сигнатур вида A → Maybe<B> давайте напишем для них обертку. Можно и без нее, но с ней как то по нагляднее. Категория Клейсли - категория где морфизмы имеют вид A → M<B>

    	class Kleisli<A,B> {
    		public Func<A,Maybe<B>> Func { get; set; }
    		public Kleisli(Func<A,Maybe<B>> f) {
    			Func = f;
    		}
    	}
    
    
    

    Напишем функцию для их композиции.

    static class Category {
    		public static Kleisli<A,B> ToKleisli<A,B>(this Func<A,Maybe<B>> f) {
    			return new Kleisli<A, B>(f);
    		}
    
    		public static Kleisli<A,C> Compose<A,B,C>(this Kleisli<B,C> f1, 
    			Kleisli<A,B> f2) {
    			return ToKleisli<A,C>(x => f2.Func(x).Bind(f1.Func));
    		}
    	}
    
    

    Пример

    
    	void Category2() {
    		Func<int, Maybe<int>> f1 = y => (y + 1).Pure();
    		Func<int, Maybe<int>> f2 = y => (y * 2).Pure();
    		var fr = f2.ToKleisli().Compose(f1.ToKleisli());
    		var r = fr.Func(1); //r == Some(4)
    	}
    

    Если не использовать оберток, запись была бы точно такое же как и у обычных функций f2.Compose(f1)
    Теперь мы можем создавать композиции из Клейсли морфизмов.

    Стрелка


    Вот мы и подошли к последней проблеме. У нас есть функции двух видом А -> B, B -> Maybe<C> и законное желание соединять их между собой. При текущем раскладе это у нас не получится, но как всегда можно написать функцию которая решит все наши проблемы
    
    	static class Arrow {
    		public static Kleisli<A,B> Arr<A,B>(this Func<A,B> f) {
    			return Category.ToKleisli<A,B>(x => f(x).Pure());// Преобразуем обычную функцию в Клейсли
    		}
    	}
    
    

    Пример

    	void Arrow() {
    		Func<int, int> f1 = y => y + 1;
    		Func<int, int> f2 = y => y * 10;
    
    		Func<int, Maybe<int>> fm1 = y => (y * 2).Pure();
    		Func<int, Maybe<int>> fm2 = y => (y - 5).Pure();
    		var fa1 = f1.Arr();
    		var fa2 = f2.Arr();
    		var fk1 = fm1.ToKleisli();
    		var fk2 = fm2.ToKleisli();
    		var fr = fk2.Compose(fa1).Compose(fk1).Compose(fa2);
    		var r1 = fr.Func(2); // r1 == Some(36)
    		// опять же без обертки можно было бы написать var r1 = f2.Compose(f1.Arr()).Compose(f1).Compose(f2.Arr())(2)
    	}
    

    Итого: мы можем комбинировать функции обоих видом, как нам заблагорассудится.

    У стрелок еще есть много интересных функций, с помощью которых можно виртуозно жонглировать конвейерами практически любой сложности. Например, как так compose по сути последовательное вычисление, то можно предположить что есть и параллельное: (&&&) - распаралеливает конвейер, (***) - производить параллельные вычисления и пр. Но пожалуй на этом мы остановимся.

    Заключение


    Надеюсь я смог передать некую красоту и логичность всех вышеописанных конструкций, и возможно у вас возникнет вопрос, почему же такая иерархия практически ни в каких языках не встречается. Ответ скорее всего в том что, для нормальной реализовать нужна система типов сложнее чем в том же C#. Например если мы заходим написать все тоже для списков, которые являются точно таким же переходом между уровнями A -> List<A>, то нам придется продублировать ~90% кода, так как возможности для обобщения практически никакой нет. Для примера можно посмотреть как это все может выглядеть на хаскеле, где за счет типов классов и полиморфизма высшего порядка существенная часть абстракций выделена, и вместо того что бы работать с Maybe все манипуляции происходят над обобщенным типом M<A>где M может быть любым типом с одним параметром Maybe<A> List<A> и пр.

    Для желающих углубиться в затронутую тему, рекомендую учебник http://anton-k.github.com/ru-haskell-book/book/toc.html, в нем уделено внимание как практической составляющей хаскеля, так и теоретическим основаниям, плюс это возможно единственных учебник(или по крайней мере один из не многих) на русском где описывается теория категорий в контексте программирования.

    Код на haskell



    import Prelude hiding (Functor,map,Monad)
    
    class Pointed f where
    	pure :: a -> f a
    
    instance Pointed Maybe where
    	pure = Just
    
    class Functor f where
    	map :: (a -> b) -> f a -> f b
    
    instance Functor Maybe where  
    	map f (Just x) = Just (f x)  
    	map f Nothing = Nothing  
    
    class (Functor f, Pointed f) => Applicative f where
    	apply :: f (a -> b) -> f a -> f b
    
    instance Applicative Maybe where  
    	apply Nothing  _ = Nothing  
    	apply (Just f) something = map f something  
    
    class Applicative f => Monad f where
    	bind :: f a -> (a -> f b) -> f b
    
    instance Monad Maybe  where
    	bind (Just x)  k      = k x
    	bind Nothing   _      = Nothing
    
    newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }
    
    class Category cat where
    	compose :: cat b c -> cat a b -> cat a c
    
    instance Category (->) where
    	compose f g = \x -> f (g x) 
    
    instance Monad m => Category (Kleisli m) where
    	compose (Kleisli f) (Kleisli g) = Kleisli (\b -> bind (g b) f)
    
    class Category a => Arrow a where
    	arr :: (b -> c) -> a b c
    
    instance Arrow (->) where
    	arr f = f
    
    instance Monad m => Arrow (Kleisli m) where
    	arr f = Kleisli (compose pure f)
    
    


    Upd: Давайте еще раз выпишем наш как бы реальный пример из жизни и рассмотрим два способа решения.
    Классическое решение данной проблемы:
    Maybe<int> userId = UserService.GetUserId(email);
    Maybe<int> productId = ProductService.GetProductId(productCode);
    Maybe<int> discount = Maybe<int>.Nothing;
    if(userId.HasValue && porductId.HasValue)
        discount = new Maybe(DiscountService.GetDiscount(userId.Value, productId.Value));
    

    Что в нем плохого? Мне кажется явное выписывание if, которое усложняет восприятие кода.
    Давайте посмотрим на второе решение:
    Func<int,int,int> f = DiscountService.GetDiscount;
    Maybe<int> discount = f.Curry().Pure().Apply(userId).Apply(productId);
    

    В чем его плюс? Думаю в том что нам совершенно не нужно задумываться, а что там у нас в userId и productId, код получается более декларативным.
    Поделиться публикацией

    Похожие публикации

    Комментарии 152

      +10
      а можно все-так ещё раз просуммировать решаемые проблемы? не совсем понятна важность 10 страниц текста
        +2
        При образовании нового типа M<A> возникают проблемы с использованием старых функций
        1) A -> B 
        2) (A,B) -> C
        Так же у нас получается новый тип функций A -> M<B> у которых есть проблемы с 
        3)Применением
        4)Композицией между собой
        5)Композицией со старыми функциями
        
          –1
          А с практической точки зрения?
            +1
            Пример с GetDiscount не практический? Можно городить кучу ifов, а можно использовать абстракции. Да на C# выглядит страшно, так как он не совсем подходит под такой стиль.
              –2
              int discount = DiscountService.GetDiscount(userId.Value, productId.Value)
              Что произойдет вот в этом месте? внутри userId.Value будет null или выбросится исключение на моменте получения userId?
              Какой конкретно профит? Потому и говорю, приведите полноценный пример, иначе нихрена не понятно.
                +1
                DiscountService.GetDiscount(userId.Value, productId.Value)
                Этот код я привел для простоты, конечно же он не корректный, так как в случае если один из них Nothing то Value == 0. Правильное решение дальше по тексту

                Func<int,int,int> f = DiscountService.GetDiscount;
                var discount = f.Curry().Pure().Apply(userId).Apply(productId);
                

                Получается более прозрачная запись, так как нам вообще не приходится задумываться есть там что то в userId и productId или нет.
                  +3
                  Да, я уже дочитал дальше. Если честно стиль изложения у вас слишком «матанистый». Хорошо, что я знаком уже с этой темой, но реально понять, о чем идет речь сложно сходу. И кстати, я бы назвал метод не Pure, а Maybe, для понятности:)
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Вот, я помнил, что где-то уже про это читал, спасибо:)
                  +2
                  Кстати да, это мой пост, есть еще тут, отличается от того что приведено тут в статье тем, что подход реально можно использовать, т.е. брать существующие API где null используется вроде аналога F#‘ного Nothing и делать проверки с этим допущением.

                  Вообще переписывать все как показано в статье я бы не рекомендовал вообще т.к. непонятно, какие конкретно задачи это решает. Одно дело убрать проверки на null – в этом смысле подойдет мой метод. А каррирование например? Каррирование и функциональная композиция на практике нужны мало где – например редко где нужно делать вызовы вроде f(g(h(x))) а даже если нужно, это не так страшно. Я много пишу на F# но даже там операторы << и >> у меня не возтребованы, хотя конечно |> я пользуюсь т.к. удобно (но не критично).
                    0
                    О как, спасибо за статьи, читаю постоянно:)
                      0
                      А, так Monads это ваша библиотечка?)
                        0
                        Что? Какая библиотечка? Не знаю о чем вы
                          0
                          Вот эта. Но она действительно не ваша.
                            0
                            Да, это не мое. На практике монады — очень индивидуальной явление. Каждый допиливает реализацию под свои нужды. Не думаю что можно создать что-то обобщенное. Например многие люди несогласны с моим подходом к именованию методов и возможно они правы.
                  +1
                  Ценность монад и прочего — в том, что они обобщают кучу вещей: nullable, списки, парсеры, исключения, цепочки колбеков, всякие недетерминированные вычисления, и много-много еще чего.

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

                  В C# есть LINQ, который выполняет все три перечисленные функции, и очень сильно похож на монады.

                  К сожалению, C# зарелизился не успев быть вылизанным, многие косяки уже не исправить. В частности в C# есть null, а мог бы быть Nulllable<> и для ссылочных типов. Теперь у нас есть зоопарк из null и Nullable<>, статья добаляет еще и третью сущность, и через это примеры статьи выглядят неудачно и непрактично. Если бы у нас был бы один Nullable<>, то к гадалке не ходи — был бы LINQ2Nullable и все бы юзали и были рады. Ну увы.

                  Вот хороший пример того, как можно понимание монад совокупить с LINQ и получить годный, практичный результат: code.google.com/p/sprache/
                    0
                    В частности в C# есть null, а мог бы быть Nulllable<> и для ссылочных типов.

                    Только это не в C#, а в BCL.
                  0
                  а зачем образовывать новый тип? похоже на решение проблемы введением дополнительного абстрактоного слоя.

                  а теперь вернемся на землю. у меня два контр-аргумента:
                  1) если c# — то там есть Nullable. Но даже при его использовании вылезает пункт 2
                  2) допустим где-то значение Maybe пришло в Nothing. Нет гарантии, что логическая цепочка из композиций сработает верно. А в случае null — мы получим NRE. И это будет именно exception — исключительная ситуация. И если это будет NRE — то об этом нужно логировать/сообщить/пойти альтернативным путем. В случае Maybe — это происходит за счет Maybe.HasValue, что и продемонстрировано в примерах. В итоге — разницы никакое

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

                    Отчет весьма прост: свойство Value у Maybe вызываться не должно. Ни когда. Его вообще быть не должно.
                    Это промах автора, что рассказывать про Maybe он начинает с метода, превращающего Maybe в кривой null.

                    Если не пользоваться Value, а обращаться к значению только через Map, FlatMap и т.д., то NRE исчезает и на смену ему ни что не приходит (см мой пример).
                      0
                      конечно не приходит. и в простых случаях (типа калькулятора — а все примеры на этом и основаны) этого достаточно. то есть в цепочечном вызове это можно использовать для короткой записи.

                      поясню, почему медитация академическая:
                      — не везде типы ссылочные.
                      — не так как хотелось бы исчезает NRE — я не вижу его cause. вернулся null или Nothing — хорошо. а ответа на вопрос «почему?» — нет.

                      прямо как в rails — «пишем быстро». особенно доставило в статье на gotdotnet абзац про «я сначала пишу как обычно, отлаживаю, а потом переписываю через монаду»

                      я не увидел, что за сомном букв и матанализом скрывалась какая-то серьезная мысль. да и не так human-friendly, как утверждают авторы (кстати, с этого и начинается статья на gotdotnet-е) на мой взгляд.

                      а так — я ж говорю, интересно читать, как люди с интересм тратят время. в любой компании должен быть один теоретик-архитектор. иначе скучно
                        0
                        Ссылочность не важна: Nullable — struct.

                        NRE бесполезен если вы всегда знаете что вам приходит. И если вы хотите проконтролировать, что какой-то Maybe не пуст, то вы можете это сделать множеством более осмысленных способов и бросок исключения далеко не всегда лучший из них.

                        А писать сначала обычно. а потом через монаду — это какое-то странное эстетство. На scala я пишу сразу по человечески — так гораздо удобнее. Да и на C# я пишу сразу LINQ, а не сначала foreach, а потом LINQ.
                          0
                          «Ссылочность не важна: Nullable — struct» не про то была фраза.

                          представьте что пишется какой-то контракт, самый простой.

                          class Calculator {
                          public int add(int a, int b) { return a + b; }
                          }

                          автор предлагает мне заменить это на:

                          class Calculator {
                          public Maybe Add(Maybe a, Maybe b) { return a.HasValue && b.HasValue? a.Value + b.Value: Maybe.Nothing; }
                          }

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

                          это то самое упрощение о котором говорит автор или нет?

                          ps. а апдейт к статье вообще страшный. вы будете пользоваться приложением, которое на любое нарушение преусловий будет говорить — «не шмогла»? а вы будете снова и снова вбивать один и тот же код продукта, не подозревая, что он уже не валиден.
                            0
                            Автор как раз на оборот не предлагает ничего менять, а говорит, что вот у вас появился новый тип Maybe<T> и остались старые функции А->B
                            соответственно ваш Add остается таким как бы, (int,int) -> int но его нельзя просто так использовать с новым типом, поэтому то и нужны доп телодвижения.
                              0
                              извиняюсь, source для кода не сработал…
                      0
                      Я правильно понимаю, что это некая страшная эмуляция «nullable data type» при отсутствии ее поддержки языком программирования? То есть то же самое на питоне:

                      userId = UserService.GetUserId( email ) # Может быть None
                      productId = ProductService.GetProductId( productCode ) # Может быть None
                      discount = DiscountService.GetDiscount( userId, productId) # Не нужно ".value", переживает None.
                      if discount is None :
                        # Тут бизнес логика "не найдено".
                      


                      BTW, в начале статьи вы написали фрагмент кода:

                      int discount = DiscountService.GetDiscount(userId.Value, productId.Value) // не корректное решение
                      


                      Что в нем значит комментарий «не корректное решение»? Что это некий неправильный фрагмент кода, который не показывает практическое применение монады? Или он показывает практическое прменение монады для написания неправильного кода? Или что? Запутали старика :(.
                        0
                        С питоном тут сравнивать не стоит просто по тому, что в статье подразумевается статическая типизация и защита от NRE во время компиляции.

                        А некорректность решения в том, что оно обходит защиту от NRE. Вызов Value почти всегда вреден ибо опасен.
                          0
                          С динамическими тут вообще сложно сравнивать, так как там можно делать все что пожелаешь.
                          Но представьте если бы у вас DiscountService.GetDiscount на входе требовал что бы оба параметра были не None.
                          Заменил некорректное, на классическое.
                            0
                            С динамическими тут вообще сложно сравнивать, так как там можно делать все что пожелаешь.


                            Не обижайтесь, я просто для примера взял первый попавшийся язык с поддержкой nullable data type. Могу то же самое переписать на java, ruby, objective-c. Могу на C# — но я на нем давно не писал, боюсь ляпну что-нибудь, а народ как набежит с LINQ, замыканиями и пятой версией — и все O_O.

                            Но представьте если бы у вас DiscountService.GetDiscount на входе требовал что бы оба параметра были не None.


                            Представил:

                            if userId is not None and productId is not None :
                              discount = DiscountService.GetDiscount( userId, productId)
                            


                            Все еще непонятно, чем представленное отличается от эмуляции Nullable Data Type (BTW, так все равно писать нельзя — но это отдельный вопрос, который в рамках обсуждения этой статьи неуместен).
                              0
                              Вот что бы так не писать, я в самом последнем примере показал второе решение
                              discount = DiscountService.GetDiscount.Curry().Pure().Apply( userId).Apply(productId)
                              Которое мне кажется более прозрачным из за отсутствия if.
                                0
                                Maybe<int> discount = DiscountService.GetDiscount.Curry().Pure().Apply(userId).Apply(productId);
                                


                                Фееричный, нечетаемый звиздец? применить карирование, создание функтора и тапнуть полученного монстрика два раза только для того, чтобы не вызвать метод с неверным аргументом? Чем это лучше кучки if'ов, кроме того что на поддержку данного кода придется разработчика искать в три раза дольше и в два раза дороже?
                                  0
                                  (userId |@| productId) {DiscountService.GetDiscount(_, _)}
                                  


                                  Так лучше?

                                  Или может так:

                                  for {
                                    u <- userId
                                    p <- productId
                                  } yield DiscountService.GetDiscount(u, p)
                                  
                                    0
                                    for {
                                      u <- userId
                                      p <- productId
                                    } yield DiscountService.GetDiscount(u, p)
                                    


                                    Извиняюсь за необразованность — а это вообще какой язык программирования и какое отношение это имеет к обсуждаемой эмуляции монады?
                                      0
                                      Scala

                                      Приведен как пример ФП языка с более понятным чем у хаскеля синтаксисом.

                                      К эмуляции подобного поведения на C# относится только как иллюстрация, что есть куда стремиться.

                                      Скорее это иллюстрация того, что при хорошей реализации данный подход не многословен и семантичен.
                                        0
                                        Скорее это иллюстрация того, что при хорошей реализации данный подход не многословен и семантичен.


                                        Это вы сейчас про скалу, или про то «функтор().частично().тапнуть().тупнуть().наизнанку().застрелиться()» которое мы выше на C# обсуждали? :)
                                          0
                                          функтор().частично().тапнуть().тупнуть().наизнанку().застрелиться()

                                          И это вместо

                                          productId.With(p => userId.With(u => DiscountService.GetDiscount(u, p)));
                                          
                                            0
                                            Вот это не совсем то, что я бы назвал «хорошей реализацией», но, как уже писал автор, C# не очень-то располагает к подобным фокусам.
                                          0
                                          for в скале, как и LINQ в .net — синтаксис для чего-то типа монад.
                                        0
                                        Проблема не в идеи, а в том что язык не очень подходит для такого стиля. Вот как выглядит на хаскеле
                                        getDiscount <$> userId <*> productId
                                          0
                                          А на objective-c вообще можно вызвать метод для null и получать в результате null :) Я правильно понимаю, что на практике использовать монады без поддержки языка не получится благодаря нечитаемому звездицу, который в результате вырисовывается?
                                            +1
                                            Скорее всего да. Например, хоть в скале и есть библиотека scalaz но насколько я понимаю большинство от нее плюются, данные концепции должны быть у истоков языка, как например в хаскеле. Если интересно, можете почитать мою старую статью
                                            habrahabr.ru/post/112464/
                                            там используется для монад сахар от linq.
                                              0
                                              Я читал. Но в данный момент меня эта статья больше интересует. Потому как одно дело «абстрактное множество, для пар элементов которорго мы задаем кортежи аппликативных бульбуляторов», а другое дело — некое практическое применение на языке программирования общего назначения. Но, увы, не взлетело :(.
                                                +1
                                                Хаскель вполне язык общего назначения.
                                                  0
                                                  Википедия с вами не согласна:
                                                  en.wikipedia.org/wiki/General-purpose_programming_language

                                                  Хотя, с другой стороны, кого эта википедия интересует :).
                                                    0
                                                    По вашей ссылке есть другие ФП, в которых есть практическое применение всех описаных практик.
                                                      0
                                                      Я знаю :).
                                                        0
                                                        Только я подозреваю что не у одного из них из коробки нет монад.
                                                          0
                                                          Мотря что вы под ними подразумеваете.

                                                          Там есть scala.
                                                            0
                                                            Разве в Scala в дефолтной поставке есть функторы монады категории?
                                                              0
                                                              Если нет в дефолтной, то есть в scalaz, но я бы не сказал, что scalaz так уж необходима.
                                                        +1
                                                        some general-purpose languages:
                                                          0
                                                          И это я тоже знаю :).
                                  +1
                                  Сам тип Maybe или его аналоги нужен для избавления от NullReferenceException.
                                  При помощи подобных конструкций ответственность перекладывается на компилятор.

                                  Автор забыл упомянуть, что все далее верно не только для Maybe, но и для любого другого контейнера (всевозможные коллекции). Это позволяет единообразно работать со всеми контейнерами.

                                  В остальной части статьи описывается создание инструментов для удобной работы с Maybe. К сожалению не упомянуто, что чтобы все это имело смысл точно такие же инструменты должны существовать и для остальных контейнеров. Так же не упомянуты некоторые другие базовые инструменты, такие как перевод M<M> -> M.

                                  К сожалению не показаны примеры использования, иллюстрирующие превосходство такого подхода над другими.
                                    0
                                    Код съелся:
                                    M<M<T>> -> M<T>
                                      0
                                      В заключении я как раз упомянул про List<T>. В C# наличие инструментов для других сущностный особой пользы не принесет, так как они будут не связаны, как, опять же, я написал в заключении. Не увидел смысла упоминать join, помоем достаточно bind.
                                      А какой пример бы привели вы на C#? Мне показалось, что раз я описываю проблему и ее решение, то человек уже сам при желании может сравнить как бы он решил ее старыми способами.
                                        +1
                                        Под примером я подразумевал сравнение подходов.
                                        Это савнение должно быть простым, но при этом достаточно жизненным.

                                        Постараюсь воспроизвести для C# класический пример для scala с получением первой сестры прабабушки по отцовской линии:

                                        Null:
                                        public Person GetFathersMothersSister(Person person)
                                        {
                                        	if (person == null)
                                        		return null;
                                        	var father = person.GetFather();
                                        	if (father == null)
                                        		return null;
                                        	var fathersMother = father.GetMother();
                                        	if (fathersMother == null)
                                        		return null;
                                        	return fathersMother.GetSisters().FirstOrDefault();
                                        }
                                        


                                        Maybe:
                                        public Maybe<Person> GetFathersMothersSister(Maybe<Person> person)
                                        {
                                        	return
                                        		person
                                        			.FlatMap(p => p.GetFather())
                                        			.FlatMap(f => f.GetMother())
                                        			.FlatMap(m => m.GetSisters().FirstMaybe());
                                        }
                                        
                                    –2
                                    Неужели вот такая запись:

                                    f = length . filter (>3) . map (+1) . skip 3

                                    считается логичной и читабельной?

                                    Я это прочел как «взять некую длину (список чего-то?), отфильтровать, увеличить и пропустить», а не так, как вы это описали.
                                      0
                                      Ну, эта запись соответствует принятой в математике:
                                      (f ∘ g)(x) = f(g(x))
                                      =>
                                      (length ∘ (filter (>3)) ∘ (map (+1)) ∘ (skip 3)) x = length((filter (>3))((map (+1))((skip 3)(x))))
                                      Хотя мне больше нравится синтаксис OCaml/F# для этого:
                                      Seq.length << (Seq.filter ((>) 3)) << (Seq.map ((+) 1)) << (Seq.skip 3)
                                      или, эквивалентно:
                                      (Seq.skip 3) >> (Seq.map ((+) 1)) >> (Seq.filter ((>) 3)) >> Seq.length
                                        0
                                        Дело привычки. На F# пишут так
                                        skip 3 |> map (+1) |> filter (>3) |> length
                                        Этот вариант наверное покажется более читабельным из-за того, что практически у всех современных языков операции над объектами идут через точку x.DoSomething()
                                          0
                                          Это pipelining, а не композиция. Его обычно используют так:
                                          someList 
                                          |> Seq.skip 3
                                          |> Seq.map ((+) 1)
                                          |> Seq.filter ((>) 3)
                                          |> Seq.length

                                          Разницу легко понять, если взглянуть на типы:
                                          > (|>);;
                                          val it : ('a -> ('a -> 'b) -> 'b)
                                          > (>>);;
                                          val it : (('a -> 'b) -> ('b -> 'c) -> 'a -> 'c)
                                          

                                          Ну и да, на самом деле версия с композицией не скомпилируется, если дальше мы где-то не используем полученную функцию, из-за value restriction, но это уже совсем другая история...)
                                            0
                                            Да, подзабыл F#.
                                          +1
                                          Наверное вам больше подойдет scala:
                                          numbers.drop(3).map{_+1}.filter{_>3}.length
                                          Примерно то же самое реализованов LINQ.

                                          В примере автора все становится понятнее если заменить точки на пары скобочек.
                                          Не валиднный, но более понятный код: length ( filter (>3, map (+1, skip 3 ))). То есть исходный код надо читать справа на лево.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            +6
                                            «для решения вполне реальных проблем, притом существующих не только в haskell»

                                            Но мы вам про них не скажем. Зачем?

                                              0
                                              Вы не поняли описание проблем по ходу статьи?
                                                +4
                                                Для людей, привыкших к null и считающих его естественным, Maybe выглядит просто как многословный аналог null.

                                                Действительно очень сложно понять пока не начнешь этим постоянно пользоваться.

                                                Тем, кто понимает, этастатья уже полезна не будет.
                                                А остальным надо очень наглядно объяснить в чем проблема и почему это решение.
                                                  0
                                                  Поддерживаю. Вот я пока морально не готов изучить хаскель — из статьи понял только что сделали кривую эмуляцию «nullable data type», походя допустив несколько грубейших архитектурных ошибок О_О. Зачем? Почему? Кому все это надо?

                                                  А вот знал бы я хаскель — саразу бы все понял. Наверное.
                                                    0
                                                    Если хаскель для вас перебор, как, например, для меня, то возможно стоит обратить внимание на scala — там все проще, но при этом поддерживается полноценное ФП.
                                                      +1
                                                      Да он не то чтобы перебор — у меня по работе мало алгоритмических задач, и тратить достаточно много времени на изучение теорикрафта, который заведомо не будет использоваться не очень хочется. Вот наберется естественным образом некая практическая база используемых подходов функционального программирования — тогда можно будет и изучить. Для подведения теоретической базы под практику. А без практики это будет всего лишь двадцать первый язык программирования который я «как бы знаю» и который мертвым грузом осядет в конспектах :).
                                                  0
                                                  Честно говоря — нет. Пришлось пойти по ссылке на другую статью и потратить минут 15, чтобы понять, что речь идет о полях-объектах, которые не инициализированы.

                                                  Дальше опять стало трудно понимать, поскольку неясно, что мешает проинициализировать эти поля.

                                                  Программирую на Delphi, не смог в голове построить аналог проблемы.

                                                  0
                                                  У подобного подхода есть множество плюсов.

                                                  Самый наглядный — это возможность наконец исправить «ошибку стоимостью в миллиард долларов». Полностью избавиться от самого понятия null.

                                                  При написании программы вы в любом месте знаете получите вы A или Maybe. И компилятор не позволит вам обращаться с Maybe как с A.

                                                  Другой плюс — это большая семантичность кода. Вместо получения кучи промежуточных значений, многие из которых не имеют самостоятельного смысла, вы пользуетесь копозицией функций. Вы избавляетесь от множества промежуточных точек выхода вида «if (a == null) return null». Одна точка выхода — это всегда лучше.

                                                  Ну и кроме прочего избавляясь от явного состояния мы становимся на шаг ближе к immutable подходу, что очень хорошо для многопоточного программирования, да и вообще для простоты понимания кода.
                                                    0
                                                    Я не очень понимаю, что значит «избавиться от null».

                                                    Если мне нужен объект, а вместо него вижу null, то надо бросать исключение.

                                                    Разве нет?

                                                      0
                                                      Нет.

                                                      Избавиться от null означает избавиться от ситуации «Если мне нужен объект, а вместо него вижу null».
                                                        0
                                                        Подробнее:

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

                                                        И нет возможности отличить переменную, которая может быть null от переменной, которая null быть не может. Так что программисты забывают обработать ситуацию, когда переменная может быть null и получают NRE в рантайме.

                                                        Maybe же позволяет переложить ответственность на компилятор, что надежнее.
                                                          0
                                                          Maybe позволяет переложить ответственность на компилятор только тогда, когда компилятор умеет ловить ситуации, когда не все паттерны сматчены.

                                                          Или я чего-то не понимаю?
                                                            0
                                                            Уберите из Maybe метод Value и вы сможете получить доступ к содержимому только через безопасные методы вроде Map.

                                                            Метод Value — единственный опасный, но им пользоваться не надо.
                                                              0
                                                              И кто гарантирует, что есть все нужные мне методы?

                                                              Вот у меня есть метод (в интерфейсе, а значит, c неизменняемой сигнатурой) string -> string. С оговоркой, что если на входе null, то возвращаем null.

                                                              Как с помощью вашей реализации мне гарантировать такое поведение?
                                                                0
                                                                String -> String
                                                                это одно

                                                                а если с оговоркой то:
                                                                String -> Maybe String
                                                                или
                                                                Maybe String -> Maybe String
                                                                  0
                                                                  Нет-нет, именно string -> string. В терминах C#. Интерфейс именно такой, и именно фиксированный. Внутри можно заворачивать что угодно во что угодно, но внешний интерфейс менять нельзя.
                                                                    0
                                                                    Тут я не советчик.
                                                                    Кроме haskell и erlang языков не знаю.
                                                                      0
                                                                      Вот беда в том, что пост-то на C# (и про C#-реализацию), а половина комментаторов рассуждает в терминах чистых функциональных языков.
                                                                        0
                                                                        Erlang далеко не чистый функциональный язык,

                                                                        А для C# наверно речь идет про Nullable Type, как намекает msdn.
                                                                          0
                                                                          Неправильно намекает. Nullable of T — это другое.
                                                                        0
                                                                        Хотя при строгой типизации, сигнатура функции с оговорками мне вообще не понятна.

                                                                          0
                                                                          А зря, потому что контракт функции всегда сложнее, чем можно выразить в системе типов. Это порождает контракты и аннотации контрактов.
                                                                            0
                                                                            QuickCheck для haskell, но там не может быть типа с оговорками.
                                                                            У erlang сложнее.

                                                                            При этом haskell
                                                                            позволяет спрототипировать приложение не написав ни одной реализации функции.

                                                                            Классическая разработка от полного к частному.
                                                                            Примеры можете посмотреть в ссылке выше.
                                                                              0
                                                                              Какой ссылке?
                                                                                0
                                                                                тут
                                                                                Игра 15

                                                                                  0
                                                                                  Это называется «не написав ни одной реализации»?
                                                                                    0
                                                                                    Вначале описали типы данных.
                                                                                    потом написали названия функций и их типы (из каких типов какие получаем)
                                                                                    реализация функций undefined
                                                                                    когда по типам программа корректна, только тогда начали реализацию логики.

                                                                                    По сути, прототип корректной программы не содержал ни одной реализации логики.

                                                                                    Или что то не так?
                                                                                      0
                                                                                      Прототип — это когда что-то работает (не путать с дизайном).

                                                                                      (мы тут не рассматриваем UI-прототипирование, о нем речь не идет)
                                                                                        0
                                                                                        Пусть будет дизайн.
                                                                                        Только в примере мы получаем дизайн программы, и знаем что она будет работать.
                                                                                        Единственное что нам нужно, дописать реализацию функций с известной сигнатурой.

                                                                                        Ради интереса нарыл реализацию на java
                                                                                        подобие
                                                                                        На мой взгляд логику работы понять весьма проблематично.
                                                                                        Хотя каждому свое.
                                                                                          0
                                                                                          Только в примере мы получаем дизайн программы, и знаем что она будет работать.

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

                                                                                            И кстати всегда есть выбор:
                                                                                            Prelude> take 0 undefined [] Prelude> take 0 $! undefined *** Exception: Prelude.undefined
                                                                                            первый вариант — lazy
                                                                                            второй — strict
                                                                                              0
                                                                                              Сорри парсер.
                                                                                              Prelude> take 0 undefined [] 
                                                                                              Prelude> take 0 $! undefined 
                                                                                              *** Exception: Prelude.undefined 
                                                                                              

                                                                                              первый вариант — lazy
                                                                                              второй — strict
                                                                                                0
                                                                                                Если программа проходит согласование по типам, она работоспособна при правильной реализации.

                                                                                                «Работоспособна» — это «компилируется и выполняется, не выдавая ошибок»? Это уже давно никого не интересует. Я считаю работоспособной ту программу, которая корректно реализует бизнес-требования. А тут, если мы говорим о хоть сколько-нибудь сложной программе, то есть ровно два варианта подобной ситуации.

                                                                                                (а) вы уже зашили всю бизнес-логику в типы. Это значит, что программа работоспособна если вы правильно спроектировали типы
                                                                                                (б) типы не отражают все варианты бизнес-логики, и что-то остается на усмотрение реализатора. Это значит, что программа работоспособна только тогда, когда реализатор все реализовал правильно.

                                                                                                Примеры нужны? (признаюсь честно, пример первого мне написать слабо)
                                                                                                  0
                                                                                                  Легко добиться того, чтобы программа компилировалась.
                                                                                                  Сложнее добиться чтобы она без ошибок выполнялась.

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

                                                                                                  Корректно спроектировать типы проще ибо это декларативное описание. И компилятор тут проверяет корректность в определенной стапени.

                                                                                                  Полностью зашить бизнеслогику в типы невозможно, но при различных подходах и инструментах к этому можно приблизиться в различной степени.
                                                                                                  В хаскеле и других ФП языках это проще.
                                                                                                    0
                                                                                                    Ну касательно (a)
                                                                                                    Если типы не корректно спроектированы
                                                                                                    компилятор не пропустит.
                                                                                                    Если корректно, но есть ошибки в логике, ну чудес не бывает, голова нам дана не орехи колоть.
                                                                                                    насчет (b)
                                                                                                    От логических ошибок страховки не бывает.
                                                                                                    Если нужно делить на 5 а поделили на 4 это косяк программиста а не инструмента.
                                                                                                    А если компилятор пропустил деление на ноль, и об этом узнали после релиза,
                                                                                                    я склонен считать что с инструментом есть некие проблемы.
                                                                                                      0
                                                                                                      Вообще серебряной пули не бывает.
                                                                                                      Каждый использует наиболее удобный для себя инструмент.
                                                                                                      Кому то удобно плодить if else
                                                                                                      кому то использовать Maybe.

                                                                                                      Кто то не может осилить haskell, кто то java.
                                                                                                      Дело не в инструменте, дело в головах и руках.
                                                                                                        0
                                                                                                        А если компилятор пропустил деление на ноль, и об этом узнали после релиза, я склонен считать что с инструментом есть некие проблемы.

                                                                                                        Видимо, слово «тестирование» успешно забыто.

                                                                                                        Не говоря уже о том, что я что-то не знаю компиляторов (разве что Eiffel), которые защищают от ошибок деления на ноль в случае деления на внешний аргумент.
                                                                          0
                                                                          Это должно быть на уровне идеологии.
                                                                          То есть если метод возвращает string, то этот string не null. Иначе он должен возвращать Maybe.

                                                                          В хаскеле это поддерживается полноценно (там вообще нет null).
                                                                          В scala все почти везде поддерживается. Проблемы только в Java-библиотеках, но над ними пишут обертки либо просто оборачивают специальной функцией каждый получаемый результат.
                                                                          В котлине пошли еще дальше и там все, что пришло из java автоматически обернуто если нет атрибута NotNull.
                                                                            0
                                                                            Ну то есть никак.

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

                                                                              В частности, к монадам относятся:
                                                                              IO (монада строго последовательных вычислений): стратегия связывания — «сначала первое вычисление, затем второе»;

                                                                              По сути:
                                                                              любой код на любом языке програмирования как минимум использует монаду IO (в терминах haskell)

                                                                              Смеяться можно всем миром.
                                                                                0
                                                                                Мне это напоминает «everything is an object».

                                                                                Ну да, если у вас есть молоток…
                                                                                  0
                                                                                  ) Ну да.
                                                                                  только роль объекта играет лямбда.
                                                                                  Через нее реализуются все остальные кирпичики программ в функциональной парадигме.

                                                                        0
                                                                        А если вы хотите использовать сопоставление с образцом (которого в C# нет), то там, где оно есть, обычно есть и проверка на то, что все возможности учтены.
                                                              –2
                                                              Для тех кто не знаком с C#, ключевое слово this позволяет использовать функцию через точку после объекта

                                                              Дальше даже читать не стал. Это настолько неграмотно с точки зрения C#, что слов нет.

                                                              Ну и да, при наличии работающего <a href=«nuget.org/packages/Monads>Monads это все ни о чем.

                                                              Maybe discount = f.Curry().Pure().Apply(userId).Apply(productId);
                                                              Извините, но ничего декларативного в этом коде нет. Он вообще не показывает бизнес-намерение кода.
                                                                +2
                                                                Для любителей практики, абстрактный вебсервис

                                                                Без Maybe:

                                                                получаем запрос -> проверяем корректность, если некорректно выход

                                                                если корректно -> смотрим урл -> если нет обработчика выход

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

                                                                если с правами все ок -> смотрим в базе что требуется -> если результата нет, выход

                                                                если результат есть -> рисуем и отправляем ответ

                                                                Без Maybe куча if then else

                                                                C Maybe:
                                                                получить запрос >>= 
                                                                        проверить корректность >>= 
                                                                        проверить url >>= 
                                                                        проверить пользователя >>= 
                                                                        выбрать результат из базы >>= 
                                                                        нарисовать и отправить ответ
                                                                
                                                                


                                                                если на каком нибудь этапе, обработка провалится, результат будет Nothing или кому более привычный null
                                                                  +2
                                                                  если на каком нибудь этапе, обработка провалится, результат будет Nothing или кому более привычный null

                                                                  А должен быть exception (в абстрактном вебсервисе). Потому что fail early.
                                                                    0
                                                                    Exception в многопоточном коде не всегда удобен.
                                                                    Здесь тоже выполнение прерывается на первой же неудачной операции, но менее многословно и позволяет вместо броска исключения вернуть результат неудачной проверки, например.
                                                                      0
                                                                      Exception в многопоточном коде не всегда удобен.

                                                                      Абстрактный веб-сервис однопоточен (точнее, каждый его вызов).

                                                                      позволяет вместо броска исключения вернуть результат неудачной проверки, например

                                                                      А зачем это делать тем же способом, которым возвращается результат удачного выполнения? Честное слово, исключения придумали не просто так.
                                                                        0
                                                                        Зучем придумали исключения — отдельный вопрос. Но логику работы программы они ломают. И на исклбючениях строить бизнеслогику — зло.

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

                                                                          Каким образом?

                                                                          И на исклбючениях строить бизнеслогику — зло.

                                                                          Это не бизнес-логика. Бизнес-логика в вашем примере в двух последних шагах (найти данные и вернуть результат). Все, что до этого — не бизнес.

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

                                                                          Особенно на клиенте, который теперь вынужден проверять, что именно ему вернули — нормальный результат или ошибку (тем самым внося очередные условия/монады).
                                                                            0
                                                                            Если у вас действительно ошибка, которую можно только залогировать. то исключения — ваш метод. Если же это надо обработать как часть бизнеслогики, то исключения — зло.
                                                                              0
                                                                              Вот о том и речь, что в приведенном примере это не бизнес-логика.

                                                                              Против самой монады Maybe я ничего не имею, я и сам ее радостно использую.
                                                                      0
                                                                      Nothing это и есть exception для чистых вычислений (для данного примера).

                                                                      В реальном коде там еще будет State монада, чтоб получить правильный код ответа сервера (404, 503 и тд)
                                                                      Но при этом нарисованный код останется таким же.
                                                                        0
                                                                        Nothing это и есть exception для чистых вычислений (для данного примера).

                                                                        А как отличать «не вернули результат» от «ошибка»?

                                                                        (если что, null — это именно «нет результата»)
                                                                          0
                                                                          Храним состояние в State монаде, и ответ берем оттуда.
                                                                            +1
                                                                            А зачем изобретать велосипеды? Особенно в веб-сервисах, где давно все придумано?
                                                                              0
                                                                              Это не велосипеды, это функциональная парадигма.
                                                                              И веб на ней также окучивается как на императивных языках, и зачастую сильно проще.

                                                                              И справка из википедии:
                                                                              Lisp — 1958
                                                                              Erlang — 1986
                                                                              ML — 1979
                                                                              Haskell — в конце 80
                                                                            0
                                                                            Если нет желания использовать State и Maybe,
                                                                            можно взять Data.Either
                                                                            data Either a b = Left a | Right b
                                                                            

                                                                            Это тоже монада и вычисления связываются точно также.
                                                                            Только если будет ошибка она у вас будет Left «что случилось»
                                                                            если все ок, то Right ответ сервера

                                                                              0
                                                                              То есть пример становится уже другим.
                                                                                0
                                                                                Кстати нет.
                                                                                Типы данных используются другие.
                                                                                И внутренняя реализация.
                                                                                А пример остается валидным.
                                                                                  0
                                                                                  У меня просто есть устойчивое ощущение, что для этой монады придется писать другие реализации в пайплайне.
                                                                                    0
                                                                                    Как раз нет.
                                                                                    С непривычки это может запутать еще сильнее, но обычно стараются писать функции, работающие с монадами так, чтобы работа с различными монадами была как можно более однородна.
                                                                          0
                                                                          я подозреваю, что none, в каком бы месте он не случился, пролетит оставшуюся часть пайплайна крайне быстро, так что вряд ли это как-то скажется.
                                                                            0
                                                                            Только вот вызывающий код не поймет, что произошло.
                                                                              0
                                                                              это да, но думаю, для этого уже тоже придумали какую-нибудь монаду))
                                                                                +1
                                                                                А нафига? Чем Exception-то не угодил?
                                                                                  0
                                                                                  Мне кажется, это вопрос отношения к exception. Если рассматривать его возникновение как нормальный flow для программы, то все в порядке, но многие, в том числе и «классики», считают, что exception как следует из названия, ситуация исключительная, и исключения не должны применяться в целях обеспечения обычной работы приложения. Не могу сказать, что один из подходов однозначно лучше, но мне больше по душе второй.
                                                                                    0
                                                                                    Понятие «исключительно» и «нормально» — относительны. И я склонен считать, что для абстрактного вебсервиса, отдающего данные, ошибка авторизации пользователя — исключительная ситуация (как бы часто она не проиходила).
                                                                                0
                                                                                Как раз в случае с ФП без броска исключения мало того, что вызывающий код гарантировано поймет что произошло, так еще и компилятор позаботится чтоб вызывающий код не забыл обработать все возможные результаты, а не только валидный. Ну хотя бы просто переправиви невалидный выше.
                                                                                  0
                                                                                  Потребителем «абстрактного веб-сервиса» не обязательно является функциональная программа.
                                                                                    0
                                                                                    И этой абстрактной программе проще будет обработать Either или аналогичный ему тип, чем принять исключение.
                                                                                      0
                                                                                      Вы в курсе существования WS-Fault?
                                                                                        0
                                                                                        И потом первая залетевшая ворона разрушит цивилизацию. ))
                                                                              0
                                                                              Exception должен быть только в том случае, если мы используем исключения для обработки ожидаемых ошибок (неавторизованность пользователя — это ведь ожидаемая ошибка?). Учитывая, что никто из популярных языков программирования / фреймворков так не делает — в общем случае, на практике, нам будет очень тяжко — придется каждый метод проверять — а действительно ли он в случае ожидаемой ошибки кинет исключение нужного типа? Не получится ли, что мы там вместо «not authorized» словим «out of memory» и продолжим работу, вместо того чтобы упасть?
                                                                                0
                                                                                если мы используем исключения для обработки ожидаемых ошибок (неавторизованность пользователя — это ведь ожидаемая ошибка?)

                                                                                Внутри метода «получи данные»? Нет, не ожидаемая. Мы предполагаем, что пользователь пришел с правильным контекстом.

                                                                                а действительно ли он в случае ожидаемой ошибки кинет исключение нужного типа?

                                                                                А альтернатива какая? Получать null и пытаться угадать, там нет данных, или у нас не авторизовался пользователь?
                                                                                  0
                                                                                  Внутри метода «получи данные»? Нет, не ожидаемая. Мы предполагаем, что пользователь пришел с правильным контекстом.


                                                                                  В таком случае нам не нужно в конце получать null и продолжать работу — нам нужно падать с логом в тот момент, как оказалось что пользователь пришел с неправильным контекстом. Если мы ожидаем что контекст правильный, а контекст неправильный — значит у нас бага в логике программы и дальше мы работать не хотим, надо ползти к разработчику и ремонтироваться? Ну или перезапускаться :).

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


                                                                                  Альтернатива чему?
                                                                                    +1
                                                                                    В таком случае нам не нужно в конце получать null и продолжать работу — нам нужно падать с логом в тот момент, как оказалось что пользователь пришел с неправильным контекстом.

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

                                                                                    Альтернатива чему?

                                                                                    Тройке «результат — null если данных нет (ожидаемая ситуация) — exception если нарушен контракт (неверная авторизация, нет обработчика, что-то еще)».
                                                                                      0
                                                                                      Да, вообщем-то, нет никакой альтернативы ^_^. Все так делают последние лет… много. И вроде как все работает. У меня, по крайней мере :).
                                                                              0
                                                                              Или в точечной нотации:

                                                                              вебсервис = нарисовать и отправить ответ . выбрать результат из базы . проверить пользователя . проверить url . проверить корректность
                                                                              
                                                                                0
                                                                                И вы считаете, что это читаемый код? И давно у нас текст читается с конца?
                                                                                  0
                                                                                  Кому-то привычно.
                                                                                  Если вам непривычно читать с конца, то вам будет удобнее пользоваться другими ФП языками, например scala. Суть подхода от этого не меняется.
                                                                                    0
                                                                                    Это математическая нотация.
                                                                                    Не нравится можете использовать другой синтаксис.
                                                                                    В некоторых случаях такая запись очень удобна.
                                                                                      0
                                                                                      Возможно, но, имхо, когда речь идет именно о последовательности действий (как в вашем примере), то читать/писать логичнее слева направо, как собственно и будет записываться этот код. Сомневаюсь что лишняя инверсия-другая в голове дает какой-то профит.
                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                          0
                                                                                          С точки зрения задачи (алгоритма) это именно последовательность.
                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                +1
                                                                                null в C# был добавлен в спешке. Я видел интервью где главный по C# говорит что вместо null надо было бы сделать чтобы Nullable<> работал и для reference-типов. И чтобы по-умолчанию все reference-типы были бы не-Nullable. Имели бы кучу плюшек от этого. И тогда LINQ можно было бы реализовать для Nullable, получив аналог монады Maybe с нормальным синтаксисом.

                                                                                Эх… Если бы, да кабы…
                                                                                  0
                                                                                  null вообще был «добавлен в спешке». billion-dollar mistake

                                                                                  А C# с первой версии развился очень сильно и изначально там не было ни намека на LINQ. Там и лямбд-то не было. Там даже генериков не было изначально — откуда там взяться Nullable<>.

                                                                                  Разработчики языка проделали с первой версии огромную и весьма хорошую работу. Но отказ от null уже не возможен, к сожалению.
                                                                                    0
                                                                                    Для Nullable<> нужны были только дженерики. Без остального прожить было можно, а новые фичи потом удачно бы дополнили работу с Nullable<>. Но дженерики они не успевали. Как по мне — не стоило релизить первую версию C# вообще, слишком уж многое от этого печально в C#.

                                                                                    Да, теперь уже не поправить.

                                                                                    Я вообще это все к тому, что Maybe монада — неудачный пример в контексте .net-а, ее просто не сделать нормально поверх этого зоопарка.
                                                                                  0
                                                                                  Отличная статья, впервые на русском читаю так грамотно изложенное понимание того зачем все эти Монады, Стрелки и тп нужны. Браво автору!

                                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                  Самое читаемое