У Вас есть код:

(
 ()=>{
  const PI = 3.14;
  function A(param) {
   console.log("A", param*PI )
  }

  function B(PI) {
   return function(param) {
    console.log("B", param * PI )
   }
  }

  function C(param){
   console.log("C", param * 3.14 )
  }
  

  A(1);
  B(3.14)(1);
  C(1);
 }
)();

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

Мы сговорились с ним прогуляться домой вместе. И вот идем мы с ним, болтаем за нашу нелегкую женскую долю, как вдруг он останавливается, достает из кармана катлету денег по 50 гривен (банковская упаковка), отщипывает от нее дву купюры и бежит через дорогу.

Я слежу за ним. На другой стороне - типичный интеллигентный бомж. Ну из тех которые живут бог знает где, из одежды только то что на нем, и тележка, куда он собирает бутылки пластик и бумагу.

Через пол минуты, мой спутник возвращается. Я у него спрашиваю - у тебя же в кармане не меньше 50 000. 5 000. Ты бы мог легко купить себе вот то-то (особые пилюльки).

А он мне говорит - а ты сам попробуй так сделать. Увидишь в первый раз как они плачут когда ты им просто даешь деньги, никаких пилюлек не надо.

Такая вот жизнь.

Я очень долго писал комментарий к одному ответу на YouTube.
Но оказалось что я на том канале забанен.
Размещу его здесь.

Ответ вот на это сообщение:
https://www.youtube.com/watch?v=-lHQ8b0GpEQ&lc=UgzqZ6hJTbNAmXoPxOp4AaABAg.9pRUv3pJmiBADWzUaBzFio

​ @iuriiankudinov9131

Про JavaScript ECMAScript
По сути, компания Oracle не препятствует повсеместному

Никого не волнует - препятствует или нет. Всех волнует только факт того, не придут ли завтра к тебе с иском и не потребуют ли рояльти. А чтобы этого не было - должен быть договор о использовании. Который Oracl не дает. Более того в 2024 году к ним был запрос относительно этого и получен отказ.

По этой причине с первого дня существования стандарта у нас есть ECMAScript как официальное название. О чем можно так же прочитать в первой главе Introduction спецификации ECMA.

var, let, const

Никаких областей видимости(block scope, function scope), согласно современной спецификации, в JavaScript нет. Их нет даже в первой спецификации 1997 года. Это жаргон который пришел в язык извне. И безответственно навязан многим людям, которые потом не могут понять почему у них "контекст теряется"

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

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

В первых версиях спецификации такие обьекты так и назывались - Variables Object.
В современных версиях спецификации - это называется Environments. Let и Const относятся к Lexical Environment ( не путать с лексическим окружением из сленга).

var реально нужна для глобальных объектов

Это ваши галлюцинации. Например:
Вам известно что function declaration - это тот же var? Вам известно что внутри окружения функции, используя function declaration вы используете тот же самый механизм что и используется variable statement? Где в окружении функции ( или если говорить вашим языком в function scope) глобально окружение?

let и const - это безобразно спроектированные развитие концепции var. Которая привела к просадкам производительности настолько значимым. Что первые две версии V8 с момента реализации let и const игнорировали часть спецификации чтобы сохранить ее на приемлемом уровне.

let и const - это всего лишь надстройка над var. С дополнительной проверкой в зависимости от окружения. Что видно как в спецификации, так и в конркетной реализации V8 на уровне байт кода, где доступ к идентификатору делается одним и тем же способом, но если требуется дополнительная проверка на окружение - до вставляется дополнительный код для этого.

Event Loop – базовая концепция выполнения JavaScript-код

EventLoop не имеет НИКАКОГО отношения к выполнению JS кода. И представляет из себя ОДИН ИЗ возможных механизмов постановки задачи на выполнения.

Для работы async awaite promise - event loop не требуется. Для их работы в спецификации заявлены свои очереди которые к EventLoop не имеют никакого отношения.

в реальности любая среда выполнения JavaScript (браузер или Node) использует цикл событий для организации асинхронного кода.Event Loop не ограничен только HTML5

Нет не любая. Любая среда обязана реализовать Job Queue, Promise Queue, Timeout queue. Которые могут быть сделаны ЛЮБЫМ образом. Event Loop - один из них. Например в D3 никакого Event Loop нет, при этом промисы прекрасно работают.

HTML-спецификация действительно описывает Event Loop для браузерной среды, но в Node тоже есть своя реализация Event Loop (libuv). Значит, это не только про HTML5, а про любую среду, где исполняется JS

