Я думаю, что в этом вопросе наверняка есть сплошная точка. Он освещен тем, как любая библиотека может обрабатывать исключений .
Если вы взаимодействуете с библиотекой Java, любой метод может вызвать исключение. Это может быть либо явно, через проверено исключение - или прозрачно (с точки зрения API), через время выполнения исключение. Что вы должны делать с этим, как программист, который может пытаться использовать более функциональный тип Either для обозначения сбоя (или scalaz 'Validation)?
Мне не совсем понятно, как это будет развиваться в скале (то есть, подход к проблеме и выбор чисто функционального подхода). Конечно, он может производить много разных стилей кодирования. Тем не менее, есть много богатого и полезного в функциональной части скалы, из которого вы можете выбрать; и, безусловно, возможно, чтобы это сочетание функционального и императивного кода в вашей программе работало вместе. Хотя функционал пурист может, конечно, не согласиться с тем, является ли это оптимальной ситуацией.
Несмотря на это, я обнаружил, что применение функциональных парадигм в моих программах улучшило мой код до бесконечности. Поскольку я не пробовал Haskell или F # , я не мог сказать вам, будет ли чистый результат лучше или хуже.
Но он вытирает пол Явой; и получить это на JVM (с практическим преимуществом сосуществования со всеми нашими библиотеками Java), с моей точки зрения, является убийственным приложением.
<Ч />
По краям, когда вы начнете больше использовать функциональную сторону scala, вы столкнетесь с рядом проблем. Это наиболее очевидно:
- отсутствие неявной функции карри (т.е. эквивалентность
A => B => C и (A, B) => C)
- отсутствие неявной функции tupling (т. Е. Эквивалентность между n-арной функцией и 1-арной функцией, которая принимает n-кортеж в качестве параметра)
- отсутствие вывода для частично примененных конструкторов типов (т.е. эквивалентность
M[A] с, например, Either[Int, A])
Обе эти проблемы делают функциональный код красивым и понятным, уродливым и неясным.