2) Подходят ли функциональные языки для приложений типа Business / ERP / CRM?
Чтобы ответить на второй вопрос о бизнес-приложениях / приложениях ERP / CRM: лично я бы не стал реализовывать их на «чистом» функциональном языке, таком как Haskell, или на динамическом функциональном языке, таком как Clojure. С другой стороны, я в настоящее время внедряю ERP в Scala, которая, конечно, является гибридной OOP / FP и статически компилируется.
Причина, по которой я говорю это, заключается в том, что бизнес-приложение, такое как ERP, в основном ориентировано на записи: существует схема данных, выражающая различные типы записей, и логика приложения почти полностью разрабатывается вокруг CRUDing этих записей и применения пользовательских бизнес-процессов. им. И в сущности, я не верю, что такого рода бизнес-приложения, ориентированные на данные, идеально подходят для функциональной модели.
Люди могут говорить об OOP-реляционном несоответствии всем, что им нравится, но в конечном итоге и OOP, и базы данных ориентированы на записи: язык OOP с хорошим ORM позволяет вам отображать эти разные модели данных в коде, а затем присоединять код для обработки. каждая из моделей. И наличие этого статически типизированного (в идеале со строго типизированным ORM, такого как Squeryl Scala) значительно снижает вероятность ошибки во время выполнения или, например, изменение одной из моделей данных, которые не были правильно применены в коде.
Не поймите меня неправильно - я большой поклонник FP (я все больше и больше занимаюсь системным программированием на Haskell), но для меня ориентированный на записи подход ООП имеет больше смысла, чем функция -ориентированный подход FP для обработки объектов данных бизнес-ERP или аналогичных. (Scala - хорошее исключение из правила, потому что вы можете использовать парадигму ООП с качественными ORM для манипулирования записями, но также и совершенство FP для вашего общего программирования приложений.)