На канале Бабіча сегодня был пост про Північ памʼятає! А от твоєму коду — необовʼязково.
где речь шла про мемоизацию.
От которого у меня возгорелась жопа, которая требовала уточнений

Ееее бейба да ты вся горишь,
я твой огнетушитель
пыщь пыщь, пышь пышь.


По сути
Мемоизация - это термин, который пришел к нам в этом виде из FP программирования.
Другие, тоже самое знают под термином кеширование - то есть процесс, когда сохранить результат работы какой то алгоритмической части будет дешевле, чем повторно выполнить эту алгоритмическую часть.

Например, запрос ресурса у удаленного сервера может нам стоить 300мс. То есть каждый повторный запрос, это еще 300мс ожидания. В то же время, если мы сохраним в кеше результат работы запроса и будем возвращать его - это 1мс. Экономия в 300 раз.
Ура кешированию и мемоизации.
Рахсодимся?

Нет. Во всем этом, важен сам факт сравнения - стоит ли процесс извлечения данных из кеша того? Может проще запросить их снова?

Первое то, что кеш может приносить пользу, понятно всем.
А вот второе - а когда это начинает происходить, и является свяэщенным граалем мемоизации.


Что говорится у Бабіча в посте:
Если у Вас СЛОЖНЫЕ вычисления - используйте кеширование/мемоизацию
Если у Вас существенные вычисления и повторяемость высокая - используйте кеширование/мемоизацию


Все классно, только что такое СЛОЖНЫЕ вычисления или высокая повторяемость?
Это все подобно формулировкам, сделайте хорошо когда можно сделать хорошо и никогда не делайте плохо когда плохо.

Все это идет наперевес с использованием useMemo в реакт. Как пример того, насколько бездумно его могут использовать. И снова критерий - не используйте useMemo когда это плохо. И используйте когда хорошо.


Чтобы дать хоть какую-то обьективную оценку, что хорошо, а что плохо - я лезу в код React для useMemo. И офегеваю от того сколько потребляет ресурсов эта возможность. Первое что напрашивается - никогда не используйте useMemo.

Я лезу в документацию к React с целью выяснить, что они рекомендуют:

useMemo is a React Hook that lets you cache the result of a calculation between re-renders.

и далее - чтобы принимать решение о использовании useMemo, используйте профайлинг вашего кода.
Вы знаете сколько требует ресурсов ре рендерс?

Dert Wider. Титры.


Краткая памятка что делать:
1) Если Вы понятия не имеете о том, почему вам нужно кеширование/мемоизация - не используйте вообще ничего.

2) Чтобы узнать нужно ли оно Вам - профилируйте ваш код.

3) Найдя слабое место - используйте для начала специфическое решение, гвозядми прибитое к вашему коду, который вызывает проблемы.

4) Снова профилируйте.

5) Получили положительный отклик. Попробуйте внешнее решение подобное useMemo

6) Снова профилируйте



Список ситуаций, которые должны вызывать у вас жгучее желание в одном месте попрофилировать ваш код:
1) Вызов внешних API особенно тех, которые напрямую связаны с IO: сеть, диск, формирование отображения

2) Одни и те-же математические вычисления, которые повторяются больше 5 000 раз.

3) Большая вложенность используемых методов

4) Вызов внутреннего метода, который приводит к одному из выше обозначенных поведений


На что следует обратить внимание:
любые внешние инструменты, подобные useMemo в реакт, сами по себе потребляют ресурсы. В случае useMemo - огромные.

Вы можете легко оказаться в ситуации, когда решение для кеширования, написанное вами на коленке для вашего кода, будет работать на порядок быстрее внешнего, подобного useMemo.

Если у Вас еще нет достаточного опыта в подобных вопросах то постарайтесь избавиться от любых стереотипов в голове. Вот вам пример

function doAdd (a, b) {
  return a+b
}

Вы точно знаете, что a и b всегда будут числами. Может ли тут потребоваться мемоизация? Даже если это повторяется 100500 раз?

