Вот только откуда они возьмутся, творцы эти? Обычно ведь как происходит. Скажем, интересно человеку заниматься художествами всякими. Он погружается в эту область, набивает руку, возможно, получает профильное образование. После этого, если он оказывается востребованным творцом, который не просто новые образы создавать может, но эти образы ещё и оказываются популярны у достаточного числа людей, то рождается знаменитость, звезда. Но если человек не попал в категорию звезды, то он становится "линейным" художником, который рисует всякие иллюстрации и прочий арт, обложки, логотипы там какие-нибудь, иконки к приложениям и т.п. Иными словами, он не оказывается лежащим в канаве неудачником, а имеет нишу, в которой может зарабатывать, принося посильную помощь обществу, и занимаясь приличным, возможно даже любимым делом. Уберите эту нишу, и дорога в искусство станет такой дикой лотереей, что родители начнут своим детям руки ломать, лишь бы те не шли в художники. Ну и разумеется, замените художника на музыканта или писателя - всё будет то же самое. Во всех творческих областях есть ниша для "линейных" специалистов, и не стоит смотреть пренебрежительно, ни на эту нишу, ни на тех, кто в ней занят. Это фундамент, на котором всё держится. Нельзя забраться на вершину горы, если горы нет.
Абсолютно верно. Все остальные "причины" - это просто предлог. Производительность у них, видите ли падает. Пора поднимать вопрос, чтобы время на дорогу от дома до работы и обратно считалось рабочим временем. Ведь оно тратится ради работы. Вот тогда и посмотрим что выгоднее, удалёнка или офис.
Коллапс случился не просто из-за того что электромобилей расплодилось много, а из-за морозов. В мороз электромобили хуже держат заряд, а зарядка занимает больше времени. Именно поэтому инфраструктура не справилась, и именно поэтому это случилось именно сейчас.
Вообще, вот если проводить аналогию с другими, известными мне языками, то обычно бывает 3 вида сущностей, отвечающих за параллельное выполнение: Process, Thread и Task. Терминология может отличаться, но суть та же. Task и Thread делят контекст с основным потоком, а Process это обособленная штука, которая работает в отдельном контексте (собственно, отдельно запущенный процесс). Task является более высокоуровневым по отношению к Thread. Task'и используют Thead'ы под капотом, через Thread Pool. В принципе, когда программист вручную работает с Thread'ами, он тоже должен использовать Thread Pool, если, конечно, хочет делать всё правильно. Да и вообще, по большому счёту, он должен делать всё то, что Task делает под капотом. Иными словами, если в вашем языке есть Task, то необходимость напрямую работать с Thread выглядит сомнительно. Может для каких-то случаев и нужно, тут спорить не возьмусь.
В JS я вижу порезанный Task (он же Promise), вижу Process (он же Worker), и совсем не вижу Thread. С одной стороны, как уже отмечалось выше, если есть Task, то Thread не особо-то и нужен. Проблема только в том, что Promise в JS является порезанной версией классического Task, т.к. два Promise'а не могут быть выполнены одновременно, что означает, что они и под капотом не используют никакие Thread'ы, и просто выполняются по очереди, в одном потоке. Собственно, в документации к ним так и написано. Именно это имеют в виду люди, когда говорят, что JS однопоточный. Несомненно, он может делать внешние вызовы, которые будут работать параллельно. Но сам JS код всегда работает в контексте одного главного потока. Ну, кроме Worker'ов, но они уже не потоки, а процессы.
Честно говоря, не знаю, даёт ли спецификация какие-либо указания на тот счёт, могут ли Promise'ы выполняться параллельно, но текущая реализация во всех известных средах выполнения этого не позволяет, и весь существующий код, написанный на данный момент, не рассчитан на то, что Promise'ы могли бы выполниться параллельно. Если в какой-то реализации такое сделают, то существующий код окажется несовместим с ней, т.к. в runtime посыпятся ошибки связанные с синхронизацией потоков, а точнее, с её полным отсутствием в существующем коде. Можно, конечно, добавить другой вид Promise'ов, и назвать их ParallelPromise (или Task, так будет короче). Но в этом случае, речь идёт уже о новой возможности, которая на данный момент просто отсутствует, как на уровне реализации, так и на уровне документации/спецификации. То есть, тут никак не получается притянуть за уши, что JS, дескать, многопоточный, это среды выполнения халтурят.
Что касается приведённых вами примеров XMLHttpRequest и crypto.pbkdf2, то интереснее было бы увидеть не замеры времени, а принципиальную возможность вызвать гонку за ресурсом, ну там, какое-нибудь падение при попытке одновременно добавить элемент в глобальный массив или премешанный вывод в консоль. А так, сдаётся мне, что только запрос выполняется параллельно, а обработчик события вызывается уже в главном потоке, в порядке очереди. Почему я так думаю? Да потому что я ни разу не видел ни мьютексов, ни критических секций, прочих видов блокировок в JS коде, и при этом всё работает, ничего не падает. Если бы обработчик onload у XMLHttpRequest вызывался в разных потоках, то было бы много веселья. В частности, console.log мог бы запросто перемешать несколько выводов и вывести вам один json внутри другого. Видел подобное неоднократно, только не в JS.
Из всего сказанного получается, что если давать классификацию, то JS однопоточный, асинхронный, многопроцессный язык. На мой взгляд, тому JS, что работает в браузерах, большего и не надо. С DOM, всё равно, не получится работать из нескольких потоков, и бедные фронтендеры только за зря будут страдать. Посмотрите на любой GUI фреймвёрк в любом ЯП, который поддерживает многопоточность, и вы поймёте о чём я говорю. Ни один из них не работает нормально с многопоточностью, и все они требуют обращаться к GUI из основного потока, иначе всё будет плохо. Именно поэтому, в JS и сделана асинхронность в одном потоке. А вот серверному JS параллельные Promise'ы не помешали бы. Но все серверные реализации эксплуатируют браузерные движки, и видимо там просто архитектурно не заложена такая функциональность, потому до сих пор и не добавили.
Ещё пример: стилус для сенсорных экранов. Перед покупкой вижу в карточке товара вес 20 г. Покупаю, приезжаю домой, замеряю на градуированных весах – 10 г. Я, конечно, понимаю, что разные весы имеют разную погрешность. Но как можно ошибиться в два раза?!
"Я на протяжении 10 лет покупаю спички Вашей фабрики и считаю количество спичек в коробке. Вы их кладёте то 59, то 60 штук, иногда 61, а вчера положили 56. Вы что там, совсем е**нутые?"
А разве это не является одним из условий доменно ключевой нормальной формы? Там, конечно, не только значения ENUM'ов, надо выносить в отдельные таблицы, а вообще допустимые значения любых пользовательских типов. Но сказать что оно никак не влияет уже нельзя.
Да ладно, No Man's Sky это шлак, даже после всех доработок. Собственно, доработок core механики там и не было. Понадобавляли кучу ненужных мелких активностей, а самое главное - генерация планет, как была одноклеточной, так и осталась. Условности торчат из всех щелей. Процедурная генерация настолько бросается в глаза, что убивает всю атмосферу. Например, опасных растений ровно два вида на каждой планете. Выглядят они, на всех планетах, абсолютно одинаково, отличаются только названием. Другой пример - спуститесь под землю, и вы увидите ровно три типа минералов, содержащих кобальт. Один тип минерала будет торчать с потолка пещеры, два других будут находиться на полу. Так будет на любой планете, словно это закон Вселенной. И снова, выглядеть они везде будут одинаково. В принципе, это касается любых минералов и растений в игре. Реально, есть некоторое, очень ограниченное количество типов, а потом они просто повторяются. Единственное, что будет уникальным - это их имена, которые являются случайно сгенерированными строками. Ну неужели нельзя было сделать менее топорно? Что нам пытаются продать под видом игры? Генератор случайных строк? Животные тоже не блещут разнообразием. Если визуально они ещё как-то отличаются друг от друга, то поведение у них очень однообразное, и на геймплей их разнообразие никак не влияют. Даже ресурс со всех падает одинаковый. Это множит всё разнообразие на ноль. Зачем так было делать, я вообще не понимаю. И так почти с каждым аспектом игры. Я уж не говорю о том, что на каждой планете ровно один климат и ровно одно погодное явление, которое ещё и происходит одновременно на всей планете. Да и климат, в общем-то, влияет только на визуальную составляющую и на то, какого цвета полоска защиты потребуется на этой планете. Никакой действительно уникальной механики, в зависимости от климата, нет. Ну то есть тупо, спасаться от холода, жары, токсинов или радиации нам предлагают одинаковым способом. А в чём тогда смысл разнообразия? В том что цветовой фильтр разный? Ну спасибо. Разнообразие снова помножено на ноль. Ни на одной из планет, вообще нет ничего уникального, и повторы начинают мозолить глаза уже после десятка часов игры. Игра предлагает быть исследователем, но какой в этом смысл, если найти что-то уникальное невозможно? Да и от планет там одно название. Это скорее фентезийные миры, а не планеты. Никакой планетной механики нет. Климат и тип планеты ничем не обоснованы, ни орбитой, ни типом звезды, ни вращением самой планеты. Кстати, о вращении планеты, продолжительность суток на всех планетах одинаковая. Рукалицо просто. А про продолжительность года там вообще говорить бессмысленно, ведь смены времён года, на планетах, просто нет. Всегда один сезон. Можно ли это вообще назвать планетами? Как по мне, это даже приблизительно не планеты. Обещали бесконечное множество планет, а не смогли сделать ни одной. Посмотрим что предложит беседка. На многое не рассчитываю, но у этих, даже если с механикой планет всё будет плохо, можно надеяться, что в остальных аспектах будет хорошая ролевая игра.
Один человек считает, что всё настолько плохо, что хуже и быть не может. Другой - считает, что может быть ещё хуже. Кто из них пессимист, а кто оптимист?
На мой взгляд, такое надо решать на уровне формата. Добавить формат а-ля Твиттер, для таких вот новостей, где информации на один заголовок. Если это цепочка событий, то можно группировать "твиты" по одной теме, формируя из них хронологию. Это будет удобнее как для написания, так и для отслеживания, чем то как сейчас делают одну статью, текст в которой дополняется со временем. А склеить потом всё в одну статью, можно вообще автоматически, если на то будет необходимость. Иными словами, каждое новостное агентство должно иметь раздел с твиттероподобным форматом. Новость всегда выгоднее опубликовать как можно раньше. А для полноценной статьи, даже если автор пишет молниеносно быстро, ещё надо собрать информацию, которая поступает не сразу. И Хабру стоило об этом подумать ещё в момент, когда они решили сделать раздел с новостями. Стандартный же формат Хабра для новостей не задумывался и больше подходит для глубоко анализа, ну или хотя бы, подробного изложения произошедших событий, который можно сделать только спустя значительное время.
помноженную на площадь Ленина (которую легко найти, взяв интеграл по поверхности).
Тут не всё так просто. Поскольку Ленин является радиоволной, то он обладает волновыми свойствами, и поэтому площадь Ленина может быть разной в зависимости от города, в котором вы её ищете. Если наблюдатель находится за пределами какого-либо города, то площадь Ленина находится в суперпозиции. Но стоит наблюдателю оказаться в городе, как волновая функция коллапсирует, и площадь Ленина приобретает конкретное значение.
Можно ли оставаться анонимным внутри государства, которое закрыло весь внешний Интернет?
Слово "анонимным", в этом вопросе, лишнее. И если вы видите для себя причины быть анонимным, то скорее всего, ответ - "нет". А если не видите, то ответ точно - "нет".
Надо правильно создавать аккаунт. Например, как Google так и Microsoft позволяют без всяких СМС зарегистрировать аккаунт, если создавать его как аккаунт для операционной системы, а не на сайте. Потом, правда, могут захотеть телефонный номер. Но написать несколько комментариев в ютубе вы вполне успеете, равно как и зарегистрировать что-то на эту почту. А спамерам большего и не надо, их аккаунты и так долго не живут.
Да чушь это очередная. Зачем мне NFT, подтверждающий владение часами, если у меня есть сами часы? Судя по описанию в статье, это что-то типа возможности зарегистрировать купленный продукт где-то на сайте. Во всяком случае, функциональный аналог данного действия. Купите, какой нибудь телевизор Samsung, и в инструкции к нему, вам точно так же предложат зарегистрировать эту покупку, чтобы потом получать спам эксклюзивные предложения на электронную почту.
Вот только откуда они возьмутся, творцы эти? Обычно ведь как происходит. Скажем, интересно человеку заниматься художествами всякими. Он погружается в эту область, набивает руку, возможно, получает профильное образование. После этого, если он оказывается востребованным творцом, который не просто новые образы создавать может, но эти образы ещё и оказываются популярны у достаточного числа людей, то рождается знаменитость, звезда. Но если человек не попал в категорию звезды, то он становится "линейным" художником, который рисует всякие иллюстрации и прочий арт, обложки, логотипы там какие-нибудь, иконки к приложениям и т.п. Иными словами, он не оказывается лежащим в канаве неудачником, а имеет нишу, в которой может зарабатывать, принося посильную помощь обществу, и занимаясь приличным, возможно даже любимым делом. Уберите эту нишу, и дорога в искусство станет такой дикой лотереей, что родители начнут своим детям руки ломать, лишь бы те не шли в художники. Ну и разумеется, замените художника на музыканта или писателя - всё будет то же самое. Во всех творческих областях есть ниша для "линейных" специалистов, и не стоит смотреть пренебрежительно, ни на эту нишу, ни на тех, кто в ней занят. Это фундамент, на котором всё держится. Нельзя забраться на вершину горы, если горы нет.
Абсолютно верно. Все остальные "причины" - это просто предлог. Производительность у них, видите ли падает. Пора поднимать вопрос, чтобы время на дорогу от дома до работы и обратно считалось рабочим временем. Ведь оно тратится ради работы. Вот тогда и посмотрим что выгоднее, удалёнка или офис.
Коллапс случился не просто из-за того что электромобилей расплодилось много, а из-за морозов. В мороз электромобили хуже держат заряд, а зарядка занимает больше времени. Именно поэтому инфраструктура не справилась, и именно поэтому это случилось именно сейчас.
Осталось научиться делать рентген в домашних условиях.
Вообще, вот если проводить аналогию с другими, известными мне языками, то обычно бывает 3 вида сущностей, отвечающих за параллельное выполнение: Process, Thread и Task. Терминология может отличаться, но суть та же. Task и Thread делят контекст с основным потоком, а Process это обособленная штука, которая работает в отдельном контексте (собственно, отдельно запущенный процесс). Task является более высокоуровневым по отношению к Thread. Task'и используют Thead'ы под капотом, через Thread Pool. В принципе, когда программист вручную работает с Thread'ами, он тоже должен использовать Thread Pool, если, конечно, хочет делать всё правильно. Да и вообще, по большому счёту, он должен делать всё то, что Task делает под капотом. Иными словами, если в вашем языке есть Task, то необходимость напрямую работать с Thread выглядит сомнительно. Может для каких-то случаев и нужно, тут спорить не возьмусь.
В JS я вижу порезанный Task (он же
Promise
), вижу Process (он жеWorker
), и совсем не вижу Thread. С одной стороны, как уже отмечалось выше, если есть Task, то Thread не особо-то и нужен. Проблема только в том, чтоPromise
в JS является порезанной версией классического Task, т.к. дваPromise
'а не могут быть выполнены одновременно, что означает, что они и под капотом не используют никакие Thread'ы, и просто выполняются по очереди, в одном потоке. Собственно, в документации к ним так и написано. Именно это имеют в виду люди, когда говорят, что JS однопоточный. Несомненно, он может делать внешние вызовы, которые будут работать параллельно. Но сам JS код всегда работает в контексте одного главного потока. Ну, кромеWorker
'ов, но они уже не потоки, а процессы.Честно говоря, не знаю, даёт ли спецификация какие-либо указания на тот счёт, могут ли Promise'ы выполняться параллельно, но текущая реализация во всех известных средах выполнения этого не позволяет, и весь существующий код, написанный на данный момент, не рассчитан на то, что Promise'ы могли бы выполниться параллельно. Если в какой-то реализации такое сделают, то существующий код окажется несовместим с ней, т.к. в runtime посыпятся ошибки связанные с синхронизацией потоков, а точнее, с её полным отсутствием в существующем коде. Можно, конечно, добавить другой вид Promise'ов, и назвать их ParallelPromise (или Task, так будет короче). Но в этом случае, речь идёт уже о новой возможности, которая на данный момент просто отсутствует, как на уровне реализации, так и на уровне документации/спецификации. То есть, тут никак не получается притянуть за уши, что JS, дескать, многопоточный, это среды выполнения халтурят.
Что касается приведённых вами примеров
XMLHttpRequest
иcrypto.pbkdf2
, то интереснее было бы увидеть не замеры времени, а принципиальную возможность вызвать гонку за ресурсом, ну там, какое-нибудь падение при попытке одновременно добавить элемент в глобальный массив или премешанный вывод в консоль. А так, сдаётся мне, что только запрос выполняется параллельно, а обработчик события вызывается уже в главном потоке, в порядке очереди. Почему я так думаю? Да потому что я ни разу не видел ни мьютексов, ни критических секций, прочих видов блокировок в JS коде, и при этом всё работает, ничего не падает. Если бы обработчикonload
уXMLHttpRequest
вызывался в разных потоках, то было бы много веселья. В частности, console.log мог бы запросто перемешать несколько выводов и вывести вам один json внутри другого. Видел подобное неоднократно, только не в JS.Из всего сказанного получается, что если давать классификацию, то JS однопоточный, асинхронный, многопроцессный язык. На мой взгляд, тому JS, что работает в браузерах, большего и не надо. С DOM, всё равно, не получится работать из нескольких потоков, и бедные фронтендеры только за зря будут страдать. Посмотрите на любой GUI фреймвёрк в любом ЯП, который поддерживает многопоточность, и вы поймёте о чём я говорю. Ни один из них не работает нормально с многопоточностью, и все они требуют обращаться к GUI из основного потока, иначе всё будет плохо. Именно поэтому, в JS и сделана асинхронность в одном потоке. А вот серверному JS параллельные
Promise
'ы не помешали бы. Но все серверные реализации эксплуатируют браузерные движки, и видимо там просто архитектурно не заложена такая функциональность, потому до сих пор и не добавили."Я на протяжении 10 лет покупаю спички Вашей фабрики и считаю количество спичек в коробке. Вы их кладёте то 59, то 60 штук, иногда 61, а вчера положили 56. Вы что там, совсем е**нутые?"
Ждём статью "Реальный Хабр: грустные факты, которые вас разочаруют".
На главный вопрос так и не ответили. Если такая кишечная палочка попадёт внутрь человека, будет ли у него электрический стул?
А разве это не является одним из условий доменно ключевой нормальной формы? Там, конечно, не только значения ENUM'ов, надо выносить в отдельные таблицы, а вообще допустимые значения любых пользовательских типов. Но сказать что оно никак не влияет уже нельзя.
Да ладно, No Man's Sky это шлак, даже после всех доработок. Собственно, доработок core механики там и не было. Понадобавляли кучу ненужных мелких активностей, а самое главное - генерация планет, как была одноклеточной, так и осталась. Условности торчат из всех щелей. Процедурная генерация настолько бросается в глаза, что убивает всю атмосферу. Например, опасных растений ровно два вида на каждой планете. Выглядят они, на всех планетах, абсолютно одинаково, отличаются только названием. Другой пример - спуститесь под землю, и вы увидите ровно три типа минералов, содержащих кобальт. Один тип минерала будет торчать с потолка пещеры, два других будут находиться на полу. Так будет на любой планете, словно это закон Вселенной. И снова, выглядеть они везде будут одинаково. В принципе, это касается любых минералов и растений в игре. Реально, есть некоторое, очень ограниченное количество типов, а потом они просто повторяются. Единственное, что будет уникальным - это их имена, которые являются случайно сгенерированными строками. Ну неужели нельзя было сделать менее топорно? Что нам пытаются продать под видом игры? Генератор случайных строк? Животные тоже не блещут разнообразием. Если визуально они ещё как-то отличаются друг от друга, то поведение у них очень однообразное, и на геймплей их разнообразие никак не влияют. Даже ресурс со всех падает одинаковый. Это множит всё разнообразие на ноль. Зачем так было делать, я вообще не понимаю. И так почти с каждым аспектом игры. Я уж не говорю о том, что на каждой планете ровно один климат и ровно одно погодное явление, которое ещё и происходит одновременно на всей планете. Да и климат, в общем-то, влияет только на визуальную составляющую и на то, какого цвета полоска защиты потребуется на этой планете. Никакой действительно уникальной механики, в зависимости от климата, нет. Ну то есть тупо, спасаться от холода, жары, токсинов или радиации нам предлагают одинаковым способом. А в чём тогда смысл разнообразия? В том что цветовой фильтр разный? Ну спасибо. Разнообразие снова помножено на ноль. Ни на одной из планет, вообще нет ничего уникального, и повторы начинают мозолить глаза уже после десятка часов игры. Игра предлагает быть исследователем, но какой в этом смысл, если найти что-то уникальное невозможно? Да и от планет там одно название. Это скорее фентезийные миры, а не планеты. Никакой планетной механики нет. Климат и тип планеты ничем не обоснованы, ни орбитой, ни типом звезды, ни вращением самой планеты. Кстати, о вращении планеты, продолжительность суток на всех планетах одинаковая. Рукалицо просто. А про продолжительность года там вообще говорить бессмысленно, ведь смены времён года, на планетах, просто нет. Всегда один сезон. Можно ли это вообще назвать планетами? Как по мне, это даже приблизительно не планеты. Обещали бесконечное множество планет, а не смогли сделать ни одной. Посмотрим что предложит беседка. На многое не рассчитываю, но у этих, даже если с механикой планет всё будет плохо, можно надеяться, что в остальных аспектах будет хорошая ролевая игра.
Один человек считает, что всё настолько плохо, что хуже и быть не может. Другой - считает, что может быть ещё хуже. Кто из них пессимист, а кто оптимист?
На мой взгляд, такое надо решать на уровне формата. Добавить формат а-ля Твиттер, для таких вот новостей, где информации на один заголовок. Если это цепочка событий, то можно группировать "твиты" по одной теме, формируя из них хронологию. Это будет удобнее как для написания, так и для отслеживания, чем то как сейчас делают одну статью, текст в которой дополняется со временем. А склеить потом всё в одну статью, можно вообще автоматически, если на то будет необходимость. Иными словами, каждое новостное агентство должно иметь раздел с твиттероподобным форматом. Новость всегда выгоднее опубликовать как можно раньше. А для полноценной статьи, даже если автор пишет молниеносно быстро, ещё надо собрать информацию, которая поступает не сразу. И Хабру стоило об этом подумать ещё в момент, когда они решили сделать раздел с новостями. Стандартный же формат Хабра для новостей не задумывался и больше подходит для глубоко анализа, ну или хотя бы, подробного изложения произошедших событий, который можно сделать только спустя значительное время.
По умолчанию, всё равно будут отправляться в шакальном качестве. Чтобы решить проблему, надо сделать HD вариант основным. А это дорого.
Тут не всё так просто. Поскольку Ленин является радиоволной, то он обладает волновыми свойствами, и поэтому площадь Ленина может быть разной в зависимости от города, в котором вы её ищете. Если наблюдатель находится за пределами какого-либо города, то площадь Ленина находится в суперпозиции. Но стоит наблюдателю оказаться в городе, как волновая функция коллапсирует, и площадь Ленина приобретает конкретное значение.
Слово "анонимным", в этом вопросе, лишнее. И если вы видите для себя причины быть анонимным, то скорее всего, ответ - "нет". А если не видите, то ответ точно - "нет".
Надо правильно создавать аккаунт. Например, как Google так и Microsoft позволяют без всяких СМС зарегистрировать аккаунт, если создавать его как аккаунт для операционной системы, а не на сайте. Потом, правда, могут захотеть телефонный номер. Но написать несколько комментариев в ютубе вы вполне успеете, равно как и зарегистрировать что-то на эту почту. А спамерам большего и не надо, их аккаунты и так долго не живут.
Да чушь это очередная. Зачем мне NFT, подтверждающий владение часами, если у меня есть сами часы? Судя по описанию в статье, это что-то типа возможности зарегистрировать купленный продукт где-то на сайте. Во всяком случае, функциональный аналог данного действия. Купите, какой нибудь телевизор Samsung, и в инструкции к нему, вам точно так же предложат зарегистрировать эту покупку, чтобы потом получать
спамэксклюзивные предложения на электронную почту.Разработчиков ПО может и не будут массово преследовать, а вот за авторов Википедии страшно.
Сколько нужно программистов, чтобы отрендерить картинку?
Что-то сумма совсем скромная какая-то.