Pull to refresh

Comments 24

Я конечно сейчас получу кучу минусов, но вот это:

String campPeople = sport.stream().filter(p -> p.getName() != null).map(SportsCamp::getName).collect(Collectors.joining(" and ",«In camp »," rest all days."));

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

Если добавить немного форматирования, то всё становится не так уж плохо:
String campPeople = sport.stream()
                .filter(p -> p.getName() != null)
                .map(SportsCamp::getName)
                .collect(Collectors.joining(" and ",«In camp »," rest all days."));
да, это удачное форматирование при разработке.

Да и при написании/прочтении статьи тоже, если честно

Так по моему лучше
String campPeople = sport.stream()
.filter(Objects::nonNull)
.map(SportsCamp::getName)
.collect(Collectors.joining(" and ",«In camp »," rest all days."));
Каждая строка описывает одну манипуляцию над стримом, что более очевидно передает логику.
Чуть подправлю:

String campPeople = sport.stream()
.map(SportsCamp::getName)
.filter(Objects::nonNull)
.collect(Collectors.joining(" and ",«In camp »," rest all days."));
Да, конечно вы правы.
Ну, минусов-то тут не за что. Нормальный вопрос, на нормальную (хотя и далеко не новую тему).

Попробую дать свой ответ.

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

>Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
Вот это в сущности и есть цель. Чтобы можно было надежно разбивать и компоновать обратно, а части были максимально повторно используемыми.
Еще одна статья про Stream API, коих было уже предостаточно. Описано как-то очень сумбурно. Для людей, имеющих опыт работы со стримами — ничего нового, а для новичков — ничего не понятно.
Не могу принять Вашу точку зрения, т.к. она не подкреплена примерами.
Были комментарии выше, с которыми я полностью согласен, т.к. они аргументированы, но это не про Ваш комментарий.
Вы можете привести ссылки на огромное количество статей с работающими примерами за исключением уже имеющихся у меня в избранном?
В первых строках указано, что статья для пользователей начинающих знакомиться с данными возможностями, а не для профессионалов.
«Описано как-то очень сумбурно» — у всех свой стиль написания статей, замечу, что абсолютно все примеры рабочие и в точности показывают возможности функционала, а это немаловажно.
Я не даю четкого определения и точного размера коллекций

~10000 (из книги Р. Уорбертона «Лямбда-выражения в Java 8»)
У Вас будет точная формулировка этой цифры из книги? Возможно были дополнительные условия применения именно 10000?
Имеется в виду размер коллекции, при котором использование parallelStream действительно оправдано по производительности (поскольку, как известно, fork-join имеет некоторый оверхед на разделение/слияние потоков). Точную цитату могу поискать чуть позже. Ричард Уорбертон является одним из авторов-разработчиков данной технологии (и вообще Stream API), думаю, ему можно доверять. Книга небольшая, переведена на русский и есть в магазинах (и, к слову, в миллион раз полезнее, чем данная статья)
Понятно, что речь идет про коллекцию, и про fork/join обсуждали. Вы напишите формулировку из книги, т.к. я еще раз повторю, что коллекции бывают разные(обратите на это внимание). Книга действительно хорошая. Про полезность статьи судить не Вам(возможно, что многим примеры будут полезны).
Про полезность статьи судить не Вам(возможно, что многим примеры будут полезны).


Нам судить, читателям хабра. И, пожалуйста, воздержитесь от подобных формулировок, они сильно смахивают на хамство.
Данная фраза относилась к пользователю afanasiy_nikitin. Мне кажется, что я обоснованно рассказал в комментариях ниже свою точку зрения. Еще раз повторю, что если мы заявляем о фактах из книг, то мы должны в этом быть уверены. Я не поленился и перечитал(уже почти полностью) данную книгу и написал, что afanasiy_nikitin не прав и в чем, привел выдержки из книги.
Кстати, книгу всем советую, действительно отличная.

С аргументацией я согласен, мне не понравилась форма. Может сказывается привычка к сетевому этикету, принятому в англоязычных рассылках.

Не ищите цитату, т.к. вот она:
«При замере времени работы примеров 6.1 и 6.2 на 4-ядерной машине при 10 альбомах последовательная версия оказывается в 8 раз
быстрее. При 100 альбомах обе версии работают одинаково быстро,
а при 10 000 альбомов параллельная версия опережает последовательную в 2,5 раза.
Все результаты измерений в этой главе приводятся только для сведения. На вашей машине они могут оказаться совершенно другими.
Размер входного потока – не единственный фактор, определяющий, даст ли распараллеливание ускорение. Результаты могут также
зависеть от способа написания кода и количества доступных ядер.»
Автор книги Ричард Уорбэртон приводит нам пример про 10000(не говоря о том, что 10000 — это идеальное число для «отсечки») и обратите внимание, что скорости могут отличаться.

Речь идет о количестве порядков, я полагаю? Btw, я рад, что вы нашли книгу. Надеюсь, вы прочитаете ее целиком, и ваш код (и, может быть и эта статья) обогатится более точными и полезными примерами и комментариями. Спасибо за дискуссию.
1) Речь про значение в 10000 идет о альбомах (музыкальных треках).
2) Не могу понять Ваше желание сравнивать книги и статьи, приводя неправильные примеры, вводя в заблуждение читателей. Замечу. что автор книги(Ричард Уорбэртон), начиная со 107 страницы, подробно пишет о производительности при разных структурах и объемах данных. Вами сказанного значения в "~10000" у него нет.
3)Пожалуйста.
Еще раз специально перечитал несколько глав из книги Герберта Шилдта пытаясь найти упоминание о пороговых значениях, не нашел. Пытался смотреть другие источники, не нашел. Есть особенности при обработке в параллель. Первое — мы зависим от мощностей и «свободных» процессоров. Второе — коллекции представляют из себя различную структуру, поэтому необходимы точные формулировки из Вашего примера для понимания возможностей в точности разделения коллекций по определенному пороговому значению.

Про 10000 — феерический бред. Ваша работа — это N*Q, где N — количество элементов, а Q — среднее время обработки элемента. Если Q очень велико, то распараллеливать имеет смысл уже при N = 2. Если Q исключительно мало (например, сложение двух чисел), то параллелизм поможет только при больших N. Кроме того, многое зависит от самих операций в стриме. Если все операции stateless, вы можете получить хороший прирост. Если имеются stateful-операции, можно сильно замедлиться даже для очень большого N. Переменных очень много.

(p1,p2) -> p1.getDay().compareTo(p2.getDay())
Лучше писать Comparator.comparing(SportsCamp::getDay). Меньше вероятность ошибки.
Sign up to leave a comment.

Articles