Здравствуйте, Poopy Joe, Вы писали:
PJ>И что? Это этого количество путей не становится экспотенциальным.
Путей — нет. Типов — да.
PJ>Каждый тип выражает некую бизнес-сущеность. Ее можно выразить через типы, можно спагетти-кодом, можно классами но как-то это сделать придеться.
Ну, хорошо, если бизнес-сущность. А если состояние бизнес сущности — то типов, на первый взгляд, может оказаться слишком много.
И без помощи компилятора (например, проверяющего полноту паттерн-матчинга) мы под их объёмом упадём.
S>>Да, не зависит. Но мне непонятно, как вы собираетесь получать из ShippableOrder при помощи одной операции два разных типа — UnpaidShippedOrder и PaidShippedOrder.
PJ>Никак это один тип: UnpaidShippedOrder | PaidShippedOrder, или OneOf<UnpaidShippedOrder, PaidShippedOrder>
Хм. Ну вы всего лишь передвинули проверку реального типа дальше по цепочке. Такой трюк выигрывает у if-else только в том случае, если компилятор отлавливает некорректности.
В C# нет поддержки OneOf, поэтому никакого улучшения по сравнению с if-else я не вижу.
PJ>Ну т.е. две функции и if-else. Я ровно это и сказал. 
S>> Причём, возможно, вообще не выраженного в коде приложения — была бы конфигурация предиката, которую может править администратор вообще без единого запуска компилятора. Кто ж может себе позволить ре-компиляцию и ре-деплоймент каждый раз, как надо изменить одно из правил 
PJ>Т.е. администратор может изменить правила и отправить себе бесплатно посылку, без постоплаты? Тогда мы о разном говорим.
Конечно может. В реальных системах администратор может очень много всего. Его контролирует не система типов (это всё равно невозможно), а административные практики.
Вот у меня лично есть доступ к продакшн-системам в нескольких регионах мира. Скажем, выписать себе подписку OneDrive на десяток терабайт со скидкой 100% я могу не сходя с этого места.
Но меня удерживает а) воспитание и б) понимание, что это рано или поздно вскроется (скорость зависит от объёма усилий, которые я потрачу на заметание следов), и меня накажут.
Причём мало того, что накажут деньгами — меня обязательно уволят, и шансы получить нормальную работу сразу упадут на порядок.
PJ>В случае администратора, который поменял правила не запуская компилятора, этот код может просто грохнуться. 
Что такое "просто грохнуться"?
PJ>Если у тебя поменяется любое из правил, тебе придется руками найти все места где это надо исправить, делать так каждый раз и компилятор тебе ничем не поможет.
Все — это какие? Код структурирован; изменение, скажем, региональных правил валидности адресов (типа перехода от 5 к 9-значному ZIP коду) делаются в одном месте.
S>>По моему опыту, sunny day path — это 7% кода. Как раз он и есть boilerplate. Всё остальное — это детальные политики того, что делать, когда всё пойдёт не так.
PJ>В примере выше у тебя как раз sunny day и есть, с крэшем во всех остальных случаях.
Крэш в данном случае — это откат транзакции. Детали обработки каждого из фейлов спрятаны внутрь соответствующих методов.
PJ>Именно поэтому поддерживать все это в виде "политик" ага спагетти кода — крайне трудоемко и с большим количеством вероятных ошибок. Типы позволяют не пропустить не один из сценариев, сделать правильную декомпозицию и сосредоточится именно на бизнес-процессе.
PJ>Все это делается гораздо проще и надежнее. Вот почитай https://fsharpforfunandprofit.com/rop/
Почитаю.
PJ>Хотя сам термин и как он используется в F# мне, лично, не нравится. Это просто паттерн и не обязательно про ошибки. Ну хоть так...
PJ>Единственное место где F# дает по рукам это неявное приведение типов. int и unit это разные типы. В остальном C# позволяет выражать все то же самое, но большим количеством кода.
PJ>Если сравнивать типичный C# код, с "правильным" F# кодом, то таки да. Руки отобьет.
То есть F# не проверяет полноту матчей композитных типов? Тогда я не вижу способа выиграть в выразительности у классического if-else кода за счёт системы типов.
S>>Не вполне понимаю всё же как именно выносить сайд-эффекты на "границы домена".
PJ>Как именно, это не про DDD, это просто паттерн IO/Actions.
Почитаем.
