Как раз в Julia появился конвейер. Но если нет конвейера, то необязательно использовать пайтоновские матрешки: double(inc(double(double(5)))) - можно сделать же по-человечески: pipe(5) .double() .inc() .double() .double() И код можно читать как книгу сверху вниз, и параметр можно пропихнуть в оператор, и поддержка типов имеется для мэппинга, если ts использовать. Кстати, почему мы не можем назвать функцию чистой, если она возвращает случайное число? Возможно, что нам важно сохранить предсказуемость именно характеристик случайной величины.
Люди сами усложняют себе жизнь придумывая данные концепции. Каким образом человек должен разобраться в коде, где присутствуют тысячи деклараций функций. Таким образом в коде нет особого разграничения по объектам, все константы идут друг после друга.
@@gamerzero6085 разделить на файлики и папочки недостаточно, лично мне проще импорнуть класс в котором уже все находится, чем писать "импорт звездочка эс название".
Вполне справедливое замечание. Некоторые функции я бы не стал декомпозировать. Например, три условия в if через && вполне гармонично смотрятся. В целом, должен быть тимлид, который будет решать, насколько операция часто используемая и стоит ли выносить ее в отдельную функцию. И тогда уже выносить функцию в папку utils по конкретному направлению (чарджинг, дашборд, юзер и т.п.) или даже в общую папку utils.
Я прям влюбилась. Как можно так заинтересовывать предметом. Смотрела не отрываясь.
Лектор конечно офигенный. По-моему ему надо читать лекции не только по программированию, а ещё как правильно читать лекции.😀
Жаль этот лектор про gof and grasp enterprise patterns не рассказывает(
Как раз в Julia появился конвейер. Но если нет конвейера, то необязательно использовать пайтоновские матрешки: double(inc(double(double(5)))) - можно сделать же по-человечески:
pipe(5)
.double()
.inc()
.double()
.double()
И код можно читать как книгу сверху вниз, и параметр можно пропихнуть в оператор, и поддержка типов имеется для мэппинга, если ts использовать.
Кстати, почему мы не можем назвать функцию чистой, если она возвращает случайное число? Возможно, что нам важно сохранить предсказуемость именно характеристик случайной величины.
Как человек здорово, точно, лаконично и (!) приятно для восприятия излогает. Агонь! Жалко что я JS не увлекаюсь)
Практическая часть, это конечно отвал башки, спасибо, очень круто!
32:54 почему внутри функции partial => fn(...apply, args) нет спред оператора для args? (и в функции curry)
Я пришел к тому, что там ошибка. Перепутано, что нужно спредить. Должно быть: (...args) => fn(apply, ...args)
Ахренеть. Суперское видео! И все это бесплатно на ютубе. Институты безнадежно устарели, все знания можно получить онлайн.
Исходный код практической части заливали в открытый доступ? Было бы интересно руками потрогать и попрактиковаться!
Спасибо большое за вебы!)
1:00:12 начало практики
Как проводится отладка кода при написании в таком стиле?
С помощью логов, как она проводится в практически любом крупном веб проекте. Редко когда мне доводилось воспользоваться дебаггером в крупных проектах.
пример с createCounter это скорее не замыкание а фабрика в данном случае
Я и бал как круто)
Люди сами усложняют себе жизнь придумывая данные концепции. Каким образом человек должен разобраться в коде, где присутствуют тысячи деклараций функций. Таким образом в коде нет особого разграничения по объектам, все константы идут друг после друга.
Они распределены по модулям.
@@gamerzero6085 разделить на файлики и папочки недостаточно, лично мне проще импорнуть класс в котором уже все находится, чем писать "импорт звездочка эс название".
Вполне справедливое замечание. Некоторые функции я бы не стал декомпозировать. Например, три условия в if через && вполне гармонично смотрятся.
В целом, должен быть тимлид, который будет решать, насколько операция часто используемая и стоит ли выносить ее в отдельную функцию. И тогда уже выносить функцию в папку utils по конкретному направлению (чарджинг, дашборд, юзер и т.п.) или даже в общую папку utils.