http://ramdajs.com/repl/?v=0.24.1#?const%20f1%20%3D%20R.pipe%28R.prop%28%27value%27%29%2C%20%20R.sum%29%3B%0Aconst%20f2%20%3D%20R.pipe%28R.prop%28%27value%27%29%2C%20%20R.always%29%3B%0A%0Af1%28%7B%20value%3A%20%5B1%2C2%2C3%5D%20%7D%29%20%2F%2F%206%0Af2%28%7B%20value%3A%20%5B1%2C2%2C3%5D%20%7D%29%20%2F%2F%20function%20%3F%3F%3F

Там есть шортссылка.

да ну, вложенные тернарки, не стоит как пример брать)

Два вложенность разве большая? Все могут такое прочитать без проблем. Какую альтернативу ты используешь?

а чего имена файлов в camelCase, а не в классическом для жс kebab-case?

У airbnb в стайлгайде PascalCase проповедуют.

У airbnb в стайлгайде PascalCase проповедуют.

Я раньше тоже думал гуд. В итоге сменил на проекте на kebab-case

Как имена пакетов нпм

Я так тоже использую kebab-case, но не думал, что это стандарт.

Ну нпм не позволяет верхний регистр в имени пакета

snake_case это удел рубистов

в имени пакетов kebab юзаем, а так PascalCase

хз, лично мне вообще без разницы)

Но сейчас пришлось переписать всё без рамды (можно приценить для сравнения) https://github.com/zerobias/telegram-mtproto/blob/feature/mtproto3/packages/mtproto-logger/src/string-transform.js Потому что от этой части кода требуется максимальное быстродействие ?

На счёт быстродействия. Что, настолько всё медленно с Рамдой работает, что выпилил? А в каких кейсах тогда профит от неё?

На счёт быстродействия. Что, настолько всё медленно с Рамдой работает, что выпилил? А в каких кейсах тогда профит от неё?

ты не поверишь. в декларативности

Да этим то и мне нравится.

Но где грань, после которой идёт потеря производительности? Просто боюсь увлечься этой декларативностью в ущерб производительности.

решай проблемы по мере их поступления

Думаю, что в случае больших массивов данных (>1000 элементов) при расчётах в реалтайме(<500мс) уже стоит задуматься о for и if.

быстродействие можно померять по работающим фичам

Думаю, что в случае больших массивов данных (>1000 элементов) при расчётах в реалтайме(<500мс) уже стоит задуматься о for и if.

В фп работают со списками, вставить элемент за O(1).

Я имею ввиду случаи, когда мы проходим массив не один раз и делаем все необходимые преобразования над ним с помощью for, а повторяющиеся проходы с помощью map, filter и т.п. Тут же будет потеря.

Думаю сейчас настолько все оптимизировано, что там потеря будет настолько незначительной, что не имеет смысла использовать for, а если уже есть смысл, то стоит задумать про webassembly, это уже не для js работа, кмк.

Я имею ввиду случаи, когда мы проходим массив не один раз и делаем все необходимые преобразования над ним с помощью for, а повторяющиеся проходы с помощью map, filter и т.п. Тут же будет потеря.

или нет, надо смотреть на реальных случаях и делать замеры, смотреть что именно тормозит

Думаю сейчас настолько все оптимизировано, что там потеря будет настолько незначительной, что не имеет смысла использовать for, а если уже есть смысл, то стоит задумать про webassembly, это уже не для js работа, кмк.

Нет, ты не совсем прав

Не отрицаю. ?

Из-за большого числа пересоздающихся функций, а так же из-за потрясающей универсальности либы, её реализация реально не совсем катит для мега быстрых задач. Но в среднем проекте таких задач как правило от одной до нуля))

На счёт быстродействия. Что, настолько всё медленно с Рамдой работает, что выпилил? А в каких кейсах тогда профит от неё?

Ща поясню, 5 мин

Думаю сейчас настолько все оптимизировано, что там потеря будет настолько незначительной, что не имеет смысла использовать for, а если уже есть смысл, то стоит задумать про webassembly, это уже не для js работа, кмк.

