Так как я купил, думаю, могу ответить. Это некий «ранний доступ», при котором книгу можно читать только в онлайне, только на сайте Питера. Она рендерится через Pdf.js, но с некоторой защитой, без возможности выделения и копирования. Полагаю, в этом и есть суть «раннего доступа», после старта продажи в бумаге откроют нормальный PDF [наверное].
Понятно, что перевод, но непонятно, зачем так все усложнять?..
yield используется для возврата значений промежуточных вычислений в функциях-генераторах.
Генератор - функция с хранимым состоянием. Генератор выполняется до следующего слова yield в коде, где выбрасывает рассчитанное значение значение наружу и "засыпает", ожидая следующего вызова, чтобы потом продолжить с прерванной точки. С помощью генератора можно реализовать поддежку [эффективных по помяти] бесконечных последовательностей, по типу ряда Фибоначчи или гармонических рядов. Генераторы также называют "сопрограммами".
С помощью генераторов реализуют протокол итерации, который используется для удобного обхода коллекций через стандартные механизмы языка (как правило, через цикл for). Поддержка протокола итераций реализована во многих языках, как то Python, JavaScript, C#, Rust.
Использование слова return в генераторе полностью останавливает его, после чего генератор нельзя уже будет пробудить повтрно.
Ну а потом уже можно и пример с большим массивом. А то прям какой-то детектив написан, о каких-то [мнимых] различиях совершенно разных конструкций - да еще и в стиле секрета Полишинеля...
Мой совет ограничить использование let (почти всегда) только функциональной областью видимости верхнего уровня означает, что в большинстве других объявлений должно использоваться ключевое слово let.
оригиналом является
My advice to reserve var for (mostly) only a top-level function scope means that most other declarations should use let. But you may still be wondering how to decide where each declaration in your program belongs?
То есть, первым идет как раз var...
Но должен сказать, что и из оригинала [лично мне] непонятно что подразумевается под "top-level function scope". То ли функции верхнего уровня, то ли самый верхний [блочный] уровень каждой функции. А может просто функции верхнего уровня, описанные как function expression, но через var чтобы работал hoisting? В общем, пока непонятно, зачем он пропогандирует продолжать использовать var, надо читать все подряд, чтобы понять контекст.
Мой совет ограничить использование let (почти всегда) только функциональной областью видимости верхнего уровня означает, что в большинстве других объявлений должно использоваться ключевое слово let.
Такое впечатление, что здесь опечатка, и на втором месте должно стоять const.
Беполезный ресурс с невероятно запутанным интерфейсом и отвратительным оформлением в стиле "кровь из глаз" вводит десяток новых функций чтобы... стать ещё более бесполезным?..
Львиная доля пользы от физических упражнений - это насыщение крови кислородом, с последующей рециркуляцией этой крови по тканям организма для питания / очищения. Следовательно, регулярные и умеренные занятия, где есть и кардио, и силовая часть, дадут максимальный эффект с точки зрения здоровья.
Методика, описанная вами, существует давным-давно, и известна под названием "изометрические упражнения" (т.е. статические силовые тренировки). Наиболее известный их представитель - русский силач Александр Иванович Засс, "Железный Самсон". Но он и сам отмечал, что подходить к такому типу тренировок надо осторожно, уже будучи предварительно тренированным. При статических тренировках особые требования предъявляются к сердцу, и если не тренировать кардио (бег, аэробика, скакалка, пр.), то можно с этим самым сердцем получить проблемы.
Так что занимаясь по 30 минут в неделю, наверное можно получить атлетично выглядящее тело. Главное при этом не испортить себе здоровье. Люди совсем не зря часами гирей машут.
К сожалению, с Перлом не знаком. Посему, нельзя ли дополнить статью описанием пользы таблицы применительно к Перлу, и несколько примеров использования? Чтобы можно было провести параллели, и если есть потенциальная польза, создать аналогичное для того, с чем стыкаюсь (JS / TS / Go / Rust). Спасибо!
Вряд ли стоит апеллировать к другим языкам, поскольку в разных экосистемах принято по-разному решать разные проблемы. К примеру, в некоторых языках есть опционалы, а в некоторых - перегружаемые операторы. Но вы почему-то не топите за их включение в JS, вам не нравится именно модульная система в JS.
Но ваш подход - вне сомнения - имеет полное право на жизнь (как и любой другой подход). Единственное, использовать его в проде - вряд ли обдуманное решение, поскольку такой код будет трудно ревьювить; плюс, если с проекта уйдут ключевые разработчики (т.е. вы и те кто знаком с подходом), то новоприбывшим будет очень трудно разобраться как все устроено.
Ну и простите моё любопытство, но вот, если мы к примеру пишем приложение в чисто функциональном стиле (функции высшего порядка, каррирование и декорирование функций, никаких классов) - то как в данном случае распространять зависимости (импортированные в DI контейнер) по приложению? Можно небольшой пример, или хотя бы концептуально на словах? Спасибо.
Но ваш опрос и правда звучит ультимативно. Возможный третий вариант — «Импорты допустимы при оправданной необходимости.» Что такое оправданная необходимость? Как видно уже из нескольких ваших статей и комментариев к ним, сообщество тяготеет к одному трактованию, вы — к кардинально отличному. Но при [оправданной] необходимости импорты все же используете.
Окей, но в точке (т.е. в модуле) где создается Card и принимается решение о том, какую имплементацию использовать - Fbi или Kgb - уже будет импорт трёх данных сущностей. Или мы должны пойти дальше, и импотировать все классы (а также функции, константы, внешние зависимости из npm-пакетов, svg на фронтенде и пр.) в некий клобальный entity-локатор, и оттуда раздавать по требованию?
А наличие в коде es6-модулей импортов конкретных имплементаций "убивают" принцип инверсии зависимостей.
Если импорт Fbi и Kgb будет внутри Card , то да. Но если в точке, где создается Card, то нет. Или вы предлагаете возвести инверсию в абсолют, и принимать решение обо всех деталях реализации на самом верхнет уровне - то есть, в конфигурации вне приложения, которая поключается к нему на лету во время запуска?
В таком случае будет нарушен основополагающий принцип инженерной деятельности - инкапсуляция. Не говоря уже о том, что понять как работает приложение, будет невозможно из-за динамичности абсолютно всех деталей.
Если хочется и действительно интересно, то можно освоить и в 75+, о чем я и написал в изначальном вопросе. Правда, в таком случае и руководства по тому, как "перейти в ИТ" не нужны, так как все происходит из интереса и очень естественно. Меня же интересовало другое, на что, собственно, ребята ответили, за что им спасибо.
схерали?
Не совсем понятен тон вашего посыла, в таком тоне цивилизованной дискуссии не получится.
Но по существу - если человек ранее разработкой не занимался, а прошел только пару курсов по программированию, выучил синтаксис ЯП и сделал несколько учебных проектов, то он может создать адекватную архитектуру программного проекта? Продумать контракты между слоями системы, подобрать оптимальные алгоритмы для решения более-менее сложных задач? (Ну то есть, сделать все то, что должен делать хороший разработчик.) Вы и правда так считаете?
Все-таки очень инересно было бы узнать, что двигает людьми и заствляет стать разработчиком в 35+ лет? Не только в этом конкретном случае, но и вообще.
Разработчик = инженер,
и чтобы стать [хорошим] разработчиком надо освоить инженерную деятельность, проектирование, дискретную математику, компьютер сайенс и пр.; и язык программирования в даном списке занимает лишь малую часть. Понятно, что когда это все интересно, то можно освоить и в 75+; но похоже, что все эти статьи успеха не для тех, кому просто "по кайфу".
Тут все просто. Синхронную логику мы заносим в Redux, асинхронную — в Thunk.
Уж если мы всё делим на слои, то логично, что всю бизнес-логику (и синхронную, и асинхронную) мы выносим в Thunk (или Saga), а в Redux оставляем только состояние. Либо же я совсем не понял ваш посыл…
Довольно слабая аргументация: весь упор идет на простоту и скорость разработки — но тут и Python ничем не уступит. Для прототипирования JS подойдет хорошо, да. А для конечного продукта, для устройств с ограниченными ресурсами лучше уж Rust выбрать — который в статье почему-то вообще не упомянут.
Не все, увы, понял при прочтении - уж простите, - из-за слишком витиеватого слога; но остался вопрос:
В чем собственно трудность? Вроде ж как в браузере есть встроенные инструменты обработки xml, на npm тоже немало пакетов. Или у вас какая-то очень специфическая задача?
Понятно, что перевод, но непонятно, зачем так все усложнять?..
yield используется для возврата значений промежуточных вычислений в функциях-генераторах.
Генератор - функция с хранимым состоянием. Генератор выполняется до следующего слова yield в коде, где выбрасывает рассчитанное значение значение наружу и "засыпает", ожидая следующего вызова, чтобы потом продолжить с прерванной точки. С помощью генератора можно реализовать поддежку [эффективных по помяти] бесконечных последовательностей, по типу ряда Фибоначчи или гармонических рядов. Генераторы также называют "сопрограммами".
С помощью генераторов реализуют протокол итерации, который используется для удобного обхода коллекций через стандартные механизмы языка (как правило, через цикл for). Поддержка протокола итераций реализована во многих языках, как то Python, JavaScript, C#, Rust.
Использование слова return в генераторе полностью останавливает его, после чего генератор нельзя уже будет пробудить повтрно.
Ну а потом уже можно и пример с большим массивом. А то прям какой-то детектив написан, о каких-то [мнимых] различиях совершенно разных конструкций - да еще и в стиле секрета Полишинеля...
Спасибо! Кстати, хороший пример реализации блокчейна (как бекенд, так и фронтенд части) есть в книге «TypeScript быстро».
Я нашел оригинал данного предложения - https://github.com/getify/You-Dont-Know-JS/blob/8861041133f496edce0d03885e2e998d50c3414a/scope-closures/ch6.md#where-to-let
Итак, для перевода
оригиналом является
То есть, первым идет как раз var...
Но должен сказать, что и из оригинала [лично мне] непонятно что подразумевается под "top-level function scope". То ли функции верхнего уровня, то ли самый верхний [блочный] уровень каждой функции. А может просто функции верхнего уровня, описанные как function expression, но через var чтобы работал hoisting? В общем, пока непонятно, зачем он пропогандирует продолжать использовать var, надо читать все подряд, чтобы понять контекст.
Такое впечатление, что здесь опечатка, и на втором месте должно стоять const.
P.S. Интересно, в книге тоже так?..
Беполезный ресурс с невероятно запутанным интерфейсом и отвратительным оформлением в стиле "кровь из глаз" вводит десяток новых функций чтобы... стать ещё более бесполезным?..
Львиная доля пользы от физических упражнений - это насыщение крови кислородом, с последующей рециркуляцией этой крови по тканям организма для питания / очищения. Следовательно, регулярные и умеренные занятия, где есть и кардио, и силовая часть, дадут максимальный эффект с точки зрения здоровья.
Методика, описанная вами, существует давным-давно, и известна под названием "изометрические упражнения" (т.е. статические силовые тренировки). Наиболее известный их представитель - русский силач Александр Иванович Засс, "Железный Самсон". Но он и сам отмечал, что подходить к такому типу тренировок надо осторожно, уже будучи предварительно тренированным. При статических тренировках особые требования предъявляются к сердцу, и если не тренировать кардио (бег, аэробика, скакалка, пр.), то можно с этим самым сердцем получить проблемы.
Так что занимаясь по 30 минут в неделю, наверное можно получить атлетично выглядящее тело. Главное при этом не испортить себе здоровье. Люди совсем не зря часами гирей машут.
К сожалению, с Перлом не знаком. Посему, нельзя ли дополнить статью описанием пользы таблицы применительно к Перлу, и несколько примеров использования? Чтобы можно было провести параллели, и если есть потенциальная польза, создать аналогичное для того, с чем стыкаюсь (JS / TS / Go / Rust). Спасибо!
Вряд ли стоит апеллировать к другим языкам, поскольку в разных экосистемах принято по-разному решать разные проблемы. К примеру, в некоторых языках есть опционалы, а в некоторых - перегружаемые операторы. Но вы почему-то не топите за их включение в JS, вам не нравится именно модульная система в JS.
Но ваш подход - вне сомнения - имеет полное право на жизнь (как и любой другой подход). Единственное, использовать его в проде - вряд ли обдуманное решение, поскольку такой код будет трудно ревьювить; плюс, если с проекта уйдут ключевые разработчики (т.е. вы и те кто знаком с подходом), то новоприбывшим будет очень трудно разобраться как все устроено.
Ну и простите моё любопытство, но вот, если мы к примеру пишем приложение в чисто функциональном стиле (функции высшего порядка, каррирование и декорирование функций, никаких классов) - то как в данном случае распространять зависимости (импортированные в DI контейнер) по приложению? Можно небольшой пример, или хотя бы концептуально на словах? Спасибо.
Окей, но в точке (т.е. в модуле) где создается
Cardи принимается решение о том, какую имплементацию использовать -FbiилиKgb- уже будет импорт трёх данных сущностей. Или мы должны пойти дальше, и импотировать все классы (а также функции, константы, внешние зависимости из npm-пакетов, svg на фронтенде и пр.) в некий клобальный entity-локатор, и оттуда раздавать по требованию?Если импорт
FbiиKgbбудет внутриCard, то да. Но если в точке, где создаетсяCard, то нет. Или вы предлагаете возвести инверсию в абсолют, и принимать решение обо всех деталях реализации на самом верхнет уровне - то есть, в конфигурации вне приложения, которая поключается к нему на лету во время запуска?В таком случае будет нарушен основополагающий принцип инженерной деятельности - инкапсуляция. Не говоря уже о том, что понять как работает приложение, будет невозможно из-за динамичности абсолютно всех деталей.
Если хочется и действительно интересно, то можно освоить и в 75+, о чем я и написал в изначальном вопросе. Правда, в таком случае и руководства по тому, как "перейти в ИТ" не нужны, так как все происходит из интереса и очень естественно. Меня же интересовало другое, на что, собственно, ребята ответили, за что им спасибо.
Не совсем понятен тон вашего посыла, в таком тоне цивилизованной дискуссии не получится.
Но по существу - если человек ранее разработкой не занимался, а прошел только пару курсов по программированию, выучил синтаксис ЯП и сделал несколько учебных проектов, то он может создать адекватную архитектуру программного проекта? Продумать контракты между слоями системы, подобрать оптимальные алгоритмы для решения более-менее сложных задач? (Ну то есть, сделать все то, что должен делать хороший разработчик.) Вы и правда так считаете?
Спасибо за статью!
Все-таки очень инересно было бы узнать, что двигает людьми и заствляет стать разработчиком в 35+ лет? Не только в этом конкретном случае, но и вообще.
Разработчик = инженер,
и чтобы стать [хорошим] разработчиком надо освоить инженерную деятельность, проектирование, дискретную математику, компьютер сайенс и пр.; и язык программирования в даном списке занимает лишь малую часть. Понятно, что когда это все интересно, то можно освоить и в 75+; но похоже, что все эти статьи успеха не для тех, кому просто "по кайфу".
Зачем? Неужели только из-за зарплаты в долларах?
Уж если мы всё делим на слои, то логично, что всю бизнес-логику (и синхронную, и асинхронную) мы выносим в Thunk (или Saga), а в Redux оставляем только состояние. Либо же я совсем не понял ваш посыл…