Каковы преимущества Лямбда-выражений для многоядерных систем?

Question

Java Tutorials для лямбда-выражений говорит следующее:

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

Вопрос: какие конкретные преимущества у меня есть с лямбда-выражениями в соответствии с многоядерными системами и параллельным/параллельным программированием?

Answer 1

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

collection.map { // my lambda } 

тогда сама коллекция может parallelise эту операцию без необходимости делать нарезание резьбы и т.д. самостоятельно. Параллелизм выполняется в рамках сборника map().

В чисто функциональной (то есть без побочных эффектов) системе вы можете сделать это для каждой лямбда. Для не чисто функциональной среды вам нужно будет выбрать лямбды, для которых это будет применяться (поскольку ваша лямбда не может работать безопасно параллельно). например в Scala у вас должно быть явно взять parallel view on a collection, чтобы реализовать вышеизложенное.

Answer 2

Некоторые справочные материалы:

• Вы можете прочитать ответ Мориса Нафталин в Why are lambda expressions being added to Java.
• Или вы можете прочитать ответ Марка Рейнхольда в своей статье Closures for Java.
• Рейнхольд также написал в своем блоге Closures Q&A, который, похоже, затрагивает некоторые ваши вопросы.
• И еще одна интересная статья в JavaWorld о Understanding the Closures Debate.

Answer 3

С полным уважением к Java лямбда-функции и намерениям o разработчикам я хотел бы спросить: что нового и почему это лучше, чем традиционный подход к функции интерфейса/метода? Почему это лучше, чем (допустим) forEach(IApply) где:

IApply является интерфейс

public interface IApply { 
    void exec(KEY key, VALUE value); 
} 

Как это мешает к параллельности? По крайней мере реализация IApply может быть повторно использована, унаследована (расширена), реализована в статическом классе.
Последний аргумент важен после десятков примеров ошибок юниоров, которые я видел, которые пропускают этот лямбда-код, обращаясь к этому из внешнего класса, может быть причиной того, что класс остается в памяти после того, как отдельная ссылка на него уже нулевая.
С этой точки зрения важны ссылки на статические члены класса (являются аналогами случая C# «делегат»). И главным образом - из одной руки - лямбда - это суперкапсуляция, из другой, которая не может многократно использоваться, и одновременно - нарушение основных принципов культуры OOD: свободный доступ к членам магистров. С точки зрения культуры программирования - обратный к 70-м годам прошлого века.
Функциональное программирование? - Вижу, но зачем смешивать явления ООП что Java.OOD имеет замечательный образец с разделителем Data-Behavior, который элегантно предоставляет те же возможности? Аргумент - это то же самое, что и в Java Script ... nu, действительно! Поэтому дайте инструменты для встраивания Java Script в Java и записи кусков системы в Java Script. Поэтому я до сих пор не вижу действительно настоящих преимуществ, так как есть волна рекламы.