Ответ: Нет, до тех пор пока ваши числа Типа Number.
И второй ответ: Все может сильно измениться когда у вас числа типа BigInt.

Сьогодні о 21-00 за Київом
Спроба Українською.

Поговоримо з Дмитром про типи, змінні та хоістінг

Які є типи в JS, чому Мурич говоре що змінних не має та що таке хостинг.
Як треба відповідати на співбесідах.
Про все це поговоримо з Дмитром, якого цікавить те, як не все це дивитись з глибини специфікації.

Попередження: Мова Мурича може звести вас до сказу, то якщо вас не переймає можливість паплюжити свої вуха - будь ласка долучайтесь.

https://www.youtube.com/watch?v=xp79fBrLlFw

Хлопцям з підрозділу CORVUS 93 ОМБР вкрай потрібна наша з вами допомога.
Дуже потрібна Антена для підсилення дронів, а також Коаксіальний кабель.
Сума збору 151 500 гривень. Сума немаленька, але це дасть змогу хлопцям працювати в таких жахливих умовах. Прошу долучитися всіх небайдужих. Фотозвіт та чеки після отримання комплектуючих підрозділом.

Для CORVUS 93OМБР

🎯 Ціль: 151 500 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/3QQx9kZyk

💳Номер картки банки
4441 1111 2585 3568

Я посмотрел видео про BigO от Климова.

Что укрепило меня в моем мнении об этом человеке.

Он не решился взять на себя самого отвественность и подтянул туда Тимура, который не в курсе всего контекста диалога.

Сделал он это с целью, чтобы поставить меня в неудобное положение, где, если я выставляю Климова некомпетентным, автоматически сделаю тоже самое и о Тимуре, которого я безмерно уважаю.

Может пора научиться кому-то брать на себя лично отвественность?

Туча ревнует к конспектам

Противостояние тучи и конспектов вышло на новый уровень.

часть конспекта была вырвана из контекста.

Четверг. 21-00 По Киеву
Практика и теория сложности алгоритмов в контексте языка JavaScript

Нужны ли алгоритмы JavaScript программисту, что такое Big O?

Узнаем, что говорят об этом авторитетные источники.
Получим минимально необходимый обьем знаний в теории сложности алгоритмов.
Проверим на практике то, о чем шла речь.

Эта трансляция, является ответом на записанную ранее трансляцию: Big O в JavaScript: инструмент разработчика или ненужная хрень?

Которую я считаю вредной и неверно формирующей отношение к проблеме у начинающего программиста.

https://www.youtube.com/watch?v=Qfi0_0w0dsM

Сегодня в 4 - 10 утра по Киеву
Разберем видео от Миши Ларченко

Меня много раз просили прокомментировать видео от Миши Ларченко.
Возьмем 4-ре из них:
1) JavaScript уничтожил интернет
2) EvenLoop в JavaScript простыми словами
3) Как работает асинхронность в JavaScript
4) Пойми замыкания в JavaScript

https://www.youtube.com/watch?v=0mnjOf4ViX4

Четверг. 21-00 По Киеву
Практика и теория сложности алгоритмов в контексте языка JavaScript

Нужны ли алгоритмы JavaScript программисту, что такое Big O?

Узнаем, что говорят об этом авторитетные источники.
Получим минимально необходимый обьем знаний в теории сложности алгоритмов.
Проверим на практике то, о чем шла речь.

Эта трансляция, является ответом на записанную ранее трансляцию: Big O в JavaScript: инструмент разработчика или ненужная хрень? 

Которую я считаю вредной и неверно формирующей отношение к проблеме у начинающего программиста.

https://www.youtube.com/watch?v=Qfi0_0w0dsM

Я что-то никак не могу очухаться.
Сдвинул трансляцию на час вперед.

Четверг. 21-00 По Киеву
Четверг. 22-00 По Киеву
Практика и теория сложности алгоритмов в контексте языка JavaScript