У меня был кейс, где каждые 500 мс приходит 2000 координат для карты. Там были повторяющиеся координаты. Я сначала решил фильтровать по привычке с помощью lodash.uniqBy перед каждым циклом отрисовки и получил сильные тормоза. Потом просто стал пропускать эти координаты в цикле отрисовки с помощью continue и всё полетело.

uniqBy по двум тысячам координат ?? сурово)

перед каждым рендером

жестко

Его проблема же именно в uniq)

У меня был кейс, где каждые 500 мс приходит 2000 координат для карты. Там были повторяющиеся координаты. Я сначала решил фильтровать по привычке с помощью lodash.uniqBy перед каждым циклом отрисовки и получил сильные тормоза. Потом просто стал пропускать эти координаты в цикле отрисовки с помощью continue и всё полетело.

будь у тебя в 10 раз меньше координат, ты вероятно даже не узнал бы, что это медленно

У меня был кейс, где каждые 500 мс приходит 2000 координат для карты. Там были повторяющиеся координаты. Я сначала решил фильтровать по привычке с помощью lodash.uniqBy перед каждым циклом отрисовки и получил сильные тормоза. Потом просто стал пропускать эти координаты в цикле отрисовки с помощью continue и всё полетело.

Я же про нативные map/filter/reduce.

Я же про нативные map/filter/reduce.

ну при больших данных бывает есть смысл экономить на вызовах, даже таких

другое дело, что экономить до того, как бенч показал, что тормозит редко есть смысл

т.е. еще реже, чем бывает сам кейс больших данных

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

Самое смешное, что нативный .map далеко не самый быстрый)

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

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

тут сложно предсказывать, надо знать и движок, на котором ранается, а то эти оптимизаторы да jit такого наворотят

На счёт быстродействия. Что, настолько всё медленно с Рамдой работает, что выпилил? А в каких кейсах тогда профит от неё?

Начну немного с отвлеченного примера ? Как то раз я протяжении двух недель не мог поймать странный плавающий баг — тупо не проходила авторизация, возникало ощущение, что запросы к серверу "проскальзывают" мимо друг друга. Для его исправления мне оказалось достаточно закомментировать один неудачный console.log ? Текущие ттх этого модуля: мемоизация всех возможных аргументов, данные выводятся с задержкой во избежание конфликта с важными вычислениями, сообщения для эффективности собираются в два уровня буферизации, а пиковая скорость вывода данных в максимально вербозном режиме достигает двух мегабайт в секунду) В общем этот модуль — это крайне критичное к быстродействию место?

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

ты бандл порежь и префетчи настрой

потом бенчи

Начну немного с отвлеченного примера ? Как то раз я протяжении двух недель не мог поймать странный плавающий баг — тупо не проходила авторизация, возникало ощущение, что запросы к серверу "проскальзывают" мимо друг друга. Для его исправления мне оказалось достаточно закомментировать один неудачный console.log ? Текущие ттх этого модуля: мемоизация всех возможных аргументов, данные выводятся с задержкой во избежание конфликта с важными вычислениями, сообщения для эффективности собираются в два уровня буферизации, а пиковая скорость вывода данных в максимально вербозном режиме достигает двух мегабайт в секунду) В общем этот модуль — это крайне критичное к быстродействию место?

воу, жестко)

Но сейчас пришлось переписать всё без рамды (можно приценить для сравнения) https://github.com/zerobias/telegram-mtproto/blob/feature/mtproto3/packages/mtproto-logger/src/string-transform.js Потому что от этой части кода требуется максимальное быстродействие ?

это же вроде фьюзится https://github.com/zerobias/telegram-mtproto/blob/feature/mtproto3/packages/mtproto-logger/src/string-transform.js#L70-L71

это же вроде фьюзится https://github.com/zerobias/telegram-mtproto/blob/feature/mtproto3/packages/mtproto-logger/src/string-transform.js#L70-L71

Да, как ещё в паре мест, если я правильно тебя понял, потому что это один к одному переделанные трансдюсеры. У меня там висит такой список issues, что уже как-то неудобно прокачивать дальше и без того огромный модуль для логов)

