если достаточно долго писать на javascript то вообще перестаёшь доверять людям и начинаешь обрабатывать всё подряд, будто каждый хочет тебе подсунуть undefined
Предлагаю сделать видео, где Соер просто 15 минут будет быстро говорить умные слова, за Макконнела, белые/черные списки и стратегии "мусор на входе - мусор на выходе" и т.д. больше спасибо
Ну, в левой функции можно ексепшн обработать и отдавать тоже NaN. Например, сделать влежнную функцию реального рассчета факториала, которую вызывать с трай кетчем, где в кетч блоке результат делать NaN. Ну и тип параметра проверять, чтобы было подходящее число.
А что насчёт них? Они молодцы. Они делают то, что соер предлагает прописывать руками, а именно ограничивать функцию от данных, с которыми она не работает, добавляя полотна проверок. Так что с ними все ок. Т.е. если параметр функции был условно integer n, то при мусоре на входе было бы исключение. И все норм. 3 состояния результата работы функции: число, бесконечность (это вроде как тоже число в жсе, я хз), и экзепшен.
@@0imax ну это для данного примера подходит, а что если в агрументы передаётся класс, части которого могут быть некорректными и из-за этого не отработает дальнейшая логика?
может так еще лучше function factorial(n) { return fact(n); } function fact(n) { if (n === 0) return 1; return n * fact(n-1)); } таким образом мы уберем из рекурсии проверку (многократную) хоть белого хоть черного списка
Такой подход требует, чтобы во время рекурсивных вызовов входные данные оставались корректными, гарантии чего наш код не даёт. Например, при проверке "входное значение должно быть числом большим или равным единице" указанный код крашнется при n=1.2
Чтобы не создавать 2 глобальные функции лучше поступить так: function factorial(n) { if (!Number.isInteger(n)) { throw new TypeError('Variable n must be and integer type.'); } if (n < 0) { throw new RangeError('Variable n must be positive integer.'); } return (subf = (i) => { if (i === 0) return 1; return i * subf(i - 1); })(n); }
По хорошему факториал вычислять лучше через reduce в функциональном стиле. А если делать нечего и хочешь использовать рекурсий то пожалуйста, используй хвостовую рекурсию, чтобы не вызвать исключение переполнения стека.
Насколько я понял основная идея этого видео в том, что поведение функции должно быть детерминированным. И я с этим полностью согласен. Но примеры на JS лично для меня только добавляют путаницы. Я, признаюсь, плохо знаю JS. Видимо поэтому у меня осталось только больше вопросов, чем ясности: - я правильно понимаю, что в правой функции выбрасываются одинаковые ексепшены для разных инпутов? - Если ексепшены разные - то это мало отличается от левой функции, так как надо их все обработать. - Если они все одинаковые и сообщают о переполнении буфера - то, вроде бы лучше, но не совсем понятно, как это поможет вызывающему коду понять, что он передал неправильный аргумент? - И вообще, если, я увижу, что при передаче неверного аргумента в функцию она выбросила ексепшен, который говорит о том, что она пыталась выполнить свою логику с этим заведомо неверным типом аргумента, мне будет не по себе. Просто представьте, что функция не считает факториал, а обновляет состояние в базе данных, например.
правая функция вместо моментального выхода при отрицательном целом будет крутиться до переполнения стека. это что угодно, но не хороший код. можно было бы проверить тип, но динамикодебилы не догадаются. поэтому весь фронтенд в такой жопе, ждём переполнения стека
@@S0ERDEVS А на медленном компьютере? А если это происходит тысячу раз подряд? Тоже будет "так же моментально"? Что это вообще за больная логика: "компьютер быстрый, давайте делать лишние (!) действия, не писать же нам более аккуратный код в конце концов"? Поверить не могу, что приходится это объяснять серьёзному специалисту. Но, как я уже сказал, это объясняет, почему веб-страницы долго грузятся и медленно работают, а браузеру потреблять 2гб ОЗУ для отображения картинок и текста (!!) считается нормой. Печально, очень печально.
@Solitary Subscriber Поверить не могу, что для тебя нормальная ситуация - тысяча исключений подряд, в моей практике вероятность исключительной ситуации в 0.01% - это уже очень много, но даже в таком случае, если посчитать вероятность того что такие события произойдут 1000 раз подряд, то окажется, что это практически нереально (очень уж маленькая вероятность такой ситуации). Т.е. у тебя получается, что ради того чтобы сэкономить процессорное время 1 раз на миллиард вызовов (на самом деле даже больше, но считать точно не хочу), ты в каждом из этих вызовов готов делать доп проверку (которая не бесплатно выполняется). Вот поэтому и получаются медленные приложения, что пихаете в каждую функцию проверки, которых можно избежать, если перестать руководствоваться интуицией, а подучить тервер и посчитать реально насколько вероятно наступление события, ради которого вы вносите неопределенность и сложность в программу, убивая производительность в нормальном потоке выполнения. Еще раз подумай - речь идет не о нормальном потоке исполнения, а о исключительной ситуации, т.е. в нормальном потоке вообще не будут использоваться доп. ресурсы. В твоем же случае ты хочешь экономить ради редкого исключения, повышая нагрузку на нормальный поток.
Не поможет, если сам разработчик дундук и поставил условный any как тип. Тут надо понимать что и зачем, язык лишь даёт (или не даёт) инструменты для этого.
Хм, хоть я и питонист, тем не менее - интересная концепция, особенно при переполнении стека (хотя это будет сделать проблематично - скорее комп положишь...) Ну и отсюда понимание, что питонячий обработчик исключений - просто топчик
Оба примера - плохой код. Должна быть валидация входящих данный и должно выбрасывать ошибку, либо в крайнем случае 1 (в зависимости от задачи). Также должно быть преобразование типов - это же JS *!!! Левый код более правильный. Валидация слабая, но она есть! Надо просто сделать это лучше. Потому что потом , когда во время разработки будет пойман результат Exception, хотя по факту будет ожидаться выполнение, а не переполнение, потому что якобы должно поступать небольшое число на вход - вот тогда разработчик "хорошего кода" будет рвать последние волосы на мягкой точке, ища что же не так. Так для примера на 8:00 идёт рассуждение "либо результат, либо Exception". А на каком результате он будет наступать? На 20000, на 10486? А если комп и движок JS из будущего и потянет и даже 100 000 на расчёт? * данная функция из-за особенностей JS автоматически будет приводить всё в числа. Но "0" ноль, она не переварит! Что выдаст factorial("0")? А если математическая функция использует сложение?
Очень наивный подход, на практике так не делается, уже в следующем видео на примере redux показал, что боятся исключений не стоит, и умение проектировать как раз в том и заключается - не делать лишних проверок, пытаясь подстелить соломинку.
@@S0ERDEVS ага, а потом разгребать багрепорты от пользователей. Вот так джуны почитают вас, ещё и формы проверять не будут, потому что наивный подход на практике. У вас вероятно свой опыт умения проектирования, а на практике - чем больше вариантов учтёшь, чем больше проверок и тестов предусмотришь, тем проще будет поддерживать. Не придётся искать ошибки. И хорошо, если эта функция не жизненноважные. А то может со счёта уйти пару миллиончиков долларов и будешь всю жизнь отрабатывать.
@PostoiParovoz причем тут мой опыт? Открой любую публичную популярную библиотеку и посмотри как они написаны. Было бы желание, а информации на счет проектирования более чем достаточно. Если в коде куча проверок и явных приведений - это первый признак, что никто его не проектировал, а код написан по интуиции.
NaN есть во многих языках. Это результат вычисления к примеру 0/0 Это число, но не число при этом. Inf/-Inf тоже в любом языке есть, это число в типах с плавающей точкой. undefined фишка js. По сути аналог null, но не null так как у null есть своё отдельное значение в js. А исключение Exeption тоже есть во многих языках, к примеру Java, C# Откуда взялся NaN? Сначала функция вернула просто return; -> undefined. Потом undefined попытались математически умножить с числом и получили число "нечисло", то есть NaN.
На самом деле все довольно сложно. Если более комплексный кейс рассмотреть, допустим с парсингом Http - все будет не так уж и очевидно. А люди из команды еще тебе и скажут, что им лень обрабатывать исключения и потому твой код не должен их бросать. Ну и в итоге - все придет к тому, что у тебя все публичные функции будут выглядеть как-то так: IResult, а в контексте веба - всегда 200 и пусть тот кто получает результат - смотрит, все ли нормально.
По поводу лени обработки: пускай тогда просто делают пустой catch раз уж так лень. По мне, подход: "появилась проблема, выдай исключение и умри" в разы лучше мусора на выходе, потому что мусор может потом уйти очень далеко от источника, и источник уже можно и не найти.
@@liravesnovaya242 Да я сам так же считаю(относительно принципа fail-fast), но что поделать, я же не один в команде. Потому и сказал что в конечном итоге все сведется к IResult. Как по мне - тупое решение, потому что не дает до конца понять - что не так, но что поделать.
чтобы избежать переполнения стека: function sum(n, s = 0) { return (n) ? () => sum(n - 1, s + n) : s } function trampoline(fn) { return function (...args) { let res = fn.apply(null, args) while (typeof res === 'function') { res = res() } return res } } const num = 1000000 const trampSum = trampoline(sum) const res = trampSum(num) console.log(res)
А почему в правой функции не перехватить Exception и вернуть Nan ? И вообще если надо вернуть хорошо или плохо, то надо функции немногие варианты плохо и превратить в одно возвращаемое плохо!
Тут ещё нужно смотреть на ЯП. В golang, на котором в основном я пишу код, левый вариант лучше. При < 0 возвращается ошибка, которую необходимо обработать. При невалидных входных данных (< 0) функция уйдёт в бесконечную рекурсию.
Хм, здесь что-то очень специфичное относительно языка, что требует объяснения. Я не понял, как проверка на отрицательное число в итоге приводит к разным результатам в еще двух случаях?
Мне кажется, если уж дорабатывать левый код, то правильнее было бы бросить исключение в случае не валидных входных данных. это так же позволит разделять исключения "общие" и относящиеся к бизнес логике задачи.
Мне кажется, что вторая функция тоже плохая. Да, работать она будет предсказуемо, но каждый раз, когда на вход попадает что-то кроме целочисленного значения >= 0 ждать, когда переполнится стек - это так себе идея. С точки зрения производительности это очень плохо. И я не уверен, что она будет работать одинаково на разных ОС и разных архитектурах железа (я, как программист, вообще не должен об этом думать - лучше просто написать функцию так, чтобы: 1) никакого переполнения стека не происходило вообще никогда, 2) было не важно, на какой платформе это будет запускаться. Чтобы этого добиться, пред условием выхода из рекурсии (n === 0), нужно добавить проверку корректности входящих значений. Не уверен, что это корректный код на js, но будем считать, что это некий псевдокод: if (typeof n !== integer || n < 0) { throw new Exception('Invalid parameter'); } if (n
Стек на js это условности. Не надо путать со стеком на си. Переполнение стека в js безопасно в силу гарантий самого языка. Что касается производительности то преждевременная оптимизация - зло. В данном случае переполнение стека очень недорогое поведение. И не надо забывать что это исключительная ситуация, если в программе высокие шансы получить вместо данных мусор, то надо разбираться с дизайном системы в целом.
@@S0ERDEVS Ага, т. е., в данном случае можно считать, что сам язык делает эту проверку входящих значений. Ну да, тогда никакого смысла нет проверять самостоятельно и вторая функция вполне удовлетворительна.
Расскажи, пожалуйста, как бы ты построил SPA веб приложение, в котором много связей между отдельными компонентами (например чекбокс на одной странице должен менять состояние элементов на другой). Некоторые данные используются сразу несколькими компонентами. Или хотя бы подскажи, где можно почитать про решение конкретных архитектурных проблем.
Если некоторые данные используются разными компонентыми, то их можно хранить в виде стейта в общем компоненте прородителе, это если без всяких state management. По хорошему конечно же завести глобальное хранилище состояния приложения, например вышеупомянутый редакс, и из него получать конкретные курски стейта в разных компонентах. "например чекбокс на одной странице должен менять состояние элементов на другой". Это штуку тоже можно редаксом решить, просто изменения состояния чекбокса должно запускать определенный actionCreator, который будет менять глобальное состояние, от которого и будет зависеть тот самый компонент, который вы хотите менять чек боксом, и не важно в каком месте, потому что как только тот кусок состояния в редаксе, от которого он зависит, изменится, он автоматически перерисуется. Так же черед редаксовские actionCreator's можно отправлять ассинхронные запросы на сервер, если подключить redux-thunk, что тоже добавляет удобства. Чтобы понять что к чему в редаксе потребуется определенное время и пытливость ума, но если есть время и желание, то это решение должно вам помочь.
А почему просто не выбрасить исключения вместо оператора return? Очевидно же, что программист хотел избежать ненужных операций, которые приводили бы к ошибке "Maximum call stack size exceeded", но выбрал неудобный путь.
Не думаю что я - джун. Я никто вообще... Но что, зачем, как и почему - мне понятно. Думаю тут в принципе ничего такого нет. Ну разве что гуманитарий запутается...
а че бы не проверить тип параметра? явное лучше, чем неявное. в правой функции отсутствие побочных эффектов достигается за счёт того, что нет условия ‘n < 1’. всем программистам в команде нужно знать и держать в голове, что доп проверка приводит к сайд-эффектам.
Еще один интересный метод реализации - через построение бесконечного списка - обращение к нему производится только по индексу поэтому получается "мусор на входе - исключение на выходе". Пример на Haskell: factorial = scanl (*) 1 [1..] :t factorial -- Тип списка: factorial :: [Integer] factorial !! (-1) -- Обращение к списку: *** Exception: Prelude.!!: negative index factorial !! 3 -- 6 factorial !! 300 -- Большое число не буду сюда копировать. factorial !! 30000 -- Очень большое число.
расскажи лучше как реализовать стратегию мусор на входе - оффер на выходе. да всем (кроме интервьюеров на техническом собесе) похер какую стратегию реализует кусок говнокода на жабаскрипте. потому что уже при разработке самого интерпретатора жабаскрипта изрядно наговнокодили. С нетерпением жду следующего выпуска: как писать расово правильный код на встроенном в микрософ офис висуал барсике.
Стратегия 2 интересна, но также не до конца понятно какое должно быть поведение в месте где вызывается функция, тогда в таком месте должен быть try/catch.
он очень быстро кончается в жабаскрипте. можно в браузере проверить, падает почти мгновенно. там просто ограничение на глубину вызова стоит, оно не ждёт фактического окончания памяти
@@Poloskun4ik ну это классика же, когда начинают рассказывать про программирование в быдловузе и вместо конкретных кусков кода показывают непонятный факториал если быть точнее, то факториал это классика примера рекурсии типа показать, что функция может вызвать сама себя но за столько десятилетий никто не додумался придумать боле менее наглядный пример рекурсии нежели вычисление бесполезного ряда чисел а я таки один раз использовал рекурсию, что упросило и сократило мой код аж в 3 раза по визуальному объему я аж сам с себя нереально проперся
Это особенность джаваскрипта, который может вернуть что угодно, а для ошибки у него аж четыре значения, включая null, которые могли бы быть чем-то одним, если бы было различие между значением переменной и состоянием программы. Null и Error можно понять зачем. Но NaN? Немогу сделть, и у меня для этого есть специальное слово. Переменной не присвоено значение, и для этого вот еще одно слово. Null это значение переменной, нет никакой ошибки. Лол.
Меня бы начальник убил бы нахер, если бы я сидел и перебирал все возможные некорректные значения подобных функций. Инвестор деньги немножечко не для этого выделяет всё же.
А потом я должен без обработки warning ни протестировать толком, ни ошибку найти , ни флага не увидеть что ситуация уже вышла где-то за край контроля , потому что никакой генерации warning incorrect incoming data в логах чтобы сразу понять где мина -- не будет в принципе . Считаю обе функции незаконченными в аспекте логики и рациональности именно применения как функции .
Название видео не соответствует его содержимому. Хороший код - это про правильные имена переменных, форматирование, грамотную архитектуру, принципы SOLID и т. д. А тут просто разбор ошибок в функции.
Максимально глупый пример. Кто будет делать в рекурсии две ветки if? Ещё и не использовать хвостовую рекурсию позволяя получать исключения переполнения стека. Просто зачем? Ведь все знают про хвостовые рекурсии, это уже стандарт.
Если использовать нормальный язык программирования, например java, то этой ерунды не будет, из-за типизации. Разве что выше надо будет проверить что там не отрицательный int или null, если большой integer. А так вам приходится самим компилятором быть.
С удовольствием посмотрю твои видосы про технологию разработки, когда ты наконец-то поставишь WSL и VSCode, и закончишь пересказывать документацию на язык.
@@S0ERDEVS ахаха, чел, зайди на канал и посмотри про wsl, ты опять выдал что-то неадекватное. Мои ученики давно его поставили и забыли. У тебя не получилось? :D
@@S0ERDEVS я продаю свои знания за деньги, а ты так и не понял как написать рекурсию) такой трэш нес про функции, про JS, про стэк, ахаха разберись с базой, чел.
Обязательно посмотрю это видео, когда мне понадобится знание факториалов. К сожалению, их не было в моей школьной программе (закончил в 2004), и во вступительных тоже, и даже на выш мате первых двух лет института по экономической специальности. И я ни разу не слышал об их практическом применении и не сталкивался с ними вообще. Я даже не знаю, что это такое - факториал.
Факториал - произведение ряда натуральных чисел от 1 до n. Это не сложная штука и еë часто используют для, например, демонстрации разницы между рекурсивными функциями и циклических алгоритмов.
@@ДмитрийУшаков-л6ж, спасибо, конечно. Но смысл моего комментарий был в том, что мне это знание не требуется для решения задач бизнеса, за которые мне платят(разработка серверной части мобильных приложений).
@@vetalmontolio8075, согласен. Но тяжело воспринимать информацию, когда в примере используется что-то, о чем ты не знаешь. Это примерно также, как учить слова иностранного языка, используя не их перевод, а их значения на другом иностранном языке.
Вот это контент. Вот это можно пощупать. Больше бы таких практических наглядных ситуаций, больше разборов!
Никогда не рассматривал такие примеры с факториалом с такой стороны... Вроде пример банальный, а тонкостей оказывается очень много. Спасибо!
Хвостовые рекурсии наши друзья
А исключения переполнения стека - признаки плохого программиста
вывод - языки без строгой типизации позволяют ломать себе ногу передавая обьект туда куда надо передавать uint
В таких языках надо делать проверку и типизацию (валидацию) внутри функции.
а что скажешь насчет ассемблера?
@@anotherone3641 ассемблер это лучший способ сломать себе все что возможно))
если достаточно долго писать на javascript то вообще перестаёшь доверять людям и начинаешь обрабатывать всё подряд, будто каждый хочет тебе подсунуть undefined
😂😂
Жаль, что в жс не придумали тайп хинтинг.
Хорошо, что для жс придумали тайпскрипт.
Название видео не соответствует содержанию. Надо было назвать "Страдания JS разработчиков")
Истинно
Из этого ролика я узнал в каком стиле я проектирую и пишу все свои функции - мусор на входе, мусор на выходе :peepo_cry:
да и сам код тоже мусор XD
@@nazarii.lazarchuk мусор внутри 😉
😂
Благодарность. На редкость много полезного, на одну квадратную минуту видео.
Никто не пишет рекурсии вызывающие переполнение стека. Это ужасный код.
Юзаем хвостовые рекурсии вместо этого
Обожаю такие выпуски! Всегда есть о чем погуглить и чему поучится после!
а в языках с нормальной типизацией такого не произойдет, стоял бы тип uint во входных данных, и сразу отлетели бы некорректные данные на входе
TS в помощь
@@yaroslav8609 ts всё равно транслирует код в js и выполняться код будет в js.
Максимум чем ts может помочь - это дать подсказки до запуска кода.
Предлагаю сделать видео, где Соер просто 15 минут будет быстро говорить умные слова, за Макконнела, белые/черные списки и стратегии "мусор на входе - мусор на выходе" и т.д. больше спасибо
"мусор на входе - мусор на выходе"
мое кредо
Отличный ролик! Я ещё больше полюбил TypeScript)
Ну, в левой функции можно ексепшн обработать и отдавать тоже NaN.
Например, сделать влежнную функцию реального рассчета факториала, которую вызывать с трай кетчем, где в кетч блоке результат делать NaN.
Ну и тип параметра проверять, чтобы было подходящее число.
Блин, я не программист, но автор канала так четко и понятно рассказывает, что даже мне абсолютно все понятно. Респект!
скоро тебя осенит, что ты оказывается и программировать можеш
бросиш свою унылую работу, возьмеш нотыбук и поедеш в тайланд фрилансить под пальмами
Было очень полезно. Больше таких обучающих роликов. Спасибо🙃
Если идти по пути проверок, я б эту функцию завернул в ещё одну функцию, где бы и разместил проверки. Чтоб ещё и рекурсивно их не повторять.
Классическое GIGO - garbage in, garbage out. Наглядно
А что на счёт языков со статической типизацией?
А что насчёт них?
Они молодцы.
Они делают то, что соер предлагает прописывать руками, а именно ограничивать функцию от данных, с которыми она не работает, добавляя полотна проверок.
Так что с ними все ок.
Т.е. если параметр функции был условно integer n, то при мусоре на входе было бы исключение.
И все норм. 3 состояния результата работы функции: число, бесконечность (это вроде как тоже число в жсе, я хз), и экзепшен.
@@dasauser uint
@@dasauser а что на счёт проверки x
@@Algok17 unsigned int - и число всегда будет неотрицательным.
@@0imax ну это для данного примера подходит, а что если в агрументы передаётся класс, части которого могут быть некорректными и из-за этого не отработает дальнейшая логика?
может так еще лучше
function factorial(n)
{
return fact(n);
}
function fact(n)
{
if (n === 0) return 1;
return n * fact(n-1));
}
таким образом мы уберем из рекурсии проверку (многократную) хоть белого хоть черного списка
Такой подход требует, чтобы во время рекурсивных вызовов входные данные оставались корректными, гарантии чего наш код не даёт. Например, при проверке "входное значение должно быть числом большим или равным единице" указанный код крашнется при n=1.2
Да, но у нас вместо одной функции теперь две, что не очень красиво
@@enkryp
Чтобы не создавать 2 глобальные функции лучше поступить так:
function factorial(n) {
if (!Number.isInteger(n)) {
throw new TypeError('Variable n must be and integer type.');
}
if (n < 0) {
throw new RangeError('Variable n must be positive integer.');
}
return (subf = (i) => {
if (i === 0) return 1;
return i * subf(i - 1);
})(n);
}
По хорошему факториал вычислять лучше через reduce в функциональном стиле.
А если делать нечего и хочешь использовать рекурсий то пожалуйста, используй хвостовую рекурсию, чтобы не вызвать исключение переполнения стека.
Насколько я понял основная идея этого видео в том, что поведение функции должно быть детерминированным. И я с этим полностью согласен.
Но примеры на JS лично для меня только добавляют путаницы.
Я, признаюсь, плохо знаю JS. Видимо поэтому у меня осталось только больше вопросов, чем ясности:
- я правильно понимаю, что в правой функции выбрасываются одинаковые ексепшены для разных инпутов?
- Если ексепшены разные - то это мало отличается от левой функции, так как надо их все обработать.
- Если они все одинаковые и сообщают о переполнении буфера - то, вроде бы лучше, но не совсем понятно, как это поможет вызывающему коду понять, что он передал неправильный аргумент?
- И вообще, если, я увижу, что при передаче неверного аргумента в функцию она выбросила ексепшен, который говорит о том, что она пыталась выполнить свою логику с этим заведомо неверным типом аргумента, мне будет не по себе. Просто представьте, что функция не считает факториал, а обновляет состояние в базе данных, например.
правая функция вместо моментального выхода при отрицательном целом будет крутиться до переполнения стека. это что угодно, но не хороший код.
можно было бы проверить тип, но динамикодебилы не догадаются. поэтому весь фронтенд в такой жопе, ждём переполнения стека
На чем основывается утверждение? Переполнение стека в JS в данном случае произойдет для тебя так же моментально как и выход. Страх ради страха?
@@S0ERDEVS А на медленном компьютере? А если это происходит тысячу раз подряд? Тоже будет "так же моментально"?
Что это вообще за больная логика: "компьютер быстрый, давайте делать лишние (!) действия, не писать же нам более аккуратный код в конце концов"?
Поверить не могу, что приходится это объяснять серьёзному специалисту. Но, как я уже сказал, это объясняет, почему веб-страницы долго грузятся и медленно работают, а браузеру потреблять 2гб ОЗУ для отображения картинок и текста (!!) считается нормой. Печально, очень печально.
@Solitary Subscriber
Поверить не могу, что для тебя нормальная ситуация - тысяча исключений подряд, в моей практике вероятность исключительной ситуации в 0.01% - это уже очень много, но даже в таком случае, если посчитать вероятность того что такие события произойдут 1000 раз подряд, то окажется, что это практически нереально (очень уж маленькая вероятность такой ситуации).
Т.е. у тебя получается, что ради того чтобы сэкономить процессорное время 1 раз на миллиард вызовов (на самом деле даже больше, но считать точно не хочу), ты в каждом из этих вызовов готов делать доп проверку (которая не бесплатно выполняется).
Вот поэтому и получаются медленные приложения, что пихаете в каждую функцию проверки, которых можно избежать, если перестать руководствоваться интуицией, а подучить тервер и посчитать реально насколько вероятно наступление события, ради которого вы вносите неопределенность и сложность в программу, убивая производительность в нормальном потоке выполнения.
Еще раз подумай - речь идет не о нормальном потоке исполнения, а о исключительной ситуации, т.е. в нормальном потоке вообще не будут использоваться доп. ресурсы. В твоем же случае ты хочешь экономить ради редкого исключения, повышая нагрузку на нормальный поток.
@@S0ERDEVS просто язык гавно вот и всё
я 1 кто пытался поймать кадр на 07:12 и очень сильно разочаровался ???((((
А если не использовать рекурсию в данном примере, а применить цикл, как быстро произойдёт переполнение?..
TypeScript поможет избежать мусора на входе. Типизация + аннотация параметра функции.
Не поможет, если сам разработчик дундук и поставил условный any как тип.
Тут надо понимать что и зачем, язык лишь даёт (или не даёт) инструменты для этого.
@@robertdowneyjr8494 В таком случае поможет проверка в аннотации. Чтоб обойти, дундуку придется лезь в аннотацию и там ломать проверки.
@@azamatk4302 Вы не верите в могущество идиотизма? :)
Не во всех случаях, от микса эксепшенов, НаН и обычних чисел не защитит даже при правильной типизации.
особенно смешно этот комент выглядит, если вчитаться в повторение "избежать" )))
Жень, ударение такое "Сти́вен Макко́ннелл "
Хм, хоть я и питонист, тем не менее - интересная концепция, особенно при переполнении стека (хотя это будет сделать проблематично - скорее комп положишь...) Ну и отсюда понимание, что питонячий обработчик исключений - просто топчик
Не знаю, на си и c++ - изи, причём если не сталкивался с таким, то можно по первому разу сильно удивиться, когда делаешь какой-то итеративный расчёт.
Спасибо, за разбор. Очень познавательно
Оба примера - плохой код.
Должна быть валидация входящих данный и должно выбрасывать ошибку, либо в крайнем случае 1 (в зависимости от задачи).
Также должно быть преобразование типов - это же JS *!!!
Левый код более правильный. Валидация слабая, но она есть! Надо просто сделать это лучше.
Потому что потом , когда во время разработки будет пойман результат Exception, хотя по факту будет ожидаться выполнение, а не переполнение, потому что якобы должно поступать небольшое число на вход - вот тогда разработчик "хорошего кода" будет рвать последние волосы на мягкой точке, ища что же не так.
Так для примера на 8:00 идёт рассуждение "либо результат, либо Exception". А на каком результате он будет наступать? На 20000, на 10486? А если комп и движок JS из будущего и потянет и даже 100 000 на расчёт?
* данная функция из-за особенностей JS автоматически будет приводить всё в числа. Но "0" ноль, она не переварит! Что выдаст factorial("0")?
А если математическая функция использует сложение?
Очень наивный подход, на практике так не делается, уже в следующем видео на примере redux показал, что боятся исключений не стоит, и умение проектировать как раз в том и заключается - не делать лишних проверок, пытаясь подстелить соломинку.
@@S0ERDEVS ага, а потом разгребать багрепорты от пользователей. Вот так джуны почитают вас, ещё и формы проверять не будут, потому что наивный подход на практике.
У вас вероятно свой опыт умения проектирования, а на практике - чем больше вариантов учтёшь, чем больше проверок и тестов предусмотришь, тем проще будет поддерживать. Не придётся искать ошибки. И хорошо, если эта функция не жизненноважные. А то может со счёта уйти пару миллиончиков долларов и будешь всю жизнь отрабатывать.
@PostoiParovoz причем тут мой опыт? Открой любую публичную популярную библиотеку и посмотри как они написаны. Было бы желание, а информации на счет проектирования более чем достаточно. Если в коде куча проверок и явных приведений - это первый признак, что никто его не проектировал, а код написан по интуиции.
Код хороший. Код плохой. Код злой.
Образца 1966 года.
Из этого всего мы делаем вывод - js плох, ибо у него есть ничего, и другое ничего
NaN есть во многих языках. Это результат вычисления к примеру 0/0
Это число, но не число при этом.
Inf/-Inf тоже в любом языке есть, это число в типах с плавающей точкой.
undefined фишка js. По сути аналог null, но не null так как у null есть своё отдельное значение в js.
А исключение Exeption тоже есть во многих языках, к примеру Java, C#
Откуда взялся NaN? Сначала функция вернула просто return; -> undefined. Потом undefined попытались математически умножить с числом и получили число "нечисло", то есть NaN.
На самом деле все довольно сложно.
Если более комплексный кейс рассмотреть, допустим с парсингом Http - все будет не так уж и очевидно. А люди из команды еще тебе и скажут, что им лень обрабатывать исключения и потому твой код не должен их бросать. Ну и в итоге - все придет к тому, что у тебя все публичные функции будут выглядеть как-то так: IResult, а в контексте веба - всегда 200 и пусть тот кто получает результат - смотрит, все ли нормально.
По поводу лени обработки: пускай тогда просто делают пустой catch раз уж так лень. По мне, подход: "появилась проблема, выдай исключение и умри" в разы лучше мусора на выходе, потому что мусор может потом уйти очень далеко от источника, и источник уже можно и не найти.
@@liravesnovaya242 Да я сам так же считаю(относительно принципа fail-fast), но что поделать, я же не один в команде. Потому и сказал что в конечном итоге все сведется к IResult. Как по мне - тупое решение, потому что не дает до конца понять - что не так, но что поделать.
Почему не рассмотрено исправление левого кода с учетом белого списка и выброса исключения? Или это тоже плохой вариант, почему?
Не успел поставить лайк после завершения, но вернулся и поставил! Спасибо за разбор!
чтобы избежать переполнения стека:
function sum(n, s = 0) {
return (n) ? () => sum(n - 1, s + n) : s
}
function trampoline(fn) {
return function (...args) {
let res = fn.apply(null, args)
while (typeof res === 'function') {
res = res()
}
return res
}
}
const num = 1000000
const trampSum = trampoline(sum)
const res = trampSum(num)
console.log(res)
Когда пытаешься написать хороший код на плохом языке...
А почему в правой функции не перехватить Exception и вернуть Nan ? И вообще если надо вернуть хорошо или плохо, то надо функции немногие варианты плохо и превратить в одно возвращаемое плохо!
Тут ещё нужно смотреть на ЯП.
В golang, на котором в основном я пишу код, левый вариант лучше.
При < 0 возвращается ошибка, которую необходимо обработать. При невалидных входных данных (< 0) функция уйдёт в бесконечную рекурсию.
Я снова не досмотрел видео и написал комментарий.
Прошу прощения.
Хм, здесь что-то очень специфичное относительно языка, что требует объяснения. Я не понял, как проверка на отрицательное число в итоге приводит к разным результатам в еще двух случаях?
Мне кажется, если уж дорабатывать левый код, то правильнее было бы бросить исключение в случае не валидных входных данных. это так же позволит разделять исключения "общие" и относящиеся к бизнес логике задачи.
Услышав про мусор, ожидал услышать что-нибудь про контракты.
Хотя не знаю, есть ли какое-то подобие контрактов в JS.
Отличное видео, побольше бы таких.
Мне кажется, что вторая функция тоже плохая. Да, работать она будет предсказуемо, но каждый раз, когда на вход попадает что-то кроме целочисленного значения >= 0 ждать, когда переполнится стек - это так себе идея. С точки зрения производительности это очень плохо. И я не уверен, что она будет работать одинаково на разных ОС и разных архитектурах железа (я, как программист, вообще не должен об этом думать - лучше просто написать функцию так, чтобы: 1) никакого переполнения стека не происходило вообще никогда, 2) было не важно, на какой платформе это будет запускаться. Чтобы этого добиться, пред условием выхода из рекурсии (n === 0), нужно добавить проверку корректности входящих значений. Не уверен, что это корректный код на js, но будем считать, что это некий псевдокод:
if (typeof n !== integer || n < 0) {
throw new Exception('Invalid parameter');
}
if (n
Стек на js это условности. Не надо путать со стеком на си. Переполнение стека в js безопасно в силу гарантий самого языка.
Что касается производительности то преждевременная оптимизация - зло.
В данном случае переполнение стека очень недорогое поведение.
И не надо забывать что это исключительная ситуация, если в программе высокие шансы получить вместо данных мусор, то надо разбираться с дизайном системы в целом.
@@S0ERDEVS Ага, т. е., в данном случае можно считать, что сам язык делает эту проверку входящих значений. Ну да, тогда никакого смысла нет проверять самостоятельно и вторая функция вполне удовлетворительна.
@@S0ERDEVS Причем здесь JS к проверке стэка вызовов? не позорься))
Отличное видео. Побольше бы именно такого контента
Почему ты не продаешь курсы по JS? Разбогател бы, уехал жить на остров, может даже и на свой :)
Мудро и познавательно
Расскажи, пожалуйста, как бы ты построил SPA веб приложение, в котором много связей между отдельными компонентами (например чекбокс на одной странице должен менять состояние элементов на другой). Некоторые данные используются сразу несколькими компонентами. Или хотя бы подскажи, где можно почитать про решение конкретных архитектурных проблем.
Посмотрите в сторону архитектуры Flux и хранилищ типа NgXs/Redux
Если некоторые данные используются разными компонентыми, то их можно хранить в виде стейта в общем компоненте прородителе, это если без всяких state management. По хорошему конечно же завести глобальное хранилище состояния приложения, например вышеупомянутый редакс, и из него получать конкретные курски стейта в разных компонентах.
"например чекбокс на одной странице должен менять состояние элементов на другой". Это штуку тоже можно редаксом решить, просто изменения состояния чекбокса должно запускать определенный actionCreator, который будет менять глобальное состояние, от которого и будет зависеть тот самый компонент, который вы хотите менять чек боксом, и не важно в каком месте, потому что как только тот кусок состояния в редаксе, от которого он зависит, изменится, он автоматически перерисуется. Так же черед редаксовские actionCreator's можно отправлять ассинхронные запросы на сервер, если подключить redux-thunk, что тоже добавляет удобства. Чтобы понять что к чему в редаксе потребуется определенное время и пытливость ума, но если есть время и желание, то это решение должно вам помочь.
А почему просто не выбрасить исключения вместо оператора return? Очевидно же, что программист хотел избежать ненужных операций, которые приводили бы к ошибке "Maximum call stack size exceeded", но выбрал неудобный путь.
Спасибо!"!!!!!!!!!!!!!!
Посмотрел ролик и вспомнил, почему у меня горит от языков с динамической типизацией. Спасибо за видео.
Круто... Подписался
Джун: ничерта не понятно, но очень интересно 😂
Не думаю что я - джун. Я никто вообще... Но что, зачем, как и почему - мне понятно.
Думаю тут в принципе ничего такого нет. Ну разве что гуманитарий запутается...
@@covid-2284 гуманитарий. Не запутался :)
в java действительно нужно === поставить?)))
Спасибо за ролик!
А ещё будет?
не смотря дальше первой части видео, могу сказать, что правильным будет второй код, НО с добавленным типом
а че бы не проверить тип параметра? явное лучше, чем неявное. в правой функции отсутствие побочных эффектов достигается за счёт того, что нет условия ‘n < 1’. всем программистам в команде нужно знать и держать в голове, что доп проверка приводит к сайд-эффектам.
Спасибо, расширили сознание.
Еще один интересный метод реализации - через построение бесконечного списка - обращение к нему производится только по индексу поэтому получается "мусор на входе - исключение на выходе". Пример на Haskell:
factorial = scanl (*) 1 [1..]
:t factorial -- Тип списка: factorial :: [Integer]
factorial !! (-1) -- Обращение к списку: *** Exception: Prelude.!!: negative index
factorial !! 3 -- 6
factorial !! 300 -- Большое число не буду сюда копировать.
factorial !! 30000 -- Очень большое число.
расскажи лучше как реализовать стратегию мусор на входе - оффер на выходе.
да всем (кроме интервьюеров на техническом собесе) похер какую стратегию реализует кусок говнокода на жабаскрипте.
потому что уже при разработке самого интерпретатора жабаскрипта изрядно наговнокодили.
С нетерпением жду следующего выпуска: как писать расово правильный код на встроенном в микрософ офис висуал барсике.
Стратегия 2 интересна, но также не до конца понятно какое должно быть поведение в месте где вызывается функция, тогда в таком месте должен быть try/catch.
Конечно. Обе функции бездарные, с точки зрения JS.
Но этот приколист еще убрал проверку на отрицательный аргумент в надежде на exception.
Трэш.
«Мусор на входе, мусор на выходе» - полицейский участок
А я правильно понимаю, что правый вариант функции от -1 будет крутить рекурсию пока не кончится стек? Это тоже как то не слишком здорово выглядит.
он очень быстро кончается в жабаскрипте. можно в браузере проверить, падает почти мгновенно. там просто ограничение на глубину вызова стоит, оно не ждёт фактического окончания памяти
В этом и есть главная идея видео - для стандартного разработчика код справа выглядит некорректным, хотя в определённой перспективе он лучше левого.
@@enkryp Ну да, в этом смысле понятно, что правый вариант лучше. Просто они оба плохие)
А для чего вообще подобный кусок кода используется?
вычиляет факториал - бесполезный абстгактный пример из мудематики, когда хотят показать программирование
@@kalobyte да судя по комментам я тут один не понимаю всего праздника жизни)))
@@Poloskun4ik
ну это классика же, когда начинают рассказывать про программирование в быдловузе и вместо конкретных кусков кода показывают непонятный факториал
если быть точнее, то факториал это классика примера рекурсии
типа показать, что функция может вызвать сама себя
но за столько десятилетий никто не додумался придумать боле менее наглядный пример рекурсии нежели вычисление бесполезного ряда чисел
а я таки один раз использовал рекурсию, что упросило и сократило мой код аж в 3 раза по визуальному объему
я аж сам с себя нереально проперся
@@kalobyte ахахах, молодец
Смотрю , очень проявляется «синдром Одина» , это - хорошо )))
услышал про рекурсию - закрыл видео
О. Хорошо однако, элементарнейшие вещи но хорошо
Это особенность джаваскрипта, который может вернуть что угодно, а для ошибки у него аж четыре значения, включая null, которые могли бы быть чем-то одним, если бы было различие между значением переменной и состоянием программы. Null и Error можно понять зачем. Но NaN? Немогу сделть, и у меня для этого есть специальное слово. Переменной не присвоено значение, и для этого вот еще одно слово. Null это значение переменной, нет никакой ошибки. Лол.
Меня бы начальник убил бы нахер, если бы я сидел и перебирал все возможные некорректные значения подобных функций. Инвестор деньги немножечко не для этого выделяет всё же.
Спасибо!
Отличное видео!
А потом я должен без обработки warning ни протестировать толком, ни ошибку найти , ни флага не увидеть что ситуация уже вышла где-то за край контроля , потому что никакой генерации warning incorrect incoming data в логах чтобы сразу понять где мина -- не будет в принципе . Считаю обе функции незаконченными в аспекте логики и рациональности именно применения как функции .
спасибо
А ещё стратегию мусор на входе и мусор на выходе используют на футбольных стадионах
Java программистам не понять проблем Javaскриптизёров...
javascript на входе - мусор на выходе!
10461 -> максимальное число, с которым получаем Infinity, а не ловим исключение
Респект!
Сразу видно, автор видел много мусора на входе и на выходе. : )
if (n < 0) throw new IllegalArgumentException();
Главная ошибка что код написан на js
Название видео не соответствует его содержимому. Хороший код - это про правильные имена переменных, форматирование, грамотную архитектуру, принципы SOLID и т. д. А тут просто разбор ошибок в функции.
Судя по всему, вы пропустили (промотали) видео на 1:23-2:00
Да
Оба варианта ужасны .
Сяп чисто коммент для продвижения Ы
7:12
На самом деле все просто:
Хороший код - "_" в названии приватного поля
Плохой код - без "_"
Не путай!
Максимально глупый пример.
Кто будет делать в рекурсии две ветки if? Ещё и не использовать хвостовую рекурсию позволяя получать исключения переполнения стека.
Просто зачем? Ведь все знают про хвостовые рекурсии, это уже стандарт.
плохая демонстрация - на чёрном фоне.
Питонисты с обработкой явных исключений дико орут
тут все орут, кто хоть что-то знает))
+
Если использовать нормальный язык программирования, например java, то этой ерунды не будет, из-за типизации. Разве что выше надо будет проверить что там не отрицательный int или null, если большой integer. А так вам приходится самим компилятором быть.
а если использовать еще более нормальный язык, чем java, а именно kotlin, то и проверок на null не будет)
обе ф-ции говно, т.к. не прописан тип входящего параметра и тип выходящих данных
Красава. Это правильный ответ.
Либо сделать Number.parseInt / Number.parseFloat.
А тесты где?! Где тесты, Билли?!
Мдааааааа
С удовольствием посмотрю твои видосы про технологию разработки, когда ты наконец-то поставишь WSL и VSCode, и закончишь пересказывать документацию на язык.
Блин, так ты инфоцыган th-cam.com/video/lBnk-z04yWk/w-d-xo.html
@@S0ERDEVS ахаха, чел, зайди на канал и посмотри про wsl, ты опять выдал что-то неадекватное. Мои ученики давно его поставили и забыли. У тебя не получилось? :D
@@S0ERDEVS я продаю свои знания за деньги, а ты так и не понял как написать рекурсию) такой трэш нес про функции, про JS, про стэк, ахаха разберись с базой, чел.
@@S0ERDEVS можешь у меня купить курс, будешь шарить за стэк и рекурсию :D
Очень длинное видео.
Рыдая, с болью в душе, Я задаю всего лишь один вопрос - И ЧТО ТЕПЕРЬ ВСЁ ПЕРЕПИСЫВАТЬ? аааа!!! зачем Я Вас увидел? :) Спасибо!
Обязательно посмотрю это видео, когда мне понадобится знание факториалов. К сожалению, их не было в моей школьной программе (закончил в 2004), и во вступительных тоже, и даже на выш мате первых двух лет института по экономической специальности. И я ни разу не слышал об их практическом применении и не сталкивался с ними вообще. Я даже не знаю, что это такое - факториал.
Факториал часто встречается в комбинаторике
Видео не о факториале
Факториал - произведение ряда натуральных чисел от 1 до n. Это не сложная штука и еë часто используют для, например, демонстрации разницы между рекурсивными функциями и циклических алгоритмов.
@@ДмитрийУшаков-л6ж, спасибо, конечно. Но смысл моего комментарий был в том, что мне это знание не требуется для решения задач бизнеса, за которые мне платят(разработка серверной части мобильных приложений).
@@vetalmontolio8075, согласен. Но тяжело воспринимать информацию, когда в примере используется что-то, о чем ты не знаешь. Это примерно также, как учить слова иностранного языка, используя не их перевод, а их значения на другом иностранном языке.
Интересная стратегия: мусор на входе, мусор на выходе. Хмм, надо подумать о внедрении
Я уже пакеты с мусором поставил как делает автор) А если серьезно - очень полезное видео) Заставляет задуматься и понять, что мой код - го*но...
Паттерн стратегия - поменяйте алгоритм в процессе работы на мусорный...
Вообще-то мусор на входе, ошибка на выходе, хотя я тебя понял)
Мусор ломится в квартиру
Спасибо!