Comments 26
const curry = (fn, a = []) => (...args) =>
a.length + args.length >= fn.length
? fn(...a, ...args)
: curry(fn, [...a, ...args]);Согласитесь, но как по мне читабельность стремится к нулю. Сколько надо времени, чтоб сходу сказать что она делает и как? Особенно радует когда такое надо дебажить, да и еще если что-то где-то упало, и надо отдебажить и сделать хотфикс.
2) Добавьте JSDoc с пояснением зачем это нужно. Имя curry является стандартом де-факто и облегчает переход между языками программирования, но нарушает концепцию говорящих имен. Так, к примеру C# в свое время говнили за то, что map называется Select, filter называется Where, а reduce называется Aggregate.
3) Обратите внимание на то, что функция curry либо входит в стандартную библиотеку функциональных языков программирования, либо ненужен. Вы не должны видеть такого кода в проекте, потому что этот код должен быть объявлен в какой-то библиотеке.
4) Занимательный прикол: каррирование можно делать и без curry.
Как тут заметили — это обычно библиотечная функция. А так я реально нашел в инете реализацию. Код как по мне — не самый очевидный, но при некотором навыке нормально читается. Зависит от того, насколько разработчик "утоп" в функциональном дискурсе. Кстати с ООП та же песня — читать все эти фабрики фабрик фабрик легко с некоторым ооп бэкграундом.
Ну во-первых, тут всего одно условие в 3 строчки, все вполне читаемо. А во-вторых, такие функции, как правило, не пишутся прямо в проекте, а выносятся либо в библиотеку (а еще лучше — юзаются уже написанные вместо своих велосипедов), либо в отдельную часть, чтобы один раз написать и дальше просто использовать, не заботясь о внутренностях.
Как я отметил в конце статьи, это пойдет только если у вас проблемы с потреблением памяти. Это не серебряная пуля. Процессинг данных через map, filter, reduce — декларативный и понятный. Код с compose может быть непривычным, но фактически удобный, гибкий (с for не сравнить), читается легко.
Бенчмарки не делал, самому интересно. Скорее всего сольет вчистую классике на for, на больших объемах должен быть производительнее, чем цепочка методов над array. Может на досуге потестирую, напишу отдельно заметку.
1) Изначальный пост о введении transducers в clojure ("Transducers are coming") говорит, что они приходят в «core» и «core.async». К примеру, ваши хваленные итераторы не могут работать с асинхронными источниками данных (rxjs, к примеру). Кейсы, когда нужен реюз одного алгоритма и для массива, и для асинхронного потока — есть, но весьма редки. Если у вас такого нет, то вы можете не использовать трандьюсеры с чистой душой.
2) Трандьюсеры очень серьезно помогают дизайну языка. Рича Хикки просто задолбало то, что для каждого вида коллекции нужно реализовывать набор методов поразительно схожий по коду. Если вы не пишите свой язык и не пишите свои коллекции, то вы можете не обращать внимания на транcдьюcеры с чистой душой. Они просто придут к вам внезапно. Если выживут, конечно.
3) На всякий случай. Изначально в clojure были ленивые последовательности и все методы работы с коллекциями прекрасно с ними работали. Это чтобы вы не думали, что их из-за незнания итераторов ввели.
Спасибо за информативный комментарий. До статьи Рича к стыду своему не добрался, лисп все же мне далек. В обучалках да, нюансы, которые вы описали — потерялись. Моя идея была в том, что экономить память при преобразовании потока можно и более привычным способом.
К примеру, ваши хваленные итераторы не могут работать с асинхронными источниками данных
Итераторы — нет, но генераторы-то ведь да?
И вообще, мне показалось, что статья не про «Трансдьюсеры — кака», а про «Трансдьюсеры это те же генераторы». И если вы не можете вкурить про трансдьюсеры, вкурите про генераторы и пользуйтесь на здоровье. То же самое, только с перламутровыми пуговицами.
Мне вот лично тоже кажется, что генераторы понять проще, чем трансдьюсеры.
И вообще, мне показалось, что статья не про «Трансдьюсеры — кака», а про «Трансдьюсеры это те же генераторы». И если вы не можете вкурить про трансдьюсеры, вкурите про генераторы и пользуйтесь на здоровье. То же самое, только с перламутровыми пуговицами.
В этом то и дело, что трансдьюсеры != генераторы. Трансдьюсеры мощнее и гибче. А код на генераторах писать более привычно. По своей сути генераторы являются кастрированной специализированной do-нотацией. Генераторы — это сахар. Трансдьюсеры сахаром не являются.
Вы вообще гляньте на заголовок и вступление статьи. Начало вовсе не о том, что ленивую обработку можно сделать через генераторы. Вот скажите: эта статья у вас не вызвала ощущение, что трансдьюсеры придумали упоротые астронавты? На всякий случай, перечитайте свой комментарий.
Итераторы — нет, но генераторы-то ведь да?
Да, есть такой proposal. Он позволяет писать асинхронный код на генераторах, не спорю. Пожалуй, я криво сформулировал начальное предложение. Возможно даже похоже на то, как сформулировал автор поста вступление :-).
Но я немного не о том говорил. Я говорил о том, что трансдьюсеры — это механизм, обеспечивающий реюз кода при обработке синхронного источника данных и асинхронного источника данных. Если вы считаете, что на генераторах можно делать реюз логики обработки данных, то пример в студию (без костылей)
Мне вот лично тоже кажется, что генераторы понять проще, чем трансдьюсеры.
Эм… Лол? Очень голословное и двоякое утверждение.
Посему есть вопросики:
1: Кому проще-то? Какой бэкграунд должен быть у человека? Мы же не спорим о том, что будет проще для абстрактных пекарей? Вы же не основываете свое личное мнение на «сложных» статьях, которые пишутся для тусовки, в которую вы не входите?
2: Проще понять концепцию или код, который получается?
3: Вы уверены, что с ростом количества кода вы все равно будете понимать как работает код на генераторах лучше, чем код на трансдьюсерах?
4: Откуда у вас уверенность, что вы понимаете как работает код написанный на генераторах? Не подменяете ли вы реальное понимание на ложное интуитивное?
По статье — да, я в начале слегка иронизирую над функциональным подходом — хотя бы в силу того, что JS всё-таки скорее императивный язык. Пожалуйста, не обижайтесь.
И концепция, и код трансдьюсеров — не очень просты. Transducers.js тому подтверждение. И про понимание, многие вещи мы понимаем и пытаемся воспринимать интуитивно. Иначе элементарно не хватит внимания на более сложные вещи. Это и есть абстракция, в конце концов.
JS всё-таки скорее императивный языкВы может удивитесь сколько людей считают JS функциональным языком. Однако, хотел бы отметить, что функциональный подход не накладывает требования на отсутствие императивщины. И никаких обид, сам считаю js нихрена не функциональным :-)
Мне тоже проще понять генераторный подходЯ постараюсь объяснить поподробнее, что мне не нравится в вашем утверждении.
Вкратце, что такое трансдьюсер. Это функция, которая принимает элемент коллекции и выдает указание что делать дальше для постройки новой коллекции. Это абстракция над map/filter без привязки к входной и выходной коллекции. А генератор это абстракция над map/filter с привязкой к входной коллекции (если она есть) и без привязки к выходной коллекции. Ужасно большое понимание требуется для первого и никакого для второго, да :-)
У вас в статье написаны библиотечные функции. Мне кажется стремным предъявлять к библиотечному коду требования простоты. Просто я очень сомневаюсь, что вы легко понимаете код браузера. Да блин, библиотеки существуют, чтобы делать какие-то типичные задачи наилучшим образом, а не самым понятным. Я надеюсь, это снимет вопрос о понимании map/filter.
Касательно генераторов. Когда у вас есть map/filter, то количество кода на генераторах стремится к минимуму. И никто вам не запрещает писать генератор. Мы же тут не говорим о том, чтобы брать микроскоп для забивания гвоздей.
И вот когда у вас есть уже готовая библиотека, то вопрос о сложности превращается: а насколько легко это использовать? И вы легко можете написать вместо transduce функции mapIntoArray(sourceCollection, algo), mapIntoSet(soureCollection, algo) и т.д.
Я просто реально не понимаю где вы видите сложность этого подхода. Я вижу только то, что у transducers ужасная документация и идиотское именование.
В начале посмотрев на код и слова что "комментарии излишни" подумал что я совсем дно. Пока не дошел до комментариев:)
Трансдьюсеры это трансформаторы потоков (с pull или push интерфейсами). Конечно нет необходимости использовать интерфейсы потоков из Clojure в JS, где свои интерфейсы. В этой статье функции трансформируют ES итераторы. Но это так же потоковый интерфейс.
Термин трансдьюсер использовался как трансформатор потоков задолго до появления их в Clojure и для других интерфейсов.
Тут я немного описывал это с большими деталями. И тут с добавлением асинхронных генераторов.
const mixFn = compose(greduce((c, v) => c + v, 0), square, moreThan5);
let yyy = [...mixFn(values)];
greduce(..) вернет число, а не итератор. spread-оператор не нужен для записи в переменную.
Трансдьюсеры в JS – так ли уж необходимы?