As For JS

20:00 по Киеву. Разберем видео, где его автор - Григорий Бизюкин, будет говорить о асинхронности в JavaScript и выбираться из callback hell. Расскажет про цикл событий - Event Loop, очереди задач, функции обратного вызова, промисы (promise) и многое многое другое от автора видео - продвинутый JavaScript. Обещаю быть насколько спокойным настолько же и объективным. https://www.youtube.com/watch?v=mIxGEGgxNiI

Перебирая бумажки из прошлой жизни, нашел одно собеседование, где была такая задача: Каким образом нужно инициализировать theIdent в коде:

var doExplAdd = (
  (theValue, theNum)=>{
    var theIdent = ????; //менять код можно только тут
    return `${theIdent}${theNum+theIdent}${+theIdent+theNum}`
  }
);
console.log( doExplAdd(3, 7) );

что бы мы получили результат: Hi. The 1st value is 3. You want to add 7 to the first value. So the result will be: 10 На скриншоте дополнительные примеры.

Что сегодня почитать: ⎡En⎦ Вячеслав Егоров: Maybe you don't need Rust and WASM to speed up your JS https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html посмотреть: ⎡Ukr⎦ 00:03:30 YARMAK FT. ALISA - ДИКЕ ПОЛЕ Україно, свята мати героїв, зійди до серця мого https://www.youtube.com/watch?v=mOOClonYKmc посмотреть: ⎡msk⎦ 00:58:12 Виктор Вершанский — Множественное наследование на JavaScript https://www.youtube.com/watch?v=P-j448mMoBI

По перше ми живі. Незважаючи увагу на увесь тий безлад який сьогодні вночі було зроблено БРАЦЬКІМ НАРОДОМ. Что сегодня почитать: SMIs and Doubles Язик: En https://darksi.de/6.smids-and-doubles/ посмотреть: 00:03:48 ONUKA — PEREMOHA Якик: Рідна мова Неймовірна естетика. Мурахи. https://www.youtube.com/watch?v=umIaIJAD9xo посмотреть: 00:51:46 Не морочьте мне голову со своим функциональным программированием / Виталий Брагилевский Якик: msk https://www.youtube.com/watch?v=mmvHC3UgYmg Слава Україні.

Трансляция началась… https://t.me/AsForJavaScript?livestream

Диалог о том, почему аналогии, которые не отвечают спецификации, это не всегда плохо. Один из нас, рискнул донести до такого человека как я, мысль о том, что мои претензии к аналогиям, на базе которых они, обучают языку, не обязательно являются злом для всех. И пока Вы, а стало быть и я, разбираемся в том, кто на ком стоял, в выше заявленном тизере - подписываемся на телеграм канал, и шлём ненужные Вам деньги согласно реквизитам опубликованным ниже. *Поддержать маленького бородатого JavaScript-ра* Карта Приват: 5168745021397333 💵 USDT Tron (TRC20): TKoZu59WHiX6L6qvwYTYTsZJerDrnAHBTx 💶 USDT etherium (erc20): 0x75fb8a62dfcf453b2e73f1ef1c407d46f918fffa 💴 bitcoin:bc1q74aru82v4d3alay7p53jdwkmxe4a5gz7fmvfm2?message=AsForJS&time=1686349743 💷 PayPal: demimurych@protonmail.com https://patreon.com/demimurych https://t.me/AsForJavaScript?livestream – ссылка на стрим в телеге. https://www.youtube.com/watch?v=Tfr4vXlc1sw – ссылка на трубу.

09:30 По киеву Разбираем видео: "Продвинутый JS (Григорий Бизюкин)" Меня всегда интересовал один вопрос, почему от Яндекс, выступают люди, которые уже на протяжении нескольких лет рассказывают чушь с экрана, в то время, когда у них есть действительно сильные специалисты. Прогнозируемое время около 2х часов.

6:45 по Киеву. Обсудим часть интервью D. Crockford: Why We Should Stop Using JavaScript

Что сегодня почитать: JavaScript engine fundamentals: optimizing prototypes https://mathiasbynens.be/notes/prototypes посмотреть: 00:37:45 Вячеслав Егоров — Производительность JavaScript через подзорную трубу https://www.youtube.com/watch?v=HPFARivHJRY

у меня большая просьба ко всем кто перичислял средства. напишите мне пожалуйста лично: @demimurych

все. горшочек не вари. кот счастлив. от имени заслуженных пенсионеров js фронта выражаю всем искреннюю благодарность. Ай нє нє

