Вообще, говоря честно, наверное надо было серию статей писать где-то на другом ресурсе. Теперь я это понимаю. Наверное я их все удалю и перенесу в какое-то другое место позже. Главное чтобы в поисковых системах светились. Честно говоря я просто устал, что вместо хоть сколько нибудь нормальной реакции получаешь как обычно копну зачастую нерациональной критики, на которую потом ещё тратится моё личное время и нервы. И почти ни одного поста, который дал бы мне нечто полезное. Зачем я вообще закидывал сюда посты о рамде? Чтобы какие-то старпёры хабра, простите, доказывали мне, что я идиот, который вообще не понимает зачем это нужно? Я не ради этого переводил статьи.
Вы наверное и редукс в проектах не используете, потому что слишком сложно? Знаете, на проект, использующий редукс, новичок без опыта точно также будет смотреть как баран на новые ворота. Только вот большинство людей этого мира все-таки понимают бенефиты от редакса (но не все старпёры хабра, надо заметить). Реакт тоже может быть довольно сложной асинхронной хернёй в некоторых случаях в силу своего управления стейта, однако мир современный он завоевал. И проекты, которые пишут на реакте и редаксе — они в реальности намного более более простые для понимания, я лично по своему опыту вижу, чем те проекты, в которых применяется некая самописная логика, подобная вашей. Но для человека, который в реакте и редаксе не разбирается — это будет адом в каком-то смысле. Ибо ему совершенно будет непонятно, что и как устроено. До того момента пока он не почитает вдумчиво официальную документацию к инструментам. Точно также с рамдой. Я честно вообще не вижу здесь пространства для споров, хотя посетители хабра иногда меня конечно удивляют подобными вышеуказанными статьями. Уже половина мира использует редакс — но на хабре есть масса людей, которые считают, что редакс это вообще плохо… Как-бы нам в своём мирке таким макаром не остаться совсем, даже железного занавеса никакого не нужно, достаточно подобного вашему стремления подтасовать факты в своих измышлениях и успокоиться на этом, как на высокообъективных доказательствах.
Я наверное дальше не буду обсуждать это, извините. Для меня лично просто всё понятно в этом плане. Я не знаю что тут дальше привести, зачем тратить время на обсуждение этого. Если у вас другое мнение — я рад за то, что вы способны его иметь и высказывать. А спорить я не люблю.
Ну окей, тогда код на рамде можно упростить ещё сильнее, на основе вашего подхода:
const alwaysDrivingAge = max(16)
Я абсолютно серьёзно, оно работает, именно так, как надо.
Вы уже второй, кто меня пытается уличить в "усложнении", хотя я вообще в конкретно этой сериии статей вижу наоборот такие подходы, которые код как раз упрощают и сокращают, а не наоборот.
Да это же чисто вопрос того, насколько ты привык шпилить проекты на Rx.js и Ramda. Если бы я пилил на них уже пару лет — я бы понял там всё намного быстрее.
Я согласен, что в данном случае императивный вариант оказался вполне хорош.
Вышеуказанный пример функциональщины я лично не могу никак посчитать идеальным. В нём много чего путает, в силу того, как его написал сам автор: десяток анонимных функций уже сам по себе сбивает с толку. Был бы я тимлидом в проекте, увидел бы такую портянку — раскритиковал бы автора за это и заставил переписывать на нормальные именованные функции-блоки, имеющие ясную логику работы. Вы в своём примере примерно это же и сделали ведь. С этим кодом надо бы сделать то же самое, а сейчас он действительно выглядит и страшным, и запутанным, я с этим не спорю. Но запутан он не потому что там используется функциональщина, а потому что автор не стремился к ясности, видимо очень ему хотелось именно "понтануться" различными вывертами функциональными, что я лично никогда не ценил в людях.
Однако, даже несмотря на все эти недостатки, в нём можно разобраться, можно его отрефакторить, сделать более чистым и ясным. Ещё хорошо бы знать Rx.js на нормальном уровне, чтобы сделать это ещё более качественным образом. У меня возникает ощущение, что этот код писал не совсем опытный программист, хотя-бы та же связка с жиквери немного обескураживает.
И вообще в этом случае, по-моему, не надо было совсем использовать Rx.js, ибо он не для подобных вещей, он скорее для реакции на множественные потоки событий предназначем, как я знаю. Он здесь просто излишен, ни к чему. Переусложнение без необходимости.
Можно написать намного более простую реализацию с использованием только рамды и нативной подписки на DOM-события, этого было бы более чем достаточно.
А говнокод может быть и в императивном коде ведь. Я очень не уверен в данный момент, что всякую функциональщину можно назвать "говнокодом" априори, как вы это пытаетесь сделать.
Вообще, там надо банально хранить где-то историю выбранных значений, наверное, чего в коде с использованием rxjs и рамдой не делается в данной реализации. Но это можно исправить, переписав немного код по другому. Примерно как в том примере с императивной реализацией, которую вы написали. Для человека достаточно развитого это вряд ли станет проблемой. Вся суть лишь в том, что надо индекс последнего активного элемента где-то хранить и вытаскивать при клике с зажатым шифтом. Вроде для меня всё стало ясно и понятно. Вопрос с "непонятностью" функциональщины на этом, надеюсь, в какой-то степени снимается с повестки)
Почитал, изучил тему, разобрался с кодом. Вообще, проблема конкретно в этом примере не связана с Ramda, она была связана с Rx.js. Пришлось немного изучить, как он работает и понять суть проблемы.
Мне хватило примерно получаса чтобы разобраться с проблемой. Естественно, функциональщина — это такая штука, с которой, наверное, сможет разобраться тот, у кого есть более-менее основательный опыт в программировании. Для меня лично логика вполне стала уловимой и ясной из вышенаписанного кода спустя где-то 20 минут изучения логики работы используемых функций, благо документация к ним имеется в открытых источниках.
Кто сомневался, что ванила быстрее библиотеки? Поэтому реакт и вью и проводят столько работ по оптимизации своего кода. Конечно на ваниле все в тысячи раз быстрее. Кроме скорости разработки конкретных фич в проектах)
Я рад за неё. Сжатый код всей рамды весит 12 килобайт. Примерно в 2.5 раза меньше текущего jquery и в 2 раза меньше лодаша. Код современных проектов обычно в сотни раз объемнее. При этом, с использованием рамды, есть определенная вероятность, что по конечному объему размер кода проекта выйдет даже меньшим, в силу большого количества переиспользования одних и тех же строительных блоков-функций, так что это спорное утверждение изначально.
Мне кажется, что вы просто привыкли к императивной логике, и поэтому она кажется сейчас вам более простой, чем декларативная)
Сравните два этих примера:
const alwaysDrivingAge = age => age <= 16 ? 16 : age;
const alwaysDrivingAge = when(lt(__, 16), always(16));
Первый императивный, второй декларативный. Я чуток упростил второй пример, применив в нём "бесточечную нотацию", о которой рассказывается в следующей части серии, это не мешает ему оставаться рабочим.
Вот для простого человека, который программирование знает совсем мало, какой из вариантов выглядит более очевидным сейчас?) Думаю, это дело привычки в большей степени. Не стоит торопиться с выводами, наверное надо немного поработать с написанием подобного кода, чтобы начать воспринимать его как нечто привычное.
Сразу говорю, оставляю за собой право не отвечать на сообщения, ибо здесь такое ощущение, что собрались какие-то ненавистники редакса, которых переубеждать желания никакого нету.
Напишу лишь пример реального проекта, вы просили его. Я сейчас являюсь одним из фронтенд разрабов проекта https://rawg.io
Никаких указанных вами проблем в разработке не возникает, редакс на мой личный взгляд — прекрасная вещь, очень сильно упрощающая разработку. Страшно вспоминать свои дни с бекбоном и отдельными стейтами компонентов. Повторяю: спорить не собираюсь, время ценнее.
Я же дал ссылку на документацию, неужели настолько лень пойти и почитать? Усмирите свое желание поворчать и поспорить, в идеале вообще избавьте себя от такой части характера.
Проект открытый, создайте ишью, отправьте пул реквест, создайте свой собственный менеджер пакетов, вам никто ничего не должен из разрабов npm'а, они вроде добровольно всем занимаются. Впрочем, всего этого даже не надо делать: yarn сейчас наиболее близок к composer'у, поэтому если есть желание — можно использовать просто его.
Там дело в том, что команда npm i изменяла существующий package-lock.json на новый, как написано в док-ции к этому файлу:
package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json.
Теперь у нас есть команда npm ci, которая не будет изменять этот файл, обновляя зависимости проекта на самые последние, вместо этого он будет устанавливать строго то, что содержится в этом файле.
Спасибо, теперь и для таких тупых как я понятно, откуда всё это)
Картинка из инета для наглядности:
Оно конечно чисто со смысловой стороны меня всё равно до сих пор никак не удовлетворяет, я не вижу логики называть "дополнением" и то, что происходит на картинке… Ну теперь хотя-бы понятно, откуда растут корни )
Логику работы этой функции в фп-языках более правильно было бы описать как "отрицание" всё-таки. Пока что я так понимаю. До сих пор не могу уловить, каким образом её можно было назвать комплементом. В этом и весь вопрос был.
Так и переводится, "дополнение", всё верно. И как вы логически соотносите "дополнение" и "отрицание"? Это синонимы, или, может, термины, близкие друг к другу по значению? Я лично под "отрицанием" понимаю одно, а под "дополнением" — другое. А комплимент здесь причём?
Это да, это понятно… Только обычный человеческий смысл этого слова какой-то совсем другой, и это сбивает меня с толку ) Обычно есть всё-таки нормальная логическая связь терминов из языков программирования с терминами из нашего реального мира.
Это будет перевод оригинального цикла, мне кажется, автор уже не будет обновлять свои статьи, а я пока слишком мало знаю о рамде, чтобы дописывать что-то о ней от себя :)
Напишите вы от себя в комментах, из того что знаете дополнительно, думаю, все будут признательным вам, в том числе и я )
Не знаю. Конкурировать с таким монстром как Гугл — не такая простая задача. Как нынче иногда посмеиваются в сторону Сафари, идущего подобной дорогой, называя его "современным ие", также и с вами может возникнуть подобная проблема.
Возможно, всё-таки лучше оставаться на той самой стратегии, на которой находитесь в данный момент вы.
Вообще, говоря честно, наверное надо было серию статей писать где-то на другом ресурсе. Теперь я это понимаю. Наверное я их все удалю и перенесу в какое-то другое место позже. Главное чтобы в поисковых системах светились. Честно говоря я просто устал, что вместо хоть сколько нибудь нормальной реакции получаешь как обычно копну зачастую нерациональной критики, на которую потом ещё тратится моё личное время и нервы. И почти ни одного поста, который дал бы мне нечто полезное. Зачем я вообще закидывал сюда посты о рамде? Чтобы какие-то старпёры хабра, простите, доказывали мне, что я идиот, который вообще не понимает зачем это нужно? Я не ради этого переводил статьи.
Вы наверное и редукс в проектах не используете, потому что слишком сложно? Знаете, на проект, использующий редукс, новичок без опыта точно также будет смотреть как баран на новые ворота. Только вот большинство людей этого мира все-таки понимают бенефиты от редакса (но не все старпёры хабра, надо заметить). Реакт тоже может быть довольно сложной асинхронной хернёй в некоторых случаях в силу своего управления стейта, однако мир современный он завоевал. И проекты, которые пишут на реакте и редаксе — они в реальности намного более более простые для понимания, я лично по своему опыту вижу, чем те проекты, в которых применяется некая самописная логика, подобная вашей. Но для человека, который в реакте и редаксе не разбирается — это будет адом в каком-то смысле. Ибо ему совершенно будет непонятно, что и как устроено. До того момента пока он не почитает вдумчиво официальную документацию к инструментам. Точно также с рамдой. Я честно вообще не вижу здесь пространства для споров, хотя посетители хабра иногда меня конечно удивляют подобными вышеуказанными статьями. Уже половина мира использует редакс — но на хабре есть масса людей, которые считают, что редакс это вообще плохо… Как-бы нам в своём мирке таким макаром не остаться совсем, даже железного занавеса никакого не нужно, достаточно подобного вашему стремления подтасовать факты в своих измышлениях и успокоиться на этом, как на высокообъективных доказательствах.
Я наверное дальше не буду обсуждать это, извините. Для меня лично просто всё понятно в этом плане. Я не знаю что тут дальше привести, зачем тратить время на обсуждение этого. Если у вас другое мнение — я рад за то, что вы способны его иметь и высказывать. А спорить я не люблю.
Ну окей, тогда код на рамде можно упростить ещё сильнее, на основе вашего подхода:
Я абсолютно серьёзно, оно работает, именно так, как надо.
Вы уже второй, кто меня пытается уличить в "усложнении", хотя я вообще в конкретно этой сериии статей вижу наоборот такие подходы, которые код как раз упрощают и сокращают, а не наоборот.
Да это же чисто вопрос того, насколько ты привык шпилить проекты на Rx.js и Ramda. Если бы я пилил на них уже пару лет — я бы понял там всё намного быстрее.
Я согласен, что в данном случае императивный вариант оказался вполне хорош.
Вышеуказанный пример функциональщины я лично не могу никак посчитать идеальным. В нём много чего путает, в силу того, как его написал сам автор: десяток анонимных функций уже сам по себе сбивает с толку. Был бы я тимлидом в проекте, увидел бы такую портянку — раскритиковал бы автора за это и заставил переписывать на нормальные именованные функции-блоки, имеющие ясную логику работы. Вы в своём примере примерно это же и сделали ведь. С этим кодом надо бы сделать то же самое, а сейчас он действительно выглядит и страшным, и запутанным, я с этим не спорю. Но запутан он не потому что там используется функциональщина, а потому что автор не стремился к ясности, видимо очень ему хотелось именно "понтануться" различными вывертами функциональными, что я лично никогда не ценил в людях.
Однако, даже несмотря на все эти недостатки, в нём можно разобраться, можно его отрефакторить, сделать более чистым и ясным. Ещё хорошо бы знать Rx.js на нормальном уровне, чтобы сделать это ещё более качественным образом. У меня возникает ощущение, что этот код писал не совсем опытный программист, хотя-бы та же связка с жиквери немного обескураживает.
И вообще в этом случае, по-моему, не надо было совсем использовать Rx.js, ибо он не для подобных вещей, он скорее для реакции на множественные потоки событий предназначем, как я знаю. Он здесь просто излишен, ни к чему. Переусложнение без необходимости.
Можно написать намного более простую реализацию с использованием только рамды и нативной подписки на DOM-события, этого было бы более чем достаточно.
А говнокод может быть и в императивном коде ведь. Я очень не уверен в данный момент, что всякую функциональщину можно назвать "говнокодом" априори, как вы это пытаетесь сделать.
Вообще, там надо банально хранить где-то историю выбранных значений, наверное, чего в коде с использованием rxjs и рамдой не делается в данной реализации. Но это можно исправить, переписав немного код по другому. Примерно как в том примере с императивной реализацией, которую вы написали. Для человека достаточно развитого это вряд ли станет проблемой. Вся суть лишь в том, что надо индекс последнего активного элемента где-то хранить и вытаскивать при клике с зажатым шифтом. Вроде для меня всё стало ясно и понятно. Вопрос с "непонятностью" функциональщины на этом, надеюсь, в какой-то степени снимается с повестки)
Почитал, изучил тему, разобрался с кодом. Вообще, проблема конкретно в этом примере не связана с Ramda, она была связана с Rx.js. Пришлось немного изучить, как он работает и понять суть проблемы.
Вот исправленный вариант, работает так, как вы хотели, без "бага": https://jsfiddle.net/a9m50xev/29/
Мне хватило примерно получаса чтобы разобраться с проблемой. Естественно, функциональщина — это такая штука, с которой, наверное, сможет разобраться тот, у кого есть более-менее основательный опыт в программировании. Для меня лично логика вполне стала уловимой и ясной из вышенаписанного кода спустя где-то 20 минут изучения логики работы используемых функций, благо документация к ним имеется в открытых источниках.
Кто сомневался, что ванила быстрее библиотеки? Поэтому реакт и вью и проводят столько работ по оптимизации своего кода. Конечно на ваниле все в тысячи раз быстрее. Кроме скорости разработки конкретных фич в проектах)
Я рад за неё. Сжатый код всей рамды весит 12 килобайт. Примерно в 2.5 раза меньше текущего jquery и в 2 раза меньше лодаша. Код современных проектов обычно в сотни раз объемнее. При этом, с использованием рамды, есть определенная вероятность, что по конечному объему размер кода проекта выйдет даже меньшим, в силу большого количества переиспользования одних и тех же строительных блоков-функций, так что это спорное утверждение изначально.
Мне кажется, что вы просто привыкли к императивной логике, и поэтому она кажется сейчас вам более простой, чем декларативная)
Сравните два этих примера:
Первый императивный, второй декларативный. Я чуток упростил второй пример, применив в нём "бесточечную нотацию", о которой рассказывается в следующей части серии, это не мешает ему оставаться рабочим.
Вот для простого человека, который программирование знает совсем мало, какой из вариантов выглядит более очевидным сейчас?) Думаю, это дело привычки в большей степени. Не стоит торопиться с выводами, наверное надо немного поработать с написанием подобного кода, чтобы начать воспринимать его как нечто привычное.
Сразу говорю, оставляю за собой право не отвечать на сообщения, ибо здесь такое ощущение, что собрались какие-то ненавистники редакса, которых переубеждать желания никакого нету.
Напишу лишь пример реального проекта, вы просили его. Я сейчас являюсь одним из фронтенд разрабов проекта https://rawg.io
Никаких указанных вами проблем в разработке не возникает, редакс на мой личный взгляд — прекрасная вещь, очень сильно упрощающая разработку. Страшно вспоминать свои дни с бекбоном и отдельными стейтами компонентов. Повторяю: спорить не собираюсь, время ценнее.
Я же дал ссылку на документацию, неужели настолько лень пойти и почитать? Усмирите свое желание поворчать и поспорить, в идеале вообще избавьте себя от такой части характера.
Проект открытый, создайте ишью, отправьте пул реквест, создайте свой собственный менеджер пакетов, вам никто ничего не должен из разрабов npm'а, они вроде добровольно всем занимаются. Впрочем, всего этого даже не надо делать: yarn сейчас наиболее близок к composer'у, поэтому если есть желание — можно использовать просто его.
Там дело в том, что команда
npm iизменяла существующийpackage-lock.jsonна новый, как написано в док-ции к этому файлу:Теперь у нас есть команда
npm ci, которая не будет изменять этот файл, обновляя зависимости проекта на самые последние, вместо этого он будет устанавливать строго то, что содержится в этом файле.Более подробно об особенностях
npm ciможно, опять же, почитать в документации к этому методу.Наверное, хорошо было бы немного прояснить этот момент в документации, да, ибо я согласен, что это немного сбивает с толку.
Большой и сложный проект + малое число контрибьютеров. Основных разрабов там два человека, как я понимаю.
Спасибо, теперь и для таких тупых как я понятно, откуда всё это)
Картинка из инета для наглядности:
Оно конечно чисто со смысловой стороны меня всё равно до сих пор никак не удовлетворяет, я не вижу логики называть "дополнением" и то, что происходит на картинке… Ну теперь хотя-бы понятно, откуда растут корни )
Логику работы этой функции в фп-языках более правильно было бы описать как "отрицание" всё-таки. Пока что я так понимаю. До сих пор не могу уловить, каким образом её можно было назвать комплементом. В этом и весь вопрос был.
Так и переводится, "дополнение", всё верно. И как вы логически соотносите "дополнение" и "отрицание"? Это синонимы, или, может, термины, близкие друг к другу по значению? Я лично под "отрицанием" понимаю одно, а под "дополнением" — другое. А комплимент здесь причём?
Это да, это понятно… Только обычный человеческий смысл этого слова какой-то совсем другой, и это сбивает меня с толку ) Обычно есть всё-таки нормальная логическая связь терминов из языков программирования с терминами из нашего реального мира.
Это будет перевод оригинального цикла, мне кажется, автор уже не будет обновлять свои статьи, а я пока слишком мало знаю о рамде, чтобы дописывать что-то о ней от себя :)
Напишите вы от себя в комментах, из того что знаете дополнительно, думаю, все будут признательным вам, в том числе и я )
Не знаю. Конкурировать с таким монстром как Гугл — не такая простая задача. Как нынче иногда посмеиваются в сторону Сафари, идущего подобной дорогой, называя его "современным ие", также и с вами может возникнуть подобная проблема.
Возможно, всё-таки лучше оставаться на той самой стратегии, на которой находитесь в данный момент вы.