Почему я бы решил не использовать функцию редукторов clojure 1.5?

Я читал о редукторах clojure, введенных в 1.5, здесь: https://github.com/clojure/clojure/blob/master/changes.md. Я понимаю, что они улучшают производительность существующих функций/фильтров/сокращений. Поэтому, если это так, мне интересно, почему они находятся в новом пространстве имен и не просто заменяют существующие реализации map/reduce/filter. Иными словами, почему бы мне не выбрать новую функцию редукторов?

ИЗМЕНИТЬ:

В ответ на два первых ответа, вот пояснение:

Я приведу здесь примечания к выпуску:

Редукторы обеспечивают набор высокопроизводительных функций для работы с коллекциями. Фактические алгоритмы fold/reduce задаются с уменьшением коллекции. Это позволяет каждой коллекции определять наиболее эффективный способ уменьшить ее содержимое.

Это не звучит для меня, как новые функции map/filter/reduce, по сути, параллельны. Например, ниже в примечаниях к выпуску указано:

Он содержит новую функцию fold, которая представляет собой параллельное сокращение + объединение

Поэтому, если заметка о выпуске плохо написана, мне кажется, что есть одна новая функция, сворачиваемая, которая параллельна, а другие функции представляют собой специфические для коллекции реализации, которые нацелены на получение максимальной производительности, возможной для конкретной коллекции, Я просто неправильно читаю заметки о выпуске здесь?

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Вам необходимо поддерживать обратную совместимость с Clojure 1.4. Это затрудняет использование редукторов в библиотечном коде, например, где вы не знаете, какая версия Clojure использует ваши приложения
В некоторых случаях есть лучшие опции: например, если вы имеете дело с численными массивами, то вам почти наверняка будет лучше использовать что-то вроде core.matrix.

Ответ 4

Я нашел следующую статью Rich Hickey, которая, хотя все еще несколько запутывает, очищает (некоторые) вещи для меня: http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html

В частности, сводка:

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