Ай нє нє! Сбор на макароны директору Табора и его первому помощнику нам чтобы дожить до конца месяца нужны: 150дол. 90дол ВСЕ ГОРШОЧЕК НЕ ВАРИ Кто чем может: Карта Приват: 5168745021397333 USDT Tron (TRC20): TKoZu59WHiX6L6qvwYTYTsZJerDrnAHBTx USDT etherium (erc20): 0x75fb8a62dfcf453b2e73f1ef1c407d46f918fffa bitcoin: bc1qt74aru82v4d3alay7p53jdwkmxe4a5gz7fmvfm2?message=AsForJS&time=1686349743 PayPal: demimurych@protonmail.com

Что можно сегодня почитать: Язык: Английский   Сложность: Пред-средняя Understanding V8’s Bytecode Что можно посмотреть: Язык: Русский   Сложность: Минимальная ⎡~1:43:18⎦ Vitaly Bragilevsky: Вводная лекция по теории алгоритмов

В рамках программы - ото делать мне больше нечего Что можно сегодня почитать: Язык: Английский   Сложность: Средняя JavaScript Bytecode Авторы попробовали на нескольких примерах прояснить, что такое Байт код в V8 Что можно посмотреть: Язык: Английский   Сложность: Минимальная YoutTube 25 минут: Franziska Hinkelmann: JavaScript engines - how do they even? Несмотря на то, что этому видео уже больше 6 лет, оно все еще остается актуальным на уровне формирования общего представления о том, как работает V8.

8:30 По Киеву https://www.youtube.com/watch?v=Hy_oU4iPIIY

⎡4.1. Примеры => Память и две разные HOST среды⎦ Неделей ранее, было записано видео, где мы разбирали случай, когда в среде NodeJS, оперирование большим массивом данных состоящим из целых чисел в пределах от 0 до 30бит на число, требовало большего количества ресурсов процессора, нежели такой же обьем данных состоящий из чисел типа Double64. Что было 100% воспроизводимо на 64 битных системах, и показывало более прогнозируемый результат на 32 битных системах. Причиной которого, стала именно особенность оперирования памятью в случае HOST среды NodeJs, в которой отключены существующие уже два года в оригинальном V8 оптимизации напрямую связанные с работой GC и сжатием указателей для 64 битных систем. То есть, HOST среда d8 показывала производительность в три раза выше чем среда NodeJs. И при этом, поведение d8 было предсказуемым для заданных задачей типов чисел (SMI vs Double64) При этом, производительность в NodeJS удалось привести к состоянию прогнозируемой (целые числа быстрее) и соизмеримой d8, только компенсировав особенности этой HOST среды. Напомню еще раз, что разница была более чем в три раза. ⎡4.2. Примеры => Рекурсия⎦ Одним из самых показательных примеров проблем O нотации и ей подобных, является оценка сложности алгоритмов использующих рекурсию, против алгоритмов ее не использующих. O нотация, однозначным образом определяет алгоритмы основанные на рекурсии, как те, которое несоизмеримо хуже чем алгоритмы не использующие рекурсию. Однако, в V8 по умолчанию, для WASM кода уже год как включена оптимизация, которая носит общизвестное название - хвостовая рекурсия. Алгоритм закрепленный спецификацией ECMA. Согласно которому, например вычисление тех же чисел фибоначи, произойдет с применением этой оптимизации, которая превратит рекурсивные вызовы функции, в плоский код без единого вызова функции, производительность которого в общем случае будет выше традиционной реализации. Выше в силу того, что подобная оптимизация накладывает на программиста набор правил, следуя которым он получает как гарантии применения оптимизации, так и гарантии получения чрезвычайно оптимизированного кода. Для JS эта оптимизация пока находится на стадии тестирования. Хвостовая рекурсия - это стандарт дефакто для функциональных языков, где наличие циклов - то есть итарций вообще исключено. И решение происходит за счет использования абстракции - рекурсия. Которая благодаря форме хвостовой рекурсии, преобразовывается RunTime в форму эффективнее типичного итерационного цикла. Как результат O нотация, дает совершенно неверное предсказание относительно используемого алогоритма в подобных условиях. ⎡5. Вместо ИГОГО⎦ Я преследовал цель, наглядно продемонстрировать, что O нотация, не может использоваться как эффективный инструмент, для принятия решений в случае выбора алгоритма, реализация которого будет на языке JavaScript. Язык JavaScript, как и любой другой динамический интепретируемый язык, живет в мире абстракций чрезвычайно высокого уровня. В котором не может быть место методологии, которая отталкивается от предельно упрощенных способов оценки потребляемых ресурсов базирующихся на детерминированности поведения. Это противоречит природе таких языков. Иными словами, я заявляю, что на собеседованиях, или где либо еще, когда кто-то требует пояснение JS кода с точки зрения O нотации - этот кто-то некомпетентен. При этом, я хочу подчеркнуть, что само по себе понимание принципов оценки сложности алгоритмов, в отрыве от их реализации в JavaScript, безусловно положительно скажется на навыках программиста.

