Тут всё правильно уже сказали, но добавлю.


Начал читать информацию о Scala и ФП, и так понял, что для ввода-вывода в ФП используются монады. Ввод-вывод влечет побочные эффекты, что недопустимо с точки зрения чистого ФП и монады играют роль моста между императивным и функциональным программированием. Так ли это?


Так. В смысле -- функциональные программисты действительно так считают. И иногда это дейтвительно оправдано.



Тут у меня возник сам вопрос - в каждом подходе есть свои + и -, есть языки, которые поддерживают оба стиля, поэтому можно ли сделать такой вывод - если язык поддерживает оба подхода, делай подзадачи проекта на том инструменте, который лучше всего подходит - типа работа с персистентными структурами данных, места где можно много ИП-style кода заменить на лаконичный ФП-style код лучше идет на функциональной парадигме, а ввод/вывод с файлов, с базы - лучше тупо использовать в той же Scala java.io.* и не париться с монадами. Верен ли такой вывод?



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

Scala, на сколько я знаю, не умеет сама распараллеливаться, поскольку её VM -- это стандартная VM от Java. Поэтому в Scala FP -- это только для удобства программирования на ней, что ОЧЕНЬ важно, но чистота для этого не нужна абсолютно.

kolchanov>Дело-то всё в том, что при отсутствии побочных эффектов программу можно в любом месте распараллелить. Это -- самое главное, для чего нужна чистота от побочных эффектов. Ну и соответственно, если тебе не нужно мгновенное автоматическое распараллеливание, то не нужна и чистота.

Не могу согласиться, что только для параллельности, для меня важна безопасность использования.
Функцию без побочного эффекта можно покрыть тестовым окружением, соответственно тестировать только ее и потом безопасно заменить на любую другую раеализацию, которая совпадает по сигнатуре и проходит тесты.

Функцию с побочным эффектом невозможно тестировать и рассматривать как черный ящик.
Все изменения надо проверять в контексте того, кто ее использует.

не прав.
нормальные функции можно тестировать.
если функция шизонутая, если не сказать больше, то да, но нафига такая вообще нужна?

ну и как бы 90 процентов всех программ не функциональные и не чистые, но тем не менее из тестируют, и они в большинстве работают.