AT
то есть принципиально то же самое, только хуже?
Size: a a a
2020 February 26
TS
ну вот да, кажется, что старая форма оне вполне вписывается в это современное безумие. "Оне делали"
PZ
Ну maybe не слишком удобная замена именно исключеням, в maybe информацию об ошибке не передашь. Все же тема с исключениями более широкая. Мое мнение - исключения нельзя использовать для failure path в бизнес-логике. Можно только для экстренных ситуаций.
Ну, maybe - это просто
А Either это перехват конкретных исключений. Пока что не вижу разницы
try
...
catch (...)
....
А Either это перехват конкретных исключений. Пока что не вижу разницы
АГ
Исключения - механизм языка. Монадические цепочки - это значения, ты можешь их переиспользовать, соединять с другими, применять генеричные монадические функции. Там их много, и они очень полезны, упрощают код. В итоге ты не просто пишешь логику, ты делаешь ее декларативной и более переиспользуемой
FF
кстати, а как мы переводим на русский "they/them"?
(это я к вопросу "Sy Brand сделал")
(это я к вопросу "Sy Brand сделал")
он_а, если тебе действительно интересен ответ на этот вопрос. :)
AP
Исключения скорее заменяются на expected (Either), там можно передавать информацию об ошибке
expected тоже представим в виде монады, и к нему неплохо прикручивается монадический интерфейс:
int i = try bar();
return i + try foo();АГ
expected тоже представим в виде монады, и к нему неплохо прикручивается монадический интерфейс:
int i = try bar();
return i + try foo();Такой пропозал как раз и есть. Детали, правда, там уже не помню какие
AV
Исключения - механизм языка. Монадические цепочки - это значения, ты можешь их переиспользовать, соединять с другими, применять генеричные монадические функции. Там их много, и они очень полезны, упрощают код. В итоге ты не просто пишешь логику, ты делаешь ее декларативной и более переиспользуемой
Динамическое конструирование и комбинирование транзакций?
АГ
Динамическое конструирование и комбинирование транзакций?
?
АГ
Монадические цепочки, конечно, можно создавать динамически
AV
По сути блок стейтментов в try - это транзакция
AV
Монады позволяют то же, плюс можно ими манипулировать
AV
А если ещё и вычисления ленивые...
АГ
Это мы еще не говорили про монадные трансформеры ;)
AV
Но как потом выяснить, где оно сломалось?
АГ
Но как потом выяснить, где оно сломалось?
Для Maybe/optional - никак, ты просто знаешь, что цепочка зафейлилась. А для Either/expected - ты возвращаешь специфическую ошибку, по которой и видно, какая функция в середине цепочки зафейлилась
AV
Заучит это все круто, но хотелось бы реальных примеров хоть в псевдокоде.
Допустим пишем мы игру -стрелялочку. Скажем wolf3d старообрядный.
Где это пригодится? И будет ли это проще, гибче и быстрее нежели старая добрая императивщина?
Допустим пишем мы игру -стрелялочку. Скажем wolf3d старообрядный.
Где это пригодится? И будет ли это проще, гибче и быстрее нежели старая добрая императивщина?
АГ
ФП для реал-тайм игрушек не очень использовать. Если бы ты про пошаговые спросил, там в принципе можно придумать хорошие примеры. Скажем, в шахматах можно цепочки ходов завернуть в монаду Maybe или Either. Сделал ход, оценил ситуацию. Норм? Делай следующий ход. Не норм? Возвращай ошибку.
PZ
Исключения - механизм языка. Монадические цепочки - это значения, ты можешь их переиспользовать, соединять с другими, применять генеричные монадические функции. Там их много, и они очень полезны, упрощают код. В итоге ты не просто пишешь логику, ты делаешь ее декларативной и более переиспользуемой
Но зачем? Есть где-нибудь статья/учебник, где вот берут императивный пример, переписывают монадически и получают ништяки
AV
ФП для реал-тайм игрушек не очень использовать. Если бы ты про пошаговые спросил, там в принципе можно придумать хорошие примеры. Скажем, в шахматах можно цепочки ходов завернуть в монаду Maybe или Either. Сделал ход, оценил ситуацию. Норм? Делай следующий ход. Не норм? Возвращай ошибку.
Даже на плюсах?