https://www.youtube.com/watch?v=Qfi0_0w0dsM

На ловца и зверь бежит.
Вместо моих причитаний рекомендую.

Александр Куликов, доктор физ мат накук, руководитель лаборатории сложности алгоритмов.

Вот про все вот это вот. В том числе о бесполезности Big O нотации.

https://www.youtube.com/watch?v=dHobFIzR4nk

23-00 по Киеву.
Смотри вместе: Александр Куликов - оптимизация сложности алгоритмов.

https://www.youtube.com/watch?v=_36Z4U07o3g

Если хочется о чем то подумать.

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

любая цепочка обращения к проперти приводит к возвращению строки из имен этих проперти.

Усик.
5 раунд.
чемп.

Слава Україні.

Что будет отображено в консоли при выполнении следующего кода:

var theSym = Symbol("abc");
console.log( theSym );
console.log( `${theSym}` );

тем кому слишком просто, задачка со звездочкой - почему происходит именно так

Пояснения относительно задачи про Symbol.

Короткий ответ:
console.log - это внешнее API, которое не обязано подчинятся спецификации ECMA.
Описание того, как и что именно, может делать метод log обьекта console содрежится в спецификации HTML5.

Где прямо написано - решение о том, как поведет себя метод log - лежит на плечах программиста который реализует этот метод. Реализует так - как ему хочется.


Длинный ответ:
Чтобы легко ориентироваться в том, как работает JS - нужно помнить три простых принципа:

1) JS это язык, в котором нет своего ввода/вывода. Любое получение данных или отображение данных, зависит не от языка JS. и может быть каким угодно, в зависимости от того, как работает внешнее API

2) механизм прототипного наследования, которым пронизана вся спецификация (для нашего случая сейчас не принципиален)

3) каждый statement разбирается на выражения, которые выполняются согласно алгоритму заявленному спецификацией.
то есть когда Вы смотрите на строку кода, то в ней НЕТ НИЧЕГО чтобы не прошло через какой то алгоритм.

даже когда вы пишите просто число 1 - то это не данные, это statement который приводит к тому, что возвращается ссылка на что-то что описывает данные.

var theSym = Symbol("abc");
console.log( theSym );

в строке с console.log у нас несколько частей, которые пройдут работу согласно алгоритмам спецификации:
1) console.log - получение ссылки на метод
2) ( ) - callable expression, то есть вызов чего то с чем то
3) идентификатор theSym - получение ссылки на структуру данных связанной с идентификатором theSym

Если кратко - вызов внешнего API log, внешнего обьекта console, передав ему ссылку на то, что связано с идентификатором theSym.

Результат? - в душе не тилельнкаю, потому, что это внешнее API которое может делать чем ему вздумается.


Вторая часть

console.log( `${theSym}` );

отличается от первой тем, что идентификатор theSym проходит через еще один этап вычисления выражения (алгоритма спецификации ECMA). Который требует вызов метода toString применимого к идентификатору, из-за использования темплейт литерал.

Согласно которому, в случае типа Symbol, должно быть throw.


Вместо ИГОГО:
Сталкиваясь с любым поведением, которое вас ставит в тупик, первое что сделайте - разделите где сам язык JS, который регламентируется ECMA Spec, а где вызов внешнего API.

Поведение которого, не обязательно регламентируется той самой ECMA Spec. И может быть как подчинено сторонней спецификации так и быть галлюцинацией программиста, который реализовывал API.

То есть разница в выводе заявленной задачи, оьясняется тем, что метод log обьекта console, а точнее те кто его реализовывал в Google Chrome, сделали так как им удобно. Вопреки тому, что диктует спецификация

Смотрите по сторонам.
Не пропускайте жизнь которая идет вокруг Вас.
Те кто умеет єто делать и становятся счастливыми людьми.

https://www.youtube.com/watch?v=5wrwcEZ3Btw