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

Пример с GetDiscount не практический? Можно городить кучу ifов, а можно использовать абстракции. Да на C# выглядит страшно, так как он не совсем подходит под такой стиль.

Ценность монад и прочего — в том, что они обобщают кучу вещей: nullable, списки, парсеры, исключения, цепочки колбеков, всякие недетерминированные вычисления, и много-много еще чего.

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

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

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

Вот хороший пример того, как можно понимание монад совокупить с LINQ и получить годный, практичный результат: code.google.com/p/sprache/

Вопрос совершенно логичный и неоднократно поднимался.

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

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

С питоном тут сравнивать не стоит просто по тому, что в статье подразумевается статическая типизация и защита от NRE во время компиляции.

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

С динамическими тут вообще сложно сравнивать, так как там можно делать все что пожелаешь.
Но представьте если бы у вас DiscountService.GetDiscount на входе требовал что бы оба параметра были не None.
Заменил некорректное, на классическое.

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

Постараюсь воспроизвести для 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());
}

Да, подзабыл F#.

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

А вот знал бы я хаскель — саразу бы все понял. Наверное.

Нет.

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

Exception в многопоточном коде не всегда удобен.

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

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

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

Nothing это и есть exception для чистых вычислений (для данного примера).

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

(если что, null — это именно «нет результата»)

Только вот вызывающий код не поймет, что произошло.

если мы используем исключения для обработки ожидаемых ошибок (неавторизованность пользователя — это ведь ожидаемая ошибка?)

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

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

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

Кому-то привычно.
Если вам непривычно читать с конца, то вам будет удобнее пользоваться другими ФП языками, например scala. Суть подхода от этого не меняется.

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