⎡3.1. Проблемы метрики о затраченной памяти => Интерпретируемые среды⎦ В системах, где задачами распределения этого ресурса, занимается среда выполнения кода, особенностей которые следует учитывать для уверенного прогноза затраченных ресурсов - чрезвычайно много. Но даже учитывая их все, едва ли можно было бы сделать уверенный прогноз соответствующий критериям O нотации. ⎡3.2. Проблемы метрики о затраченной памяти => Garbage Collector⎦ Типичный пример - срабатывание Garbage Collector-а (GC), в процессе выполнения алгоритма, может вносить значимые флюктуации в результирующее затраченное время. Само по себе срабатывания GC на прямую связано с использованием оперативной памяти. Как следствие, алгоритм, который ставит во главу угла свою производительность за счет чрезмерного расхода той самой памяти, может оказаться не у дел, в силу агрессивной политики стороннего механизма GC. ⎡3.2. Проблемы метрики о затраченной памяти => Особенности представления в памяти данных⎦ Другой типичный пример - это то каким образом в принципе организовывается работа с данными в интерпретируемых средах подобных JS. Характерным отличием которых, является тот факт, что *представление таких данных в памяти - не отвечает ожидаемому* Например: создание двух идентификаторов, которые ссылаются на одну и туже строку:

var theThing = "abc";
var theEnotheThing = "abc";

не приведет к дополнительным расходам оперативной памяти для обеспечения функционирования второго идентификатора. Оба идентификатора будут ссылаться на одну и туже строку в памяти. Об этом позаботиться среда. Но что еще хуже, если бы мы в силу работы алгоритма сделали что-то подобное этому:

var theThing = "abc";
var theEnotheThing = "abc";
[...] 
theThing = undefined;
theEnotheThing = undefined;

это не означало бы, что память используемая для представление строки abc была бы освобождена. Более того, если бы где-то ниже в алгоритме снова использовалась бы строка abc то окружение снова бы сослалось на эту строку в памяти. ⎡3.2. Проблемы метрики о затраченной памяти => Данные в коде и данные в интерпретаторе могут быть представлены радикально по разному⎦ Другим примером является конкатинация строк, когда существует минимум два поведения среды: либо действительно создать в памяти новую результирующую строку, либо создать особую структуру, которая описывает факт конкатинации с сылками на две строки. И зависит этот выбор от разного набора параметров: первый из которых длина самой строки. Если строка больше какого-то минимума, то при конкатинации, новая строка никогда не будет создана, но будет создана структура описывающая логику того, где взять части и как их собрать вместе для получения результата. При этом не стоит забывать, что очистка памяти от строк, на которые больше не ссылаются идентификаторы, происходит только в самых критических случаях, решение о которых принимает тот самый GC. ⎡3.4. Проблемы метрики о затраченной памяти => Выводы⎦ Как было показано выше, распределение памяти, для выполнения необходимых задач в средах, где отсутствует ручное управление, может приобретать неконтролируемые формы в силу особенностей работы алгоритмов GC. Что делает предсказание о расходе подобного ресурса, намного более сложной задачей, нежели простое предположение о инкрементном использовании ресурса. Сама архитектура среды, может представлять данные в памяти образом, который предполагает целый ряд оптимизаций, исключающих избыточность потребления памяти. Например одни и те-же строки будут представлены один единсвенным образом. Что еще более увеличивает сложность оценки поведения подобного ресурса. Пример с конкатенацией строк, лишь подчеркивает насколько далеко может зайти в принципе оптимизация процесса использования памяти. Что как минимум, потребует в рамках O нотации, изменение методологии оценки расхода этого ресурса. И, как максимум, сделает его невозможным в принципе. ⎡4. Примеры⎦ А теперь несколько примеров, наглядно демонстрирующих сказанное выше.