Я пока счёл достаточным, что там вся эта операция быстро мемоизируется, так как список этих тегов — конечен

Я пока счёл достаточным, что там вся эта операция быстро мемоизируется, так как список этих тегов — конечен

?

?

М?)

В разных частях кода вызывается log`tag,messages,description`(...data) С этими тегами в бэктиках производится довольно много преобразований для требуемого форматирования, поэтому они все создаются только при первом вызове такого лог-сообщения

Народ, а где можно посмотреть versions history по ramda? Что б при появлении каждой новой версии сразу видеть список новых или модифицированных методов?

У них в issues

https://github.com/ramda/ramda/issues?q=is%3Aissue+is%3Aopen+label%3A%22upgrade+guide%22

https://github.com/ramda/ramda/issues?q=is%3Aissue+label%3A%22upgrade+guide%22+is%3Aclosed

первое это открытые и второе это уже релизы бывшие

как вы смотрите на то, что я выложу все пейперы (pdf) о Recursion Schemes (все, что я находил, когда разбирался с этой темой)

@xgrommx спасибо!

У них в issues

Конечно это не очень хорошо говорит о "поставленности" проекта )

Да они странные просто

Им просто плевать на то, будут ли их продукт юзать

Там полноценные посты по изменениям, нет никакой разницы куда их постить, но делают почему то там

Им просто плевать на то, будут ли их продукт юзать

Ну вот это точно нет)

все эти mergeDeepWith.. есть просто рекурсивные версии mergeWith

в них я не увидел что надо было так api раздувать

Там полноценные посты по изменениям, нет никакой разницы куда их постить, но делают почему то там

может потому что в issues можно обсудить все?)

Хз, это не отменяет же release notes

ERROR: S client not available

ну это конечно умно https://github.com/ramda/ramda/blob/master/CHANGELOG.md

innerJoin кстати хорошая штука)

хм

это же просто filter + contains

как вы смотрите на то, что я выложу все пейперы (pdf) о Recursion Schemes (все, что я находил, когда разбирался с этой темой)

Что это и для чего ты разбирался?

это же просто filter + contains

Это вообще всё один большой оверхед над аппликацией и абстракцией

функторная алгебра что заменяет примитивную и структурную рекурсии корекурсии (ну всякие cata,ana,para,apo,hylo) морфизмы

как вы смотрите на то, что я выложу все пейперы (pdf) о Recursion Schemes (все, что я находил, когда разбирался с этой темой)

Мне интересно, скидывай

2 варианта

const innerJoin_ = (p, xs, ys) => xs.filter(x => ys.filter(y => p(x, y)).length > 0) const innerJoin__ = (p, xs, ys) => chain(x => chain(y => p(x, y) ? x : [], ys), xs)

можно даже так) const innerJoin_ = (p, xs, ys) => xs.filter(x => ys.some(y => p(x, y)))

Помогите переписать вот этот небольшой кусок на чистую композицию. Что-то не пойму как впихнуть R.ifElse в R.pipe и захватывать внешние переменные.

http://ramdajs.com/repl/#?const%20STATUS_LIST%20%3D%20%5B%27active%27%2C%20%27draft%27%5D%3B%0Aconst%20payload%20%3D%20%7B%0A%20%20state%3A%20true%2C%0A%20%20status%3A%20%27active%27%2C%0A%20%20newDataLength%3A%202%2C%0A%20%20canDelete%3A%20true%2C%0A%7D%3B%0A%0Aconst%20changer%20%3D%20R.pipe%28%0A%20%20payload%20%3D%3E%20STATUS_LIST.includes%28payload.status%29%0A%20%20%3F%20%7B%0A%20%20%20%20...payload%2C%0A%20%20%20%20state%3A%20payload.newDataLength%20%3E%3D%201%2C%0A%20%20%7D%0A%20%20%3A%20%7B%0A%20%20%20%20...payload%2C%0A%20%20%20%20state%3A%20false%2C%0A%20%20%7D%2C%0A%20%20%28%7B%20state%2C%20canDelete%20%7D%29%20%3D%3E%20state%20%26%26%20canDelete%2C%0A%29%3B%0A%0Aconsole.log%28changer%28payload%29%29%3B

