Scala для эффективности понимания?

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

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

Что касается окончательного рассмотрения, скрывает ли это сложность или нет, я утверждаю следующее:

for {
  b1 <- books
  b2 <- books
  if b1 != b2
  a1 <- b1.authors
  a2 <- b2.authors 
  if a1 == a2
} yield a1

Очень легко увидеть, что делается, и очевидна сложность: b ^ 2 * a ^ 2 (фильтр не изменит сложность), для количества книг и количества авторов. Теперь напишите тот же код на Java, либо с глубокими отступами, либо с частными методами, и попытайтесь быстро выяснить, какова сложность кода.

Так что, имхо, это не скрывает сложности, а, наоборот, дает понять.

Что касается упомянутых вами определений _2 _ / _ 3 _ / _ 4_, они не принадлежат к List или какому-либо другому классу, поэтому они не будут применяться. В основном,

for(x <- List(1, 2, 3)) yield x * 2

переводится на

List(1, 2, 3) map (x => x * 2)

и это не то же самое, что

map(List(1, 2, 3), ((x: Int) => x * 2)))

так будет называться принятое вами определение. Для справки, фактическая реализация map на List:

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That = {
  val b = bf(repr)
  b.sizeHint(this) 
  for (x <- this) b += f(x)
  b.result
}

Я пишу код, чтобы его было легко понять и поддерживать. Я тогда профиль. Если есть узкое место, я обращаю на это свое внимание. Если дело в чем-то похожем на то, что вы описали, я решу проблему другим способом. А пока я люблю "сахар". Это избавляет меня от необходимости что-то записывать или много думать об этом.

Фактически получается 6 петель. Один цикл для каждого фильтра / flatMap / map

Пары фильтр-> карта могут быть выполнены в одном цикле с использованием ленивых представлений коллекций (метод итератора)

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

Используя простые структуры данных, вы сделаете то же самое при явном кодировании.

И, конечно же, приведенный здесь пример предназначен для демонстрации сложного цикла for, а не для написания наиболее эффективного кода. Например, вместо последовательности авторов можно использовать Set, а затем определить, не является ли пересечение пустым:

for (b1 <- books; b2 <- books; a <- (b1.authors & b2.authors)) yield a

Обратите внимание, что в 2.8 вызов filter был изменен на withFilter, что является ленивым и позволяет избежать создания промежуточной структуры. См. руководство по переходу от фильтра к withFilter?.

Я считаю, что причина того, что for переводится в map, flatMap и withFilter (а также определения значений, если они есть), заключается в том, чтобы упростить использование монад.

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

Одно продолжение ответа @ IttayD об эффективности алгоритма. Стоит отметить, что алгоритм в исходной публикации (и в книге) представляет собой соединение с вложенным циклом. На практике это неэффективный алгоритм для больших наборов данных, и в большинстве баз данных вместо этого будет использоваться агрегат хеширования. В Scala агрегат хеша будет выглядеть примерно так:

(for (book <- books;
      author <- book.authors) yield (book, author)
).groupBy(_._2).filter(_._2.size > 1).keys