Какова цель Scala языка программирования?

Ответ 1

Одна из вещей, упомянутых в беседах Мартина Одерского о Scala - это язык, который хорошо масштабируется для решения различных проблем. Он не говорил о масштабировании в смысле производительности, но в том смысле, что сам язык может казаться расширяться через библиотеки. Так что:

val lock = new ReentrantReadWriteLock
lock withReadLock {
   //do stuff
}

Похоже, есть специальный синтаксический сахар для работы с j.u.c locks. Но это не так, это просто использование языка Scala таким образом, каким оно кажется. Код более читабельен, не так ли?

В частности, различные правила синтаксического анализа языка Scala очень упрощают создание библиотек, которые выглядят как язык, специфичный для домена (или DSL). Посмотрите scala -test, например:

describe("MyCoolClass") { 
  it("should do cool stuff") {
     val c = new MyCoolClass
     c.prop should be ("cool")
  }
} 

(Есть много примеров этого - вчера я узнал этот). Существует много разговоров о том, какие новые функции появляются на Java-языке в JDK7 (проектная монета). Многие из этих функций являются специальным синтаксическим сахаром для решения некоторых конкретных проблем. Scala был разработан с некоторыми простыми правилами, которые означают, что для каждого небольшого раздражения не нужны новые ключевые слова.

Ответ 2

Другой целью Scala было преодоление разрыва между функциональными и объектно-ориентированными языками. Он содержит множество построенных конструкций (то есть скопированных из!) Функциональных языков. Я считаю невероятно мощным соответствие шаблону, основанный на актерах concurrency framework и (конечно) функции первого и более высокого порядка.

Конечно, в вашем вопросе говорилось, что существует определенная цель, и я только что дал 3 отдельных причины; вам, вероятно, придется спросить Мартина Одерского!

Ответ 3

Еще одна из исходных целей дизайна заключалась, конечно, в создании языка, который работает на виртуальной машине Java и полностью совместим с Java-классами. Это имеет (по крайней мере) два преимущества:

• вы можете использовать вездесущность, стабильность, возможности и репутацию JVM. (подумайте об управленческих расширениях, компиляции JIT, расширенной коллекции мусора и т.д.).
• вы все равно можете использовать все ваши любимые библиотеки Java, как сторонние, так и собственные. Если бы это было не так, это было бы существенным препятствием для использования Scala коммерчески во многих случаях (например, для моего).

Ответ 4

Согласитесь с предыдущими ответами, но рекомендуйте введение в Обзор Scala языка программирования:

Работа над Scala связана с исследовательскими усилиями по разработке лучшей языковой поддержки компонентного программного обеспечения. Есть две гипотезы, которые мы хотели бы подтвердить с экспериментом Scala. Во-первых, мы постулируем, что язык программирования для программного обеспечения компонентов должен быть масштабируемым в том смысле, что одни и те же концепции могут описывать как небольшие, так и большие части. Поэтому мы концентрируемся на механизмах абстракции, состава и декомпозиции, а не на добавлении большого набора примитивов, которые могут быть полезны для компонентов на определенном уровне, но не на других уровнях. Во-вторых, мы постулируем, что масштабируемая поддержка компонентов может быть обеспечена языком программирования, который унифицирует и обобщает объектно-ориентированное и функциональное программирование. Для статически типизированных языков, из которых Scala является экземпляром, эти две парадигмы до сих пор в значительной степени разделялись. (Одерски)

Я лично классифицировал Scala вместе с Python с точки зрения проблем, которые он решает и как. Заметная разница и случайная жалоба - сложность типа. Я согласен Scala абстракции сложны и время от времени кажутся свернутыми, но для нескольких точек:

• Они также в основном необязательны.
• Scala компилятор похож на бесплатное тестирование и документацию, поскольку циклическая сложность и линии кода возрастают.
• Когда корректно реализованный Scala может выполнять в противном случае все, кроме невозможных операций за последовательными и согласованными API. Из Scala 2.8 Коллекции:

Например, String (или, скорее, его поддерживающий класс RichString) можно рассматривать как последовательность Chars, но это не общий тип коллекции. Тем не менее, сопоставление символа с картой символов над RichString должно снова приводить RichString, как в следующем взаимодействии с Scala REPL:

scala> "abc" map (x => (x + 1).toChar)
res1: scala.runtime.RichString = bcd

Но что произойдет, если применить функцию от Char к Int до строки? В этом случае мы не можем создать строку в качестве результата, она должна быть некоторой последовательностью элементов Int вместо этого. Действительно получается:

"abc" map (x => (x + 1))
res2: scala.collection.immutable.Vector[Int] = Vector(98, 99, 100)

Итак, получается, что карта дает разные типы в зависимости от того, какой тип результата переданного аргумента функции! (Одерски)

Ответ 5

Поскольку он функционирует и использует актеров (как я понимаю, прокомментируйте, если у меня получилось это неправильно), он очень легко масштабируется почти до любого количества процессоров.

Тем не менее, я рассматриваю Scala как пробную кровать для новых языковых функций. Бросьте в кухонную раковину и посмотрите, что произойдет.

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

Чем больше людей добавляется, тем больше времени вы потратите на объяснение чего?: означает или разница между | и || применительно к двум логическим значениям (в Java вы найдете очень мало людей).