И общего у этих реализаций только название. LibUv очень старается быть похожим на EventLoop из HTML5 но они радикально разные. Типичный пример - обработка окружением Node и HTML5 таймеров. Которая радикально разная.

И так далее.

Он EventLoop критичен для понимания асинхронности JS. Принцип «однопоточности» и механика отложенных задач (callbacks, promises, async/await) напрямую зависят от Event Loop. Без этого понимания невозможно работать с асинхронным JavaScript.

Это полнейшие глупости. Откуда Вы их взяли? Я могу вам обьяснить асинхронность без единого упоминания EventLoop и показать как он работает на примерах ГДЕ НИКАКОГО EventLoop нет.
Для их работы нужна Job Queue и Promise Queue, которые никакого отношения к Event Loop не имеют. Они вообще работают иначе.

Что Вы думаете насчет такого кода?

sub_off(sub_pos) {
            if (!(sub_pos < this.data.length)) {
                fail(new Error(`Wrong pos ${sub_pos}`));
            }
            const end = this.data.length - 2;
            if (sub_pos !== end) {
                this.peer_move(end, sub_pos);
            }
            this.data.pop();
            this.data.pop();
            if (this.data.length === this.sub_from)
                this.reap();
        }

любые предложения приветствуются. (;

єто вам про программирование
єйджизм и выбор между
возраст 25 и 45
и прочее

https://youtu.be/VHmVV-fWj4E?si=iX1xl0ogPtE_o8q3

JavaScript и спорт.

https://youtube.com/shorts/cRRytPpV1sM?feature=share

Обязательно посмотрите Flow/Поток, полтора часа мимимишного рафинированного удовольствия

Искать перевод - ненужно. Там перевод не нужен.

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

Чтобы почитать про программирование.

Очень рекомендую к прочтению старую книжку McConnell-а "Совершенный код"

Она будет Вам интересна как с точки зрения проектирования приложения, так и с точки зрения того, как изменились взгляды на эффективное программирование.

Чтобы познакомиться с материалом вот вам ссылка, которая будет активна сутки.

Если Вам понравится книжка - купите ее.

Обновил ссылку.
https://murych.com/media/books/js/Makkonnell_S_Sovershenny_kod.pdf

1-15 По Киеву.

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

Задачка на внимательность

Что будет выведено в консоль?

"use strict";
[1,2,3]
  .map( 
    ()=>{ console.log(this); }
    , {'this': 'is'} 
  )

https://t.me/AsForJsTalks/90966
Почему в JS нет переменных

О моем отношении к термину переменная и терминологии в целом
Єффективность общения программиста с другим программистом для случая их профессиональной деятельности, зависит от того насколько язык который они используют понятен для них обоих.

Чем сложнее и глубже термин - тем эффективнее их общение, в случае если они его понимают одинаково.

Например: .
если я Вам скажу TypeScript, то Вы меня поймете строго однозначным образом.
если я Вам скажу Promise (в контексте языка JavaScript) - Вы меня поймете однозначным образом.

НО
если в контексте языка JavaScript - я Вам скажу переменная, то Вы меня поймете в зависимости от Вашего уровня погруженности в тему.

Большинство расскажет что это некая коробочка, которая содержит в себе некое значение и шабаш.

В то же время, условный ДецПердец скажет - ты ебанулся не иначе. Никаких коробочек для значений в JS нет.

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


О перегруженности терминов
Эту проблему, обычно, решают на уровне спецификации - описывая Terms и Conditions. То есть то как следует понимать те или иные термины в рамках этого документа.

Например спецификация содержит термин Exotic Object. Что это такое?
Или что такое undefined? Из определения строго следует - что это особое Value (значение). Физически существующее значение, но не статус Identifier как многие думают.

В JavaScript, если Ваш идентификатор undefined - то это не означает его статус. Это означает что идентификатор связан с особым значением Undefiend. Равно как и Null.

В то же время в других языках, это может быть именно особый статус Идентификатора.


Что это значит для программиста? Это значит, что когда идентификатор === undefiend - мы проводим ровно туже операцию сравнения что и для идентификатор === 7; Что поведение этого идентификатора определено том же самым правилом, как если бы он был связан с любым другим типом. Он не имеет особого поведения.

Я как программист, знакомясь с JS и прочитав об этом в спецификации, сделал для себя совершенно очевидный вывод:
Если я хочу быстрый код, то мне лучше иметь, подобно тому как это делают в языке Ассемблера или Си, свои числовые константы, которые получают максимальную производительность. Тем самым избавив себя от лишней абстракции.


К чему тут переменные
Термин переменная никак не определен на уровне спецификации. НИКАК. Употребление слова variable касается только внутренней кухни самой спецификации.

Как работают Идентификаторы в JS?
Каждый Ваш идентификатор - это строковый ключ в обьекте (эта аналогия чрезвычайно близка к реальности). Где property этого обьекта содержит 32 или 64 битный адрес в памяти на структуру, которая описывае с чем именно связан идентификатор.

На уровне спецификации это описывается парой строчек - Reference Like. Мой рассказ про структуру и ссылку и биты - это из реализации V8 того самого Reference Like.

Как следствие вопрос - а где тут коробочки?
Если они и есть на уровне спецификации - то только для того, чтобы в них лежали ссылки.


Вернемся к разговору двух программистов. Если я пришел из Си и услышал слово перменная, которое никак не регламентируется на уровне спецификации JavaScript - я автоматом подумаю ПРО РЕАЛЬНУЮ КОРОБОЧКУ. Потому что в языке Си при компиляции, ваше число будет не какойто ссылкой на структуру в памяти - а рельаным его представлением либо в 32 либо в 64 либо в форме с плавающей точкой.

И я подумаю. О круто - переменная и число. Экономия память. Фаст перформанс. Кул кул.
И ахренею когда узнаю что это вранье. И в JavaScript все reference like.

Где это применяется? Пример.
У Вас строка в 1 мегабайт. Вы ее передаете в функцию. Вам говорят - там копируются по значению. И Вы как Си программист сидите такой и думаете - ипать копать, а как в функцию передать строку, чтобы не создать ее копию?

И вопрос этот у программиста возник именно потому что он думает что термин переменная с которым он пришел в JS не совпадает с тем как это есть в JS.

То есть терминология которая использовалась при общении двух людей ввела одного в заблуждение что привело к неэффективности его кода.


Почему в JS нет переменных
Они там коненчо же есть. Но они там существуют не в виде коробочек, как всем рассказывают, но в виде ссылочных типов. Если говорить совсем академическим языком - все переменные в JS это Shared Variables. или Shared Reference. В спецификации это называется Reference Like.

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


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

22-00 По Киеву.
Видео короткое. Так что будем писать шортс часа на два.

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

4-15 по Киеву.

Дополнение к предыдущему стриму, с уточненным экспериментом согласно пожеланиям сомневающихся.

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

Я просто оставлю это здесь
История одного комита в type script compiller. от 2023 года.

Performance on TypeScript compiler
Runtime
Using the STR in this issue comment filed by TypeScript, using this TypeScript commit (because it predates their manual var downleveling),

The prototype CL saw an improvement of 2-3% (1.29s - 1.30s parsing to 1.26s - 1.27s).

To compare, manually downlev eling to var sees an improvement of 6% (1.29-1.30s of parsing to 1.22s - 1.23s)

.
цифры даны инженерами v8


Кому интересно почитать обсуждение
https://issues.chromium.org/issues/42203665

Документ от инженеров V8 про особенности работы let/const с упоминанием того самого комита и цифр.
https://docs.google.com/document/d/1klT7-tQpxtYbwhssRDKfUMEgm-NS3iUeMuApuRgZnAw/edit?tab=t.0

шаг и мат шароземельщикам.


К слову по итогам 23 года, инженеры V8 поделились тем что они сделали за год, где в том числе было сказано

Finally, we also made ES6+ JS code faster by eliding some redundant temporal dead zone checks for let and const bindings.

Что и обьясняет изменение цифр в оценке производительности с 10-15% которые я давал два года назад, до 5-10% сейчас.

18-00 По Киеву.
Трансляция закончена. Длина 3 с половиной минуты.
Закончилась эпоха.

https://www.youtube.com/watch?v=8G0qxh4HabA

Это все еще не все.
Не смотря на то, что тема работы var/let/const для меня закрыта, и теперь за меня будут говорить инженеры v8, я анонсирую новый ахуху кейс при использовании let. Который всех снова поставит на рога.

Я сам его только что случайно открыл. Но я Вам его не покажу, потому, что у вас документов нету.

Все, в том числе и я, как остолопы тестировали издержки связанные с ThrowReferenceErrorIfHole, и никто не додумался посмотреть на то, как этот Hole инициализируется. А там, издержек в два раза больше


Кому нечем заняться - попробуйте угадать где проблема.
Вот код для теста.

function doAdd1( a, b ) {
  var theThing = 1;
  let theSummator = 0;
  function doSum() {
    for ( var i = 0; i < 10000; i++ ) {
      theSummator += theThing + i;
    }
  }
  doSum();
  return theSummator;
}