Эффективность использования только функциональной парадигмы в Scala

Одна из вещей, которую вы видите, это то, что Scala — это, прежде всего, строго типизированный функциональный язык на JVM.

Scala — это не просто функциональный язык. Он начинался как один (Воронка: http://lamp.epfl.ch/funnel/ ), но затем он был расширен, чтобы сделать его объектно-ориентированным языком с явной целью сделать его строго совместимым с классами Java.

абстракция, переопределение и пакеты — все это примеры взаимодействия в действии.

Остальное можно рассматривать не как новые возможности, а просто как снятие ограничений с Java. Принимая их по одному:

черты и линеаризация иерархии объектов

Удаляет ограничение, согласно которому интерфейсы Java могут содержать только абстрактные методы. Линеаризация — это то, как Scala решает проблемы наследования алмазов, которые в противном случае могли бы возникнуть.

одиночки

Статические методы Java являются наследием синтаксиса C++, который, в свою очередь, добавил их для лучшей поддержки процедурного стиля, необходимого для взаимодействия с C. Статические методы в значительной степени НЕ объектно-ориентированы (см. этот вопрос: Почему одноэлементные объекты более объектно-ориентированы?)

сопутствующие объекты

Разрешить использование синглетонов вместо статических методов с их привилегированными правами доступа.

неявные конверсии

Java уже делает это, но ограничивается только неявным преобразованием объектов и примитивов в строки, как в выражении "" + 3. Scala просто расширяет эту идею и позволяет программисту использовать ее для других преобразований.

Позвольте мне добавить несколько комментариев к ответу Кевина.

Трейты в основном используются как абстракции (грубо говоря, так же, как классы типов Haskell определяют абстракции) и миксины. Итак, мой код может использовать трейт Map, но на самом деле он использует экземпляр типа HashMap. И наоборот, если я хочу, чтобы мой тип «Сервис» имел функциональность ведения журнала, я мог бы смешать многоразовую черту ведения журнала.

К счастью, вам редко приходится думать об алгоритме линеаризации, кроме простых случаев, например, я могу добавить трейт, который перехватывает (обертывает) вызов метода, чтобы регистрировать факт вызова метода. Алгоритм должен обрабатывать более сложные случаи линеаризации (например, примеры, которые мы показываем в книге), но на самом деле такие сложные типы — плохой дизайн, ИМХО.

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

Неявные преобразования очень полезны, хотя и немного «волшебные». Возможно, вам будет полезно посмотреть, как они используются для имитации классов типов Haskell. Вот отличный пост Дебасиша Гоша: http://debasishg.blogspot.com/2010/06/scala-implicits-type-classes-here-i.html

Хотя я начал программировать на scala, я определенно не более опытный член сообщества scala. Но я долго работал с другим языком - python, с которым аналогичная ситуация в меньшей степени. Он поддерживает процедурный, объектно-ориентированный и функциональный стили. Я обнаружил, что хотя некоторые люди склонны придерживаться одной крайности, многие комбинируют конструкции из разных стилей. Таким образом, идиоматический python будет состоять из интенсивного использования списков, функций первого класса, более высокого порядка и частичных функций, даже если данные, с которыми работают эти функции, являются объектами. Однако следует отметить, что с годами наблюдается тенденция к небольшому сдвигу в сторону функциональности.

Я думаю, учитывая инклюзивность стилей, которые поддерживает scala, вполне вероятно, что не будет единственно правильного способа решить проблему. Но я не удивлюсь, увидев, что большая часть программистов постепенно склоняется к стилю, который разумно использует и то, и другое, даже если они остаются терпимыми к программистам, желающим придерживаться одной из крайностей.