Только там я хреново payload назвал, глобальный который.

Захватываю я STATUS_LIST, чтобы в payload не пихать.

Помогите переписать вот этот небольшой кусок на чистую композицию. Что-то не пойму как впихнуть R.ifElse в R.pipe и захватывать внешние переменные.

Напоминаю)

Отказ от переменных ради отказа от переменных не нужен, если проще написать с ними — пиши, это ок) Стиль рамды позволяет абстрагироваться от конкретных объектов и описывать операции в общем виде, в универсальной и краткой форме

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

Потом начинаешь замечать, что всё большая и большая часть задач оказывается атомарной да и вообще повторяется

А попытаться сразу писать point-free-everything — это прямой путь к fp fatigue, сколько раз уже наблюдал подобное ?

Забрал себе в архив. Спасибо

Вообще неочевидный момент, но если чувствуешь, что код "не катит" как фп то лучше эту попытку оставить)

Причина в том, что структуры данных просто плохо подходят под такую форму

Помогите переписать вот этот небольшой кусок на чистую композицию. Что-то не пойму как впихнуть R.ifElse в R.pipe и захватывать внешние переменные.

Если нужно создать композицию из нескольких параметров (тебе же нужно одновременно передать и STATUS_LIST и payload), то для этого подходит useWith Вот пример: из официального кукбука: var dotPath = R.useWith(R.path, [R.split('.')]); var propsDotPath = R.useWith(R.ap, [R.map(dotPath), R.of]); var obj = { a: { b: { c: 1 } }, x: 2 }; propsDotPath(['a.b.c', 'x'], obj); // => [ 1, 2 ]

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

Для обычных объектов point free запись постоянно встаёт поперёк, ну просто так неудобно работать

Для обычных объектов point free запись постоянно встаёт поперёк, ну просто так неудобно работать

С этим согласен ) Поначалу относил это на то, что просто ПОКА не привык )

А для объектов отвечающих спеке fantasy-land рамда — это как рельсы, с ускорителем)

Помогите переписать вот этот небольшой кусок на чистую композицию. Что-то не пойму как впихнуть R.ifElse в R.pipe и захватывать внешние переменные.

http://ramdajs.com/repl/#?const%20STATUS_LIST%20%3D%20%5B%27active%27%2C%20%27draft%27%5D%3B%0Aconst%20payload%20%3D%20%7B%0A%20%20state%3A%20true%2C%0A%20%20status%3A%20%27active%27%2C%0A%20%20newDataLength%3A%202%2C%0A%20%20canDelete%3A%20true%2C%0A%7D%3B%0A%0Aconst%20changer%20%3D%20R.pipe%28%0A%20%20R.ifElse%28%0A%20%20%20%20payload%20%3D%3E%20STATUS_LIST.includes%28payload.status%29%0A%20%20%2C%20payload%20%3D%3E%20%28%7B%0A%20%20%20%20...payload%2C%0A%20%20%20%20state%3A%20payload.newDataLength%20%3E%3D%201%2C%0A%20%20%7D%29%0A%20%20%2C%20payload%20%3D%3E%20%28%7B%0A%20%20%20%20...payload%2C%0A%20%20%20%20state%3A%20false%2C%0A%20%20%7D%29%29%2C%0A%20%20%28%7B%20state%2C%20canDelete%20%7D%29%20%3D%3E%20state%20%26%26%20canDelete%2C%0A%29%3B%0A%0Aconst%20changer_%20%3D%20%0A%20%28%7Bstatus%2C%20newDataLength%2C%20canDelete%7D%29%20%3D%3E%20%0A%20%20STATUS_LIST.includes%28status%29%20%26%26%20newDataLength%20%3E%3D%201%20%26%26%20canDelete%0A%0Aconsole.log%28changer%28payload%29%29%3B