4:24 -- есть прикладной код, а есть "фундаментальный". Ключевое отличие в том, что осмысленные имена для прикладного кода связаны с доменом, и поэтому должны быть длинными. А домен для фундаментального кода -- это собственна математика, которая также оперирует короткими именами. Это что касается compose(f1, f2 ...). Что касается коротких имен типов, то для Дженериков -- это вполне принятая практика: называть "любой тип" одной буквой (максимум двумя). Обратите внимание, что когда идет декларация типов для store (github.com/reduxjs/redux/blob/master/src/types/store.ts), то имена типов уже удлиняются, а параметры типов (любые типы) по-прежнему остаются короткими. Так, что если кто хочет, вполне может использовать исходники redux, как образец. Здесь нет антипаттернов.
>Так, что если кто хочет, вполне может использовать исходники redux, как образец. Здесь нет антипаттернов. Проблема в том, что redux - один большой антипаттерн.
@@dimitro.cardellini И чем же? Может тем, что это тормозной мусор? Может тем, что это тонны бойлерплейта? Может тем, что эта концепция попросту несостоятельна? Если редакс как концепция моностора состоятельна, то зачем даже его адепты пытаются пилить моностор на куски? Чисто архитектурно редакс сдох и признан несостоятельными всеми, даже его адептами. Почему я написал выше. Да, у него ещё есть хайп и адепты. Они пытаются путём тысяч обёрток и костылей распиливать стор, писать обёртки над всякими его нелепыми кусками. Но это уже выглядит нелепо.
@@dimitro.cardellini К тому же, в основном 99% адептов этого говна просто жертвы хайпа и узкого кругозора. Они попросту не видели удобных, быстрых и архитектурно качественных решений. Сейчас подобные решения начинают хайпить и редакс всё более и более маргинализируется.
@@dimitro.cardellini Хотя может я не прав и вы мне сможете назвать его преимущества и объяснить то, почему хорошая концепция и архитектура полностью умножается на ноль даже самыми преданными адептами. Как так вышло?
11:26 - next будет оригинальным dispatch, только для последнего middleware в applyMiddleware, для остальных next будет ссылкой на предыдущий middleware.
Ого)) а я всегда думал, что у меня костыль в коде и так писать не хорошо, а оказывается, что это "функциональная композиция" и так делать нужно)) спасибо)) буду знать))
Да, Евгений, потому заходит, потому-что помогает осмыслить такое видео те моменты, которым я вот например даже и значения не придал бы. Ну функция ну и функция, ну принимает функцию параметром, если нужно я и сам могу написать, и потом начинаешь писать, писать много, а чем больше пишешь тем больше времени уходит, больше ошибок, а нужно как бы заставить машину работать а не пальцы, как-то проникнутся смыслом и идеологиями годными. Проблема в том что идеологий парадигм уже на столько много что не знаешь кому ж верить, упирается всё во время. Поэтому обзоры кода заходят и будут заходить. Можно например обзор вообще кучи даже какой-то сделать вообще говнокода какого-то и это тоже зайдёт не хуже, там тоже будет смысл
8:22 - там не используется рекурсивный подход. Там используется свёртка (reduce). На выходе мы получаем именно то, что заказывали. Переполнение стека может произойти только если мы сами захотим "скомпозировать" достаточное большое число функций, но оно бы произошло и так, если бы мы просто руками написали аналогичную матрёшку. Собственно, вот аналогичный код, только для чистого JS: gist.github.com/DScheglov/45176f2bec9cc8bb818e07e4d8f5dd58 Случай для одной функции является избыточным, т.к. он полностью покрывается reduce. но вероятно сохранен для повішения производительности (reduce все же потребует несколько большего усилия, чем простая проверка.
Рекомендую прочитать про примитивную рекурсию на списках и ее связи со сверткой списков, например вот здесь - fprog.ru/2010/issue4/vitaly-bragilevsky-limits-of-folds-expressiveness/
@@S0ERDEVS Спасибо, с радостью почитаю. Но! Статья по ссылке как раз о том, что свертки -- это не рекурсии, а рекурсии -- это не свертки, но при этом одни могут быть заменены другими и наоборот ;) Собственно, замена рекурсии сверткой -- это один из способов уйти от рекурсии и связанной с ней проблемой переполнения стека (другой способ -- циклы, но этот способ "не разрешен" в ФП в виду "побочно-эффектно" природы циклов).
Речь в видео не шла о прямой рекурсии, под рекурсивным подходом я имел в виду обработку которая может быть выполнена в рамках примитивной рекурсии на списках (в данном случае список функций), свертка списка - это всего лишь оператор примитивной рекурсии.
@@S0ERDEVS Прочем статью до конца! ) Свертка была использована для определения оператора примитивно рекурсивных функций, заданных на множестве списков, исключительно для того, чтобы показать, что примитивные рекурсии можно заменить на свертку (это следует из того, то множество примитивных рекурсий замыкается по оператору примитивной рекурсии). Но! Из этого никак не слеудет, что свертка является рекурсией. Хотя, Свертку также можно определить через рекурсию. gist.github.com/DScheglov/c8c106b8c3e000cde8d723c94fe1ff08 (но очевидно, что итеративная модель будет более быстрой и безопасной с т.з. перепонления стека) Я бы не стал ссылаться на теорию вычислимости под видео, где пытаюсь "на пальцах" рассказать, что такое функциональная композиция и редакс-мидлвары. Это, конечно, характеризует меня не с лучшей стороны, но о примитивно рекурсивных функциях и теории вычислимости я узнал из Вашего комментария. Думаю, что большинство зрителей данного видео с радостью опустят данное знания без ущерба для понимания самого видео. В отношение "рекурсия" и "свертка" -- я бы остановился на том, что это неудачная оговорка или даже перевод слова "reduce".
Я перестал понимать со слов "итеративная модель". Термин "свертка" используется в функциональном программировании, итерирование не через рекурсивность в функциональном программировании - невозможно. Если мы говорим про перевод слова reduce, то он действительно часто переводится как "свертка", но в JS это на самом деле синтаксический сахар над циклами, т.е. reduce в императивном языке программирования - это "скрытый" цикл. Если мы говорим о моем видео то действительно можно было перевести слово reduce как свертка, но при этом функциональная композиция будет работать все так же рекурсивно и приводить к переполнению стека вызовов при использовании большого числа функций в композиции. Поэтому согласиться, что рекурсивности здесь нет я не могу. То что здесь нет прямой или явной рекурсии я согласен, но об этом я сказал и в видео.
4:20 -- так, собственно, кроме самого движка "redux", есть еще и redux-код: actionCreators, reducers, thunks, middlewares etc. и наличие в библиотеке compose очень помагает этот код писать.
9:35 - SOLID отлично работает не только для Классов. Open/Close -- необязательно требует наследования: композиция объектов предпочтительнее наследования.
Можно и через композицию (те же инъекции) но при этом нужно помнить что класс нельзя модифицировать. Т.е. прямое расширение композиции нарушает принцип.
ДОБРЫЙ ДЕНЬ! НЕ МОГЛИ БЫ ВЫ ПОДСКАЗАТЬ ХОРОШИЕ ПЛАТНЫЕ КУРСЫ FRONT END С НУЛЯ? БЛИЗОК К ТОМУ, ЧТОБЫ КУПИТЬ КУРСЫ ВЕБ-РАЗРАБОТКИ НА GEEKBRAINS, НО Я ПОКА СОМНЕВАЮСЬ (ЦЕНА/КАЧЕСТВО). ЗАРАНЕЕ БЛАГОДАРЮ ЗА СОВЕТЫ
Посоветуйте пожалуйста где можно почитать о правиле 0, 1 и бесконечность (5:25). Я довольно частенько сталкивался с аналогичным кодом и довольно часто приходилось его выпиливать из-за того что никаких оптимизация он не привносил (интерпретатор сам хорошо справлялся с тем чтобы срезать углы) и при этом вносит реализацию функции/метода лишние ветвления. В конкретном случае это действительно необходимо (скорее даже вынуждено) так как невозможно реализовать код так чтобы был только вариант с funcs.reduce.
не надо гуглить всё просто, в программировании есть или 0 или 1 или 1 и более, т.е. бесконечность. т.е. если тебя просят добавить функцию/метод который на вход принимает один параметр, ты уточняешь, а точно ли будет только один, если да, то это один. И уточняешь, что параметра может не быть, то есть ноль. Дальше уточняешь, а может ли быть больше одного, тебе говорят, что может быть 2 или 3, ну максимум 5, но это по факту, значит, что нужно писать так, что максимума нет. Отсюда и 0, 1 или бесконечность. Сойер где-то рассказывал кстати про какие-то принципы и там это упомянал
На самом деле даже в этом redux коде есть нарушения этого принципа, я там успел разглядеть метод принимающий (middleware1, middleware2, middleware3, middleware4, middleware5), в том же С# есть такие группы классов Tuple, Tuple...., Action, Action Func и т.д. Ограничения платформы даже на таком высоком уровне иногда заставляют городить вот такое))
Такая жесткая магия, а по факту она будет решать элементарную задачу. В итоге получится электронный молоток, чтобы удобно забивать гвозди. Сложно, понтово, и сыпаться будет на больших проектах. Как рельсы новые.
Вы могли бы делать увеличение транслируемого контента где-то до 150%? Это удобно смотреть и на компьютере, и на телефоне. Я сейчас вынужден выключить видео, потому что не вижу на экране 5.2"
4:54 -- длина имени никоим образом не зависит от области видимости ;) Только от домена, для которого пишется код. И если домен позволяет, то имя можно сделать коротким.
@@S0ERDEVS Здесь, наверное, небольшое недопонимание ) Думаю, надо просто пояснить, что я имел в виду: домен -- это предметная область (просто русскоязычный термин очень длинный Когда мы пишем код, мы всегда делаем это в рамках конкретной предметной области ... Для compose - это функциональное программирование в общем смысле. Для redux -- это управление состоянием.
8:20 Формально говоря, спецификация ES6 предполагает tail call optimization, который бы тут сработал, если бы хоть одна реализация, кроме Safari, была по спеке :D
6:24 -- свёртка -- это не рекурсия. Композиция -- это матрешка функций, и неважно, как мы ее делаем: руками или с помощью compose. А вот, если заменить "матрешку" на цикл, то мы получим затраты на организацию и выполнение цикла по функциям при каждом вызове композитной функции. В таком же варианте, у нас цикл один: при создании композитной функции. Кроме того, код, который будет итерировать функции на входе заметно больше, чем код, который итерирует их при создании композитной функции: gist.github.com/DScheglov/e39e35f3966069ac54edc7a5ba5c4625
Ниже кидал ссылку примитивную рекурсию на списках и свертку просто повторю здесь fprog.ru/2010/issue4/vitaly-bragilevsky-limits-of-folds-expressiveness/
@@S0ERDEVS я уже отписался по этому случаю ;) Свертка может быть заменена на рекурсию. А статья по ссылке о том, что отдельные случае рекурсии могут быть заменения сверткой. Но! это два разных инструмента и путать их не следует. Вот цитата из статьи по ссылке: Свёртки - удобное средство обработки списков и других структур данных. Они позволяют записывать многие функции без явной рекурсии, а также упрощают формальное доказательство их корректности.
Здравствуйте, интересно было бы Ваше мнение. Поможет ли изучение языка Haskell (прохождение курса на Stepik.org) для понимания и дальнейшего использования функционального подхода в Javascript, Python?
Нет, очевидно. Никакого функционального подхода на js/пистон нет и быть не может. Он там и ненужен. Просто в веб набежали хомячки, воспользовавшись в целом низким уровнем квалификации рядового веб-адепта - убедили этих адептов в том, что где-то там есть ФП и оно состоятельно. На самом деле нет. От фп у тебя есть лишь пару названий. А осознать уровень состоятельности ФП ты можешь через редакс. Это абсолютно несостоятельная, тормозная, убогая поделка. Который требует генерации тонн бойлерплейта. Это говно уже начало дохнуть. Как только адептам показали показатели другие подходы - они тут же поголовно побежали отсюда, ну у кого есть мозг и нету легаси-оков.
1) Ден эту функцию compose не писал, прямо на скрине видно по списку коммитивших, что его там нет. Редакс сейчас делают вообще другие люди. 2) Однобуквенные переменные - плохо, даже если это дженерики. В твиттере постоянно эту тему поднимают видные люди из React-коммьюнити: twitter.com/kentcdodds/status/1083831867294441472 3) В функции compose нет рекурсии, там функции сами себя не вызывают.
1) Автор знает просто куда лизать. Лижи кто популярен - хомячки будут лайкать тебя. 2) Это не плохо. Отсылка на реакт-комьюнити - это очень слабо. Причин тому несколько. В сравнении с крестами всё это - ясли, либо вообще уровень бактерий. Там с этим никакой проблемы нет. Второе и самое важное - это то, что генерик не предполагает имени. Это общий тип. Если ты хочешь дать ему имя - ты делаешь что-то неправильно, потому как имя предполагает какое-либо ограничение на тип. А если тебе нужно ограничение - пиши его явно. Имя же это костыль. Допустим, по твоей ссылке - её писал идиот. Это именно то о чём я говорил выше. Зачем автор написал DomElementType? Во-первых семантически итак ясно, что это типа. Но ладно. Это какие-то ограничения тайпскрипта, но это дыра. Потому как семантические это не DomElement. Правильно бы это писалось так: T extends DomElement и уже сразу понятно что это. Никакое имя менять ненужно. Тоже самое и с PropsType. Props - это уже тип - зачем адепт заново пишет, что это тип? Те, кто писали базовую версию - не настолько идиоты. Второе - семантически это не пропсы. Насколько я знаю в пропсах должен быть children. Поэтому это так же можно заменить на extends, т.е. ограничить тип. Изначально это не написано, скорее всего, по очевидным причинам. Это ограничения уже существуют в RefForwardingComponent и постоянно их писать - лениво. Но если уж хочется "понятности" - пиши ограничения, а не идиотские имена. 3) Здесь автор просто пытается лизать и повторять все базворды, которые у него ассоциируются с ФП.
Для объединения редьюсеров используется combineReducers. Она на вход принимает объект, а на выходе даёт сборный редьюсер. Это точно не композиция функций.
Soer, мне 18, учусь на первом прогерском курсе весьма неплохого универа. С программированием знаком с 15ти есть два больших проекта и 1.5 года опыта удаленной работы. Подскажи что делать: углубиться в математику(учебу в универе) или начать искать работу?
Хоть бы примеры кода приводили, написанием небольших кусочков кода. Если сравнивать как вы рассказываете, это объяснение инструкции пылесоса со своими мыслями. Просто вроде и хочется подписаться но когда смотрю, что после таких объяснений, ощущаю что меня укусил диванный аналитик (думаю вы не такой но ущущение есть)
Контент годный, но хотелось бы детальный анализ кода и без ереси типа заменить reduce на простой цикл чтобы джунам тоже было понятно. Джуниор ничего не поймет и с циклом в этом коде, поскольку это библиотечный код, который пишется немного иначе чем прикладной код.
Ну а теперь ждем что-то про mobx :) Сам я отошел от фронта пробовал и то и то, в целом мне все эти вещи показались сложными, но не такими, что нереально разобраться. Ушел обратно на бек ))
Скажи ты можешь сказать что ты занят своим делом и это твое предназначение? Просто зная что ты этим занимаешься так долго и это твое то ты счастливый человек. Мне 30 и я не знаю чем мне занятся в жизни. Это грусть я ощущаю уже 10 лет
а теперь представь себя человеком, который работает менеджером где бы то ни было, представь его ежедневные рабочие будни, его звонки клиентам, его общение со снабжением, с отделами финансов, с начальником, с директором, выезды на встречи, вылеты в командировки, всякое вот это вот всё и... его (*здесь громкость голоса понижается*) зарплаааатууууу.. ВСЁ ЕЩЕ ГРУСТИШЬ!!!? - А ну ТАСКИ выполнять!! быстро!!))))
Хотя, многие менеджеры зарабатывают в разы больше некоторых программистов, с этим не поспоришь и зачастую это так, но, достигнуть их уровня в принципе это тот же труд, что и стать профи в программировании, а точнее в ИТ сфере вообще
@@Michael_Sh Я тоже не вижу где тут что вызывает самого себя? Если записать тот же код без стрелочных функций то это будет выглядеть вот так. funcs.reduce(function (a,b) { return function (...args) { return a(b(...args)); } })
@@evsignevsign7528 а что по вашему делает reduce()? Может так будет нагляднее: function c(a, b){ return function(..args){ a(b(...args)); } funcs.reduce(c); если развернуть для 3-х функций будет: c(c(f1, f2), f3)
@@MakarenkoSasha при чем тут гугль? Я так понимаю, каждый автор сам настраивает то, как будет показываться реклама и насколько часто. Иначе не понятно, почему у одних авторов она через каждые 5 минут, а у других, бывает, что вообще в самом конце только, чтобы никому не мешала. Бывает, что только в начале ролика. Неужели это у Гугла такой разный подход? Что-то сомневаюсь.
7:05 Я считаю, что производительность таких функций должна стоять на первом месте. Я бы написал цикл. А информативность можно обеспечить комментариями. Еще я бы убедился с помощью тестов в высокой производительности такой конструкции как композиция, прежде чем активно ее применять.
Ещё одна проблема в твоей логике. Дело в том, что это бездарное говно в принципе не способно работать быстро. Это мёртвая концепция созданная идиотами. Поэтому абсолютно неважно что там будет - цикл или не цикл. Нету смысла думать о том, что у кого-то на тазе спойлер кривой.
@@rustonelove JavaScript очень мощный язык, его никак нельзя назвать говном. И производительность его в некоторых случаях лишь немного уступает C++. Просто нужно понимать как он работает и грамотно его использовать. Для чисто функционального программирования он явно не подходит.
@@Mike-hp3fh >JavaScript очень мощный язык Я его не называл говном. В сравнении с действительно мощным языком - он не мощный. Хотя такой язык всего один - это С++. А так в сравнении с другой скриптухой он не хуже. >И производительность его в некоторых случаях лишь немного уступает C++. У языка нету производительности. Это какие-то глупые критерии. А про "немного" - тебя обманули. >Для чисто функционального программирования он явно не подходит. Для него никакой язык неподходит. Это мертворождённая концепция.
@@rustonelove С++ нельзя сравнивать с JS, у них совершенно разные области применения, которые практически не пересекаются. С++ является строготипизированным, так что и в синтаксисе тоже его нельзя сравнивать с JS. >> У языка нету производительности У JS только одна платформа исполнения на сегодняшний день - это v8. Нет смысла рассматривать этот язык в отрыве от v8. Да и с многими другими языками ситуация такая же. >> А про "немного" - тебя обманули. Я тестировал все это сам. Когда я вижу на экране 300 млн операций в секунду в одном тесте (причем в бразере) или 2-4 такта в другом тесте (на NodeJS), я не могу сказать что это медленный язык. >> Для него никакой язык неподходит. Это мертворождённая концепция. На котором написан Slack, на котором я уже сейчас за 2 месяца написал довольно сложное приложение, которое может работать на Windows, Chrome OS, Mac. Причем оказалось так что WPF C# намного менее удобен для создания таких приложений, про Java я вообще молчу. На котором можно на коленке написать сайт, который установится как оффлайн приложение в один клик. Я считаю что ты просто не знаком с этим языком и твои взгляды на него сильно устарели.
@@Mike-hp3fh > С++ нельзя сравнивать с JS, у них совершенно разные области применения, которые практически не пересекаются. С++ является строготипизированным, так что и в синтаксисе тоже его нельзя сравнивать с JS. У тебя неверная методичка. Это js нельзя сравнивать с C++, потому как область его применения крайне ограничена. У С++ таких проблем нет. Область его применения ничем не ограничена. >У JS только одна платформа исполнения на сегодняшний день - это v8. Нет смысла рассматривать этот язык в отрыве от v8. Да и с многими другими языками ситуация такая же. У тебя опять поломалась методичка. v8 тут не причём. Проблема тут в том, что никогда в принципе не напишешь "быстрый код". И потому что не можешь и потому что даже если сможешь - тебе не позволит JS. В этом и разница между языками. >Я тестировал все это сам. Когда я вижу на экране 300 млн операций в секунду в одном тесте (причем в бразере) или 2-4 такта в другом тесте (на NodeJS), я не могу сказать что это медленный язык. Что ты там мог тестировать. Иди сюда: benchmarksgame-team.pages.debian.net/benchmarksgame/ и показывай. Я могу написать то, что в дерьме изваляет что угодно. Потому что 1) я могу, 2) мой язык может. Самое интересное, что даже если я возьму жабаскрипт - мало что изменится. Хотя о чём это я говорю. Ты там начал что-то говорить про v8. Вот у тебя проблема с методичкой. Рантайм жабаскрипта на v8 написан не на жабаскрипте. Почему? рантайм ноды написан не на жабаскрипте - почему? >На котором написан Slack, на котором я уже сейчас за 2 месяца написал довольно сложное приложение, которое может работать на Windows, Chrome OS, Mac. Ты мне электрон пытаешься заливать что-ли? Дак ты ещё и маздайская макака к тому же? Позор. К тому же какая разница что ты там написал? Ведь на самом деле ты ничего не писал. Тебя обманули. Ты взял хром состоящий из такого кол-во когда, которое все существующие веб-макаки не напишут за всю свою жизнь. Ты взял ОС, ты взял рантайм электрона. Ты взял миллион строк готовых говнолиб на жабаскрипте. Что ты там написал? Огрызки нелепые. Кстати, угадай почему существует электрон? А я тебе отвечу. Для того, чтобы к жабаскрипту прикрутить нативную часть. >Причем оказалось так что WPF C# намного менее удобен для создания таких приложений, про Java я вообще молчу. Уровень состоятельности так и прёт. >Я считаю что ты просто не знаком с этим языком и твои взгляды на него сильно устарели. Меня эти зелёные мамкины эксперты не перестают удивлять. Я знаком с этим языком куда больше чем ты, а так же в сравнении с моими представлениями именно твои устарели.
13:07 А еще эта строчка создает функцию, т.е. создает объект и кладет его в память. Это дополнительнеая нагрузка на процессор и сборщик мусора. За это я и не люблю функциональное программирование, слишком много неочевидных вещей негативно влияющих на производительность.
На самом деле там нет никакого функционального программирования. Не верь сектантам - они тебя обманывают. Это просто абстракции, причём не из мира fp. А проблемы с абстракциями у тебя есть только потому, что это скриптуха. Абстракции могут иметь нулевую стоимость.
@@rustonelove >> потому, что это скриптуха Это не скриптуха а динамически компилируемый язык. Т.е. инструмент который пишет программу за тебя. Я считаю что за такими языками будущее - которые сами позаботятся о высокой производительности, оставляя программисту время для творчества.
@@Mike-hp3fh >Это не скриптуха а динамически компилируемый язык. Это скриптуха. Компиляция ничего не значит, но и даже тут тебя обманули. То, что там есть jit - это не значит, что он компилируемый. >Т.е. инструмент который пишет программу за тебя. Это вообще какой-то набор слов. >Я считаю что за такими языками будущее - которые сами позаботятся о высокой производительности, оставляя программисту время для творчества. Ты явно ничего не знаешь ни о творчестве ни о производительности. Изучи тему. Хотя давай начни просто с аргументации. Обоснуй свои тезисы.
В последнее время как грибы после дождя поперли всякие школы и курсы по веб и мобильной разработке и в добавок ко всему еще и на ютубе куча материала, люди записывают туториалы по модным направлениям и фреймворкам. Мне не совсем это понятно. Вот вы, господин Soer, считаете что у вас очень большая зарплата? Вы хотите чтобы на ваше место 100 человек претендовало или вы может хотите на старости лет автобусным контролером пойти работать? Я понимаю что из 100 новичков 99 отсеются, но 1 пролезет и может оказаться толковее вас. И однажды вам могут сказать что в ваших услугах больше не нуждаются. К чему все эти вещания на широкую публику? Есть у вас профессия вот и работайте молча пока еще индусы с китайцами не подоспели.
Это как раз каррирование, т.е. функция от нескольких аргументов преобразовывается в набор функций от одной переменной, т.е. f = (a, b, c) => a + b + c; преобразовывается в fcur = a => b => c => a + b + c, таким образом, если к функции f аргументы применяются f(1,2,3), то к функции fcur аргументы применяются через fcur(1)(2)(3), т.е. fcur(1) возвращает функцию одного аргумента, которая возвращает функцию одного аргумента. Можно посмотреть на википедии подробности.
@@neshkeev Не совсем так. Каррирование подразумевает что функция к примеру с набором из трех аргументов, при вызове смотрит на количество аргументов и возвращает значение в зависимости от количества. Например при вызове f(1, 2) она вернет функцию которая принимает последний аргумент и возвращает итоговый результат, но при вызове f(1, 2, 3) она возвращает сразу готовый результат. Т.е. каррирование это вариативность аргументов при вызове. В коде из видео, это самая банальная последовательный вызовов с замыканием, которая никакого отношения к каррированию не имеет.
@@gr1ncher Я может быть Вас не понимаю, но если вы знакомы с Haskell, то можете заметить, что мой коментарий корректен. Каррирование - это не вариативность аргументов (не придумывайте, пожалуйста, определения, пользуйтесь общепринятыми, хотя бы из википедии), каррирование - это ПРОЦЕСС(функция curry в Haskell, например) преобразования функции многих аргументов к виду, где фукнция принимает аргументы по одному. Результатом процесса является каррированная функция, т.е. появляется вторая фукнция в дополнение к оригинальной. То что описали вы больше похоже на частично применную фукнцию, например, для функции f = (x, y, z) => x + y + z, частично примененная функция будет выглядеть f1 = (x, y) => z => x + y + z или f2 = x => (y, z) => x + y + z. Каррированая функция будет всегда выглядеть как f_curr = x => y => z => x + y + z, т.е. определяется функция одного агрумента, которая возвращает фукнцию одного аргумента и т.д. Таким образом каррированая функция является частным случаем частично примененной функции. То что Вы описываете похоже на то, что в Haskell принято по умолчанию: каждая функция является каррированной изначально, что является свойством lambda-исчисления (тело лямбды простирается вправо до конца).
@Danila Avdoshin, формально говоря да, но не принциально. Функцию, которая принимает 1 параметр и возвращает другую функцию, можно считать каррированной, в терминах ФП.
@@kookaburru Нет, любую функцию, которая принимает 1 аргумент и возвращает функцию, которая принимает больше одного аргумента можно считать частично примененной, а не каррированной, обязательное условие каррированния заключается в том, что аргументы нужно передавать по одному, сравните: f_part = x => (y, z) => x + y + z - частично применная, вызывается f_part(1)(2,3); f_curr = x => y => z => x + y + z - каррированная, вызывается f_curr(1)(2)(3), т.е. каждый раз, применяя один аргумент, возвращается функция одного аргумента.
Очень классный формат. Прошу, продолжайте в таком же духе
+++
Контент хороший, но код нужно сделать побольше. На мониторе смотреть еще терпимо, а на планшете плохо виден код. Продолжай в том же духе.
Ничего не понятно, но очень интересно)
Соер, я восхищен твоим умом и эрудицией! Спасибо за видео! Каждый раз смотрю с удовольствием.
4:24 -- есть прикладной код, а есть "фундаментальный". Ключевое отличие в том, что осмысленные имена для прикладного кода связаны с доменом, и поэтому должны быть длинными. А домен для фундаментального кода -- это собственна математика, которая также оперирует короткими именами. Это что касается compose(f1, f2 ...).
Что касается коротких имен типов, то для Дженериков -- это вполне принятая практика: называть "любой тип" одной буквой (максимум двумя). Обратите внимание, что когда идет декларация типов для store (github.com/reduxjs/redux/blob/master/src/types/store.ts), то имена типов уже удлиняются, а параметры типов (любые типы) по-прежнему остаются короткими.
Так, что если кто хочет, вполне может использовать исходники redux, как образец. Здесь нет антипаттернов.
>Так, что если кто хочет, вполне может использовать исходники redux, как образец. Здесь нет антипаттернов.
Проблема в том, что redux - один большой антипаттерн.
@@rustonelove ну это кому как ;) я люблю редакс -- он крут.
А если вы (обобщенно) не любите котиков, то, вероятно, вы просто не умеете их готовить )
@@dimitro.cardellini И чем же? Может тем, что это тормозной мусор? Может тем, что это тонны бойлерплейта? Может тем, что эта концепция попросту несостоятельна?
Если редакс как концепция моностора состоятельна, то зачем даже его адепты пытаются пилить моностор на куски?
Чисто архитектурно редакс сдох и признан несостоятельными всеми, даже его адептами. Почему я написал выше.
Да, у него ещё есть хайп и адепты. Они пытаются путём тысяч обёрток и костылей распиливать стор, писать обёртки над всякими его нелепыми кусками. Но это уже выглядит нелепо.
@@dimitro.cardellini К тому же, в основном 99% адептов этого говна просто жертвы хайпа и узкого кругозора. Они попросту не видели удобных, быстрых и архитектурно качественных решений. Сейчас подобные решения начинают хайпить и редакс всё более и более маргинализируется.
@@dimitro.cardellini Хотя может я не прав и вы мне сможете назвать его преимущества и объяснить то, почему хорошая концепция и архитектура полностью умножается на ноль даже самыми преданными адептами. Как так вышло?
Отличный формат! Спасибо!
Чувак ты задрот в програмировании - и я тоже))))Спасибо что все круто объяснил.Однозначно подписка и лайк.
11:26 - next будет оригинальным dispatch, только для последнего middleware в applyMiddleware, для остальных next будет ссылкой на предыдущий middleware.
С такими ясными умами и мир вокруг становится яснее. Спасибо! Интересен и сам предмет и ход мышления ведущего.
В точку!Лайкос однозначно!
Великолепно! Благодарю за урок! Прошу продолжения!
Отличный логотип. Молодец. Очень достойно. Вообще уважение. Умница.
И в правду интересно!
Дружище спасибо за твой труд. Продолжай рубрику!!! Очень интересная рубрика!!!
Формат действительно отличный, спасибо!
Спасибо большое! Очень познавательно.
Ого)) а я всегда думал, что у меня костыль в коде и так писать не хорошо, а оказывается, что это "функциональная композиция" и так делать нужно)) спасибо)) буду знать))
Благодарствую!
Да, Евгений, потому заходит, потому-что помогает осмыслить такое видео те моменты, которым я вот например даже и значения не придал бы. Ну функция ну и функция, ну принимает функцию параметром, если нужно я и сам могу написать, и потом начинаешь писать, писать много, а чем больше пишешь тем больше времени уходит, больше ошибок, а нужно как бы заставить машину работать а не пальцы, как-то проникнутся смыслом и идеологиями годными. Проблема в том что идеологий парадигм уже на столько много что не знаешь кому ж верить, упирается всё во время. Поэтому обзоры кода заходят и будут заходить. Можно например обзор вообще кучи даже какой-то сделать вообще говнокода какого-то и это тоже зайдёт не хуже, там тоже будет смысл
8:22 - там не используется рекурсивный подход. Там используется свёртка (reduce). На выходе мы получаем именно то, что заказывали.
Переполнение стека может произойти только если мы сами захотим "скомпозировать" достаточное большое число функций, но оно бы произошло и так, если бы мы просто руками написали аналогичную матрёшку.
Собственно, вот аналогичный код, только для чистого JS:
gist.github.com/DScheglov/45176f2bec9cc8bb818e07e4d8f5dd58
Случай для одной функции является избыточным, т.к. он полностью покрывается reduce. но вероятно сохранен для повішения производительности (reduce все же потребует несколько большего усилия, чем простая проверка.
Рекомендую прочитать про примитивную рекурсию на списках и ее связи со сверткой списков, например вот здесь - fprog.ru/2010/issue4/vitaly-bragilevsky-limits-of-folds-expressiveness/
@@S0ERDEVS Спасибо, с радостью почитаю. Но! Статья по ссылке как раз о том, что свертки -- это не рекурсии, а рекурсии -- это не свертки, но при этом одни могут быть заменены другими и наоборот ;) Собственно, замена рекурсии сверткой -- это один из способов уйти от рекурсии и связанной с ней проблемой переполнения стека (другой способ -- циклы, но этот способ "не разрешен" в ФП в виду "побочно-эффектно" природы циклов).
Речь в видео не шла о прямой рекурсии, под рекурсивным подходом я имел в виду обработку которая может быть выполнена в рамках
примитивной рекурсии на списках (в данном случае список функций), свертка списка - это всего лишь оператор примитивной рекурсии.
@@S0ERDEVS
Прочем статью до конца! )
Свертка была использована для определения оператора примитивно рекурсивных функций, заданных на
множестве списков, исключительно для того, чтобы показать, что примитивные рекурсии можно
заменить на свертку (это следует из того, то множество примитивных рекурсий замыкается по
оператору примитивной рекурсии).
Но! Из этого никак не слеудет, что свертка является рекурсией.
Хотя, Свертку также можно определить через рекурсию.
gist.github.com/DScheglov/c8c106b8c3e000cde8d723c94fe1ff08
(но очевидно, что итеративная модель будет более быстрой и безопасной с т.з. перепонления стека)
Я бы не стал ссылаться на теорию вычислимости под видео, где пытаюсь "на пальцах" рассказать, что такое функциональная композиция и редакс-мидлвары.
Это, конечно, характеризует меня не с лучшей стороны, но о примитивно рекурсивных функциях и теории вычислимости я узнал из Вашего комментария.
Думаю, что большинство зрителей данного видео с радостью опустят данное знания без ущерба для понимания самого видео.
В отношение "рекурсия" и "свертка" -- я бы остановился на том, что это неудачная оговорка или даже перевод слова "reduce".
Я перестал понимать со слов "итеративная модель". Термин "свертка" используется в функциональном программировании, итерирование не через рекурсивность в функциональном программировании - невозможно.
Если мы говорим про перевод слова reduce, то он действительно часто переводится как "свертка", но в JS это на самом деле синтаксический сахар над циклами, т.е. reduce в императивном языке программирования - это "скрытый" цикл.
Если мы говорим о моем видео то действительно можно было перевести слово reduce как свертка, но при этом функциональная композиция будет работать все так же рекурсивно и приводить к переполнению стека вызовов при использовании большого числа функций в композиции.
Поэтому согласиться, что рекурсивности здесь нет я не могу. То что здесь нет прямой или явной рекурсии я согласен, но об этом я сказал и в видео.
Очень интересно и даже понятно
отличный формат ролика, спасибо!
Годнота! Большое спасибо за видео
Супер формат!!! Продолжай!=)
шикародос
Моё почтение.
Супер объяснение, салют
4:20 -- так, собственно, кроме самого движка "redux", есть еще и redux-код: actionCreators, reducers, thunks, middlewares etc. и наличие в библиотеке compose очень помагает этот код писать.
Супер формат! продолжай, пжл
9:35 - SOLID отлично работает не только для Классов.
Open/Close -- необязательно требует наследования: композиция объектов предпочтительнее наследования.
Можно и через композицию (те же инъекции) но при этом нужно помнить что класс нельзя модифицировать. Т.е. прямое расширение композиции нарушает принцип.
@@S0ERDEVS нужно помнить, что без класса можно и вообще обойтись )
Прикольно, наверное)) Но мне пока рано. Поподробнее бы.. Но походу формат не для новичков
ДОБРЫЙ ДЕНЬ! НЕ МОГЛИ БЫ ВЫ ПОДСКАЗАТЬ ХОРОШИЕ ПЛАТНЫЕ КУРСЫ FRONT END С НУЛЯ? БЛИЗОК К ТОМУ, ЧТОБЫ КУПИТЬ КУРСЫ ВЕБ-РАЗРАБОТКИ НА GEEKBRAINS, НО Я ПОКА СОМНЕВАЮСЬ (ЦЕНА/КАЧЕСТВО). ЗАРАНЕЕ БЛАГОДАРЮ ЗА СОВЕТЫ
Оч полезно продолжай
кайфанул от полезности контента
Видео как всегда интересное
Анализ кода сайтв онлайн козино топ контент
от это годнота👍
спасибо
спасибо, интересно.
агонь
Лайк
Так каррирование или частичное применение?
Посоветуйте пожалуйста где можно почитать о правиле 0, 1 и бесконечность (5:25). Я довольно частенько сталкивался с аналогичным кодом и довольно часто приходилось его выпиливать из-за того что никаких оптимизация он не привносил (интерпретатор сам хорошо справлялся с тем чтобы срезать углы) и при этом вносит реализацию функции/метода лишние ветвления. В конкретном случае это действительно необходимо (скорее даже вынуждено) так как невозможно реализовать код так чтобы был только вариант с funcs.reduce.
Нагуглил Zero-One-Infinity Rule
не надо гуглить всё просто, в программировании есть или 0 или 1 или 1 и более, т.е. бесконечность.
т.е. если тебя просят добавить функцию/метод который на вход принимает один параметр, ты уточняешь, а точно ли будет только один, если да, то это один. И уточняешь, что параметра может не быть, то есть ноль. Дальше уточняешь, а может ли быть больше одного, тебе говорят, что может быть 2 или 3, ну максимум 5, но это по факту, значит, что нужно писать так, что максимума нет. Отсюда и 0, 1 или бесконечность.
Сойер где-то рассказывал кстати про какие-то принципы и там это упомянал
это я почти что частный случай привел, правильно про ZOI выше упомянули, там английским по белому в гугле написано :)
На самом деле даже в этом redux коде есть нарушения этого принципа, я там успел разглядеть метод принимающий (middleware1, middleware2, middleware3, middleware4, middleware5), в том же С# есть такие группы классов Tuple, Tuple...., Action, Action Func и т.д. Ограничения платформы даже на таком высоком уровне иногда заставляют городить вот такое))
топ
Круто лайк
Такая жесткая магия, а по факту она будет решать элементарную задачу. В итоге получится электронный молоток, чтобы удобно забивать гвозди. Сложно, понтово, и сыпаться будет на больших проектах. Как рельсы новые.
Вы могли бы делать увеличение транслируемого контента где-то до 150%? Это удобно смотреть и на компьютере, и на телефоне.
Я сейчас вынужден выключить видео, потому что не вижу на экране 5.2"
вот это интересно
4:54 -- длина имени никоим образом не зависит от области видимости ;) Только от домена, для которого пишется код. И если домен позволяет, то имя можно сделать коротким.
Домен это более высокий уровень абстракции. Для них локальных переменных не существует, так как "черный ящик"
@@S0ERDEVS
Здесь, наверное, небольшое недопонимание ) Думаю, надо просто пояснить, что я имел в виду:
домен -- это предметная область (просто русскоязычный термин очень длинный
Когда мы пишем код, мы всегда делаем это в рамках конкретной предметной области ...
Для compose - это функциональное программирование в общем смысле.
Для redux -- это управление состоянием.
8:20 Формально говоря, спецификация ES6 предполагает tail call optimization, который бы тут сработал, если бы хоть одна реализация, кроме Safari, была по спеке :D
Да я умоляю, мало кто читает спеку, а ты тут с хвостовой оптимизацией. Хотя штука полезная.
itpods - Айти Поц, канал в телеграм, где студент берет интервью у разработчиков из больших компаний.
6:24 -- свёртка -- это не рекурсия. Композиция -- это матрешка функций, и неважно, как мы ее делаем: руками или с помощью compose.
А вот, если заменить "матрешку" на цикл, то мы получим затраты на организацию и выполнение цикла по функциям при каждом вызове композитной функции. В таком же варианте, у нас цикл один: при создании композитной функции.
Кроме того, код, который будет итерировать функции на входе заметно больше, чем код, который итерирует их при создании композитной функции:
gist.github.com/DScheglov/e39e35f3966069ac54edc7a5ba5c4625
Ниже кидал ссылку примитивную рекурсию на списках и свертку просто повторю здесь fprog.ru/2010/issue4/vitaly-bragilevsky-limits-of-folds-expressiveness/
@@S0ERDEVS я уже отписался по этому случаю ;) Свертка может быть заменена на рекурсию. А статья по ссылке о том, что отдельные случае рекурсии могут быть заменения сверткой. Но! это два разных инструмента и путать их не следует.
Вот цитата из статьи по ссылке:
Свёртки - удобное средство обработки списков и других структур данных. Они позволяют записывать многие функции без явной рекурсии, а также упрощают формальное доказательство их корректности.
формат огненный
Здравствуйте, интересно было бы Ваше мнение. Поможет ли изучение языка Haskell (прохождение курса на Stepik.org) для понимания и дальнейшего использования функционального подхода в Javascript, Python?
Нет, очевидно. Никакого функционального подхода на js/пистон нет и быть не может. Он там и ненужен. Просто в веб набежали хомячки, воспользовавшись в целом низким уровнем квалификации рядового веб-адепта - убедили этих адептов в том, что где-то там есть ФП и оно состоятельно. На самом деле нет. От фп у тебя есть лишь пару названий.
А осознать уровень состоятельности ФП ты можешь через редакс. Это абсолютно несостоятельная, тормозная, убогая поделка. Который требует генерации тонн бойлерплейта. Это говно уже начало дохнуть. Как только адептам показали показатели другие подходы - они тут же поголовно побежали отсюда, ну у кого есть мозг и нету легаси-оков.
Что лучше thunk или saga?
1) Ден эту функцию compose не писал, прямо на скрине видно по списку коммитивших, что его там нет. Редакс сейчас делают вообще другие люди.
2) Однобуквенные переменные - плохо, даже если это дженерики. В твиттере постоянно эту тему поднимают видные люди из React-коммьюнити: twitter.com/kentcdodds/status/1083831867294441472
3) В функции compose нет рекурсии, там функции сами себя не вызывают.
1) Автор знает просто куда лизать. Лижи кто популярен - хомячки будут лайкать тебя.
2) Это не плохо. Отсылка на реакт-комьюнити - это очень слабо. Причин тому несколько. В сравнении с крестами всё это - ясли, либо вообще уровень бактерий. Там с этим никакой проблемы нет. Второе и самое важное - это то, что генерик не предполагает имени. Это общий тип. Если ты хочешь дать ему имя - ты делаешь что-то неправильно, потому как имя предполагает какое-либо ограничение на тип. А если тебе нужно ограничение - пиши его явно. Имя же это костыль.
Допустим, по твоей ссылке - её писал идиот. Это именно то о чём я говорил выше. Зачем автор написал DomElementType? Во-первых семантически итак ясно, что это типа. Но ладно. Это какие-то ограничения тайпскрипта, но это дыра. Потому как семантические это не DomElement. Правильно бы это писалось так: T extends DomElement и уже сразу понятно что это. Никакое имя менять ненужно. Тоже самое и с PropsType. Props - это уже тип - зачем адепт заново пишет, что это тип? Те, кто писали базовую версию - не настолько идиоты. Второе - семантически это не пропсы. Насколько я знаю в пропсах должен быть children. Поэтому это так же можно заменить на extends, т.е. ограничить тип.
Изначально это не написано, скорее всего, по очевидным причинам. Это ограничения уже существуют в RefForwardingComponent и постоянно их писать - лениво. Но если уж хочется "понятности" - пиши ограничения, а не идиотские имена.
3) Здесь автор просто пытается лизать и повторять все базворды, которые у него ассоциируются с ФП.
Отлично, но мало!
Та за шож нам такие испытания?!
Тоооочно Дэн Абрамов создал Редакс? Он вроде сам его критиковал.
Поправка: функция compose может использоваться при инициализации store, в middleware, а также для объединения редьюсеров низкоуровневых модулей.
Для объединения редьюсеров используется combineReducers. Она на вход принимает объект, а на выходе даёт сборный редьюсер. Это точно не композиция функций.
Soer, мне 18, учусь на первом прогерском курсе весьма неплохого универа. С программированием знаком с 15ти есть два больших проекта и 1.5 года опыта удаленной работы. Подскажи что делать: углубиться в математику(учебу в универе) или начать искать работу?
Ищи работу в только не формошлепом
тескт мелкий. справа треть экрана пустая. нажал ctrl + и увеличил масштаб.
Да, шрифт мелковат.
Хоть бы примеры кода приводили, написанием небольших кусочков кода. Если сравнивать как вы рассказываете, это объяснение инструкции пылесоса со своими мыслями. Просто вроде и хочется подписаться но когда смотрю, что после таких объяснений, ощущаю что меня укусил диванный аналитик (думаю вы не такой но ущущение есть)
Контент годный, но хотелось бы детальный анализ кода и без ереси типа заменить reduce на простой цикл чтобы джунам тоже было понятно. Джуниор ничего не поймет и с циклом в этом коде, поскольку это библиотечный код, который пишется немного иначе чем прикладной код.
Плюсую как java -ист.
Делай еще
Дружище, хоть я половину твоих слов не понимаю, но ты крут)
0 1 inf это следствие оборачивания по 2 функции за раз, а не что-то там мета
Разве это не простой синтаксический сахар?
Нихера не понятно, но очень интересно!
ждем разбор rxjs )
itpods - канал в Telegram, на котором разбираются структуры данных.
Лучший Инженер по Росии
Лучший Инженер по России
Soer, ты и data science и front и back разработчик, ты не выбрал что то одно?
Есть у него одна выбранная область, только вот он не ограничивается на ней, а развивается цельно. Широкий кругозор у человека.
Ну а теперь ждем что-то про mobx :)
Сам я отошел от фронта пробовал и то и то, в целом мне все эти вещи показались сложными, но не такими, что нереально разобраться.
Ушел обратно на бек ))
Поддерживаю, ну этот фронт нахер) на бэке спокойнее и стабильнее
Ого, мне казалось наоборот, на фронте все просто, а на беке уже сложности
@@АртемТерещенко-ц4э раньше было иначе, сейчас много логики переходит на фронт, а бэкэндщикам стало намного легче
@@SanchReload на митингах скажу им что бы не умничали тогда:)
инфа классная, но сложная
itpods - канал в Telegram, на котором вы увидите, как, что и где обычный студент учит программирование, чтобы попасть на первую работу.
Здравствуйте! Вы преподаете?
Очень толково! Благодарю.
5:15 -- нужно сокращать имена, но не в ущерб их информативности.
что у тебя с правым глазом он прикрыт, это от программирования приобретенное ? или так было
itpods - канал в Telegram, на котором решаются задачи с LeetCode
Привет душный дед, шо
Сделай реверс какой-нибудь малвари!!
Скажи ты можешь сказать что ты занят своим делом и это твое предназначение? Просто зная что ты этим занимаешься так долго и это твое то ты счастливый человек. Мне 30 и я не знаю чем мне занятся в жизни. Это грусть я ощущаю уже 10 лет
а теперь представь себя человеком, который работает менеджером где бы то ни было, представь его ежедневные рабочие будни, его звонки клиентам, его общение со снабжением, с отделами финансов, с начальником, с директором, выезды на встречи, вылеты в командировки, всякое вот это вот всё и... его (*здесь громкость голоса понижается*) зарплаааатууууу.. ВСЁ ЕЩЕ ГРУСТИШЬ!!!?
- А ну ТАСКИ выполнять!! быстро!!))))
Хотя, многие менеджеры зарабатывают в разы больше некоторых программистов, с этим не поспоришь и зачастую это так, но, достигнуть их уровня в принципе это тот же труд, что и стать профи в программировании, а точнее в ИТ сфере вообще
Абсолютно согласен. Лучше посадить зрение работая программистом чем сердечно сосудистую работая менеджером !
Редакс переписывается на Тайпскрипт, и ещё не дописан до конца, так как майнтейнеры пытаются избавиться от всех внешних зависимостей
На сколько я знаю, рекурсия это кода функция вызывает сама себя и прекращается при определённом условии. Где вы это в compose увидели?
В return она вызывает сама себя. В последнем.
@@Michael_Sh Я тоже не вижу где тут что вызывает самого себя? Если записать тот же код без стрелочных функций то это будет выглядеть вот так.
funcs.reduce(function (a,b) {
return function (...args) {
return a(b(...args));
}
})
@@evsignevsign7528 а что по вашему делает reduce()?
Может так будет нагляднее:
function c(a, b){ return function(..args){ a(b(...args)); }
funcs.reduce(c);
если развернуть для 3-х функций будет:
c(c(f1, f2), f3)
Ребята давайте уже ему нормальную работу найдём?
Ну и в чем он не прав?
itpods - канал в Telegram, на котором есть инфа, как написать чит на C++ для CS:GO
Рекламы по времени больше чем сам видос.
странно, у меня вообще нет рекламы. а вообще да.. гугль прихренел уже.
@@MakarenkoSasha при чем тут гугль? Я так понимаю, каждый автор сам настраивает то, как будет показываться реклама и насколько часто. Иначе не понятно, почему у одних авторов она через каждые 5 минут, а у других, бывает, что вообще в самом конце только, чтобы никому не мешала. Бывает, что только в начале ролика. Неужели это у Гугла такой разный подход? Что-то сомневаюсь.
7:05 Я считаю, что производительность таких функций должна стоять на первом месте. Я бы написал цикл. А информативность можно обеспечить комментариями. Еще я бы убедился с помощью тестов в высокой производительности такой конструкции как композиция, прежде чем активно ее применять.
Ещё одна проблема в твоей логике. Дело в том, что это бездарное говно в принципе не способно работать быстро. Это мёртвая концепция созданная идиотами. Поэтому абсолютно неважно что там будет - цикл или не цикл. Нету смысла думать о том, что у кого-то на тазе спойлер кривой.
@@rustonelove JavaScript очень мощный язык, его никак нельзя назвать говном. И производительность его в некоторых случаях лишь немного уступает C++. Просто нужно понимать как он работает и грамотно его использовать. Для чисто функционального программирования он явно не подходит.
@@Mike-hp3fh
>JavaScript очень мощный язык
Я его не называл говном. В сравнении с действительно мощным языком - он не мощный. Хотя такой язык всего один - это С++. А так в сравнении с другой скриптухой он не хуже.
>И производительность его в некоторых случаях лишь немного уступает C++.
У языка нету производительности. Это какие-то глупые критерии. А про "немного" - тебя обманули.
>Для чисто функционального программирования он явно не подходит.
Для него никакой язык неподходит. Это мертворождённая концепция.
@@rustonelove С++ нельзя сравнивать с JS, у них совершенно разные области применения, которые практически не пересекаются. С++ является строготипизированным, так что и в синтаксисе тоже его нельзя сравнивать с JS.
>> У языка нету производительности
У JS только одна платформа исполнения на сегодняшний день - это v8. Нет смысла рассматривать этот язык в отрыве от v8. Да и с многими другими языками ситуация такая же.
>> А про "немного" - тебя обманули.
Я тестировал все это сам. Когда я вижу на экране 300 млн операций в секунду в одном тесте (причем в бразере) или 2-4 такта в другом тесте (на NodeJS), я не могу сказать что это медленный язык.
>> Для него никакой язык неподходит. Это мертворождённая концепция.
На котором написан Slack, на котором я уже сейчас за 2 месяца написал довольно сложное приложение, которое может работать на Windows, Chrome OS, Mac. Причем оказалось так что WPF C# намного менее удобен для создания таких приложений, про Java я вообще молчу. На котором можно на коленке написать сайт, который установится как оффлайн приложение в один клик.
Я считаю что ты просто не знаком с этим языком и твои взгляды на него сильно устарели.
@@Mike-hp3fh
> С++ нельзя сравнивать с JS, у них совершенно разные области применения, которые практически не пересекаются. С++ является строготипизированным, так что и в синтаксисе тоже его нельзя сравнивать с JS.
У тебя неверная методичка. Это js нельзя сравнивать с C++, потому как область его применения крайне ограничена. У С++ таких проблем нет. Область его применения ничем не ограничена.
>У JS только одна платформа исполнения на сегодняшний день - это v8. Нет смысла рассматривать этот язык в отрыве от v8. Да и с многими другими языками ситуация такая же.
У тебя опять поломалась методичка. v8 тут не причём. Проблема тут в том, что никогда в принципе не напишешь "быстрый код". И потому что не можешь и потому что даже если сможешь - тебе не позволит JS. В этом и разница между языками.
>Я тестировал все это сам. Когда я вижу на экране 300 млн операций в секунду в одном тесте (причем в бразере) или 2-4 такта в другом тесте (на NodeJS), я не могу сказать что это медленный язык.
Что ты там мог тестировать. Иди сюда: benchmarksgame-team.pages.debian.net/benchmarksgame/ и показывай. Я могу написать то, что в дерьме изваляет что угодно. Потому что 1) я могу, 2) мой язык может.
Самое интересное, что даже если я возьму жабаскрипт - мало что изменится.
Хотя о чём это я говорю. Ты там начал что-то говорить про v8. Вот у тебя проблема с методичкой. Рантайм жабаскрипта на v8 написан не на жабаскрипте. Почему? рантайм ноды написан не на жабаскрипте - почему?
>На котором написан Slack, на котором я уже сейчас за 2 месяца написал довольно сложное приложение, которое может работать на Windows, Chrome OS, Mac.
Ты мне электрон пытаешься заливать что-ли? Дак ты ещё и маздайская макака к тому же? Позор. К тому же какая разница что ты там написал? Ведь на самом деле ты ничего не писал. Тебя обманули. Ты взял хром состоящий из такого кол-во когда, которое все существующие веб-макаки не напишут за всю свою жизнь. Ты взял ОС, ты взял рантайм электрона. Ты взял миллион строк готовых говнолиб на жабаскрипте. Что ты там написал? Огрызки нелепые.
Кстати, угадай почему существует электрон? А я тебе отвечу. Для того, чтобы к жабаскрипту прикрутить нативную часть.
>Причем оказалось так что WPF C# намного менее удобен для создания таких приложений, про Java я вообще молчу.
Уровень состоятельности так и прёт.
>Я считаю что ты просто не знаком с этим языком и твои взгляды на него сильно устарели.
Меня эти зелёные мамкины эксперты не перестают удивлять. Я знаком с этим языком куда больше чем ты, а так же в сравнении с моими представлениями именно твои устарели.
Ужас) я рад что я на js серьёзные вещи не пишу)))) такая магия мой страшный сон(. Рекурсию надо защищать счетчиками по хорошему.
очень плохо видно код, пожалейте глазки мамкиных программистов
отлично видно на 24 дюймах, можно и мельче, чот крупно ппц))
@@opalev на 15" тоже отлично видно, развёрнуто на пол экрана :)
13:07 А еще эта строчка создает функцию, т.е. создает объект и кладет его в память. Это дополнительнеая нагрузка на процессор и сборщик мусора. За это я и не люблю функциональное программирование, слишком много неочевидных вещей негативно влияющих на производительность.
На самом деле там нет никакого функционального программирования. Не верь сектантам - они тебя обманывают. Это просто абстракции, причём не из мира fp. А проблемы с абстракциями у тебя есть только потому, что это скриптуха. Абстракции могут иметь нулевую стоимость.
@@rustonelove >> потому, что это скриптуха
Это не скриптуха а динамически компилируемый язык. Т.е. инструмент который пишет программу за тебя. Я считаю что за такими языками будущее - которые сами позаботятся о высокой производительности, оставляя программисту время для творчества.
@@Mike-hp3fh
>Это не скриптуха а динамически компилируемый язык.
Это скриптуха. Компиляция ничего не значит, но и даже тут тебя обманули. То, что там есть jit - это не значит, что он компилируемый.
>Т.е. инструмент который пишет программу за тебя.
Это вообще какой-то набор слов.
>Я считаю что за такими языками будущее - которые сами позаботятся о высокой производительности, оставляя программисту время для творчества.
Ты явно ничего не знаешь ни о творчестве ни о производительности. Изучи тему. Хотя давай начни просто с аргументации. Обоснуй свои тезисы.
В последнее время как грибы после дождя поперли всякие школы и курсы по веб и мобильной разработке и в добавок ко всему еще и на ютубе куча материала, люди записывают туториалы по модным направлениям и фреймворкам. Мне не совсем это понятно. Вот вы, господин Soer, считаете что у вас очень большая зарплата? Вы хотите чтобы на ваше место 100 человек претендовало или вы может хотите на старости лет автобусным контролером пойти работать? Я понимаю что из 100 новичков 99 отсеются, но 1 пролезет и может оказаться толковее вас. И однажды вам могут сказать что в ваших услугах больше не нуждаются. К чему все эти вещания на широкую публику? Есть у вас профессия вот и работайте молча пока еще индусы с китайцами не подоспели.
Это же не каррирование
Каррирование -- это когда можно и через запятую аргументы передавать
Тут просто вложенные функции
Это как раз каррирование, т.е. функция от нескольких аргументов преобразовывается в набор функций от одной переменной, т.е. f = (a, b, c) => a + b + c; преобразовывается в fcur = a => b => c => a + b + c, таким образом, если к функции f аргументы применяются f(1,2,3), то к функции fcur аргументы применяются через fcur(1)(2)(3), т.е. fcur(1) возвращает функцию одного аргумента, которая возвращает функцию одного аргумента. Можно посмотреть на википедии подробности.
@@neshkeev Не совсем так. Каррирование подразумевает что функция к примеру с набором из трех аргументов, при вызове смотрит на количество аргументов и возвращает значение в зависимости от количества. Например при вызове f(1, 2) она вернет функцию которая принимает последний аргумент и возвращает итоговый результат, но при вызове f(1, 2, 3) она возвращает сразу готовый результат. Т.е. каррирование это вариативность аргументов при вызове. В коде из видео, это самая банальная последовательный вызовов с замыканием, которая никакого отношения к каррированию не имеет.
@@gr1ncher Я может быть Вас не понимаю, но если вы знакомы с Haskell, то можете заметить, что мой коментарий корректен. Каррирование - это не вариативность аргументов (не придумывайте, пожалуйста, определения, пользуйтесь общепринятыми, хотя бы из википедии), каррирование - это ПРОЦЕСС(функция curry в Haskell, например) преобразования функции многих аргументов к виду, где фукнция принимает аргументы по одному. Результатом процесса является каррированная функция, т.е. появляется вторая фукнция в дополнение к оригинальной. То что описали вы больше похоже на частично применную фукнцию, например, для функции f = (x, y, z) => x + y + z, частично примененная функция будет выглядеть f1 = (x, y) => z => x + y + z или f2 = x => (y, z) => x + y + z. Каррированая функция будет всегда выглядеть как f_curr = x => y => z => x + y + z, т.е. определяется функция одного агрумента, которая возвращает фукнцию одного аргумента и т.д. Таким образом каррированая функция является частным случаем частично примененной функции.
То что Вы описываете похоже на то, что в Haskell принято по умолчанию: каждая функция является каррированной изначально, что является свойством lambda-исчисления (тело лямбды простирается вправо до конца).
@Danila Avdoshin, формально говоря да, но не принциально. Функцию, которая принимает 1 параметр и возвращает другую функцию, можно считать каррированной, в терминах ФП.
@@kookaburru Нет, любую функцию, которая принимает 1 аргумент и возвращает функцию, которая принимает больше одного аргумента можно считать частично примененной, а не каррированной, обязательное условие каррированния заключается в том, что аргументы нужно передавать по одному, сравните: f_part = x => (y, z) => x + y + z - частично применная, вызывается f_part(1)(2,3); f_curr = x => y => z => x + y + z - каррированная, вызывается f_curr(1)(2)(3), т.е. каждый раз, применяя один аргумент, возвращается функция одного аргумента.
Все это конечно здорово но jScript как не пиши все равно куча мала получается в итоге
еще один жсом обкололся, кто вообще сказал что это язык программирования?
уважаемый, где можно увидить ваш анализ кода и принципов разработки?
В википедии написано
@@qdexy wiki рулит.
Ну а ты на чем пишешь?
@@bonumsignum7017 дело не в том на чем я пишу, дело в том, что не знаю ни одной норм проги на нативном жс. Может это только я не знаю...
itpods - канал в Telegram, на котором вы увидите, как, что и где обычный студент учит программирование, чтобы попасть на первую работу.