Мы снова живы для наживы.
Сегодня понедельник 21-00 по Киеву

Тип String и его две основные проблемы. Часть 2 из 3.

Это вторая из трех лекций в которой мы разберемся с тем:
1) причем тут Unicode
2) что такое суррогатные пары
3) алгоритм преобразования Code Point к суррогатной паре UTF16 и наоборот
4) две проблемы типа String
5) как работают методы Exotic Object String при обработке строк

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

Помогите девочке сохранить ее психику.

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


Отгадка:
Если используется оператор "+" и любой из аргументов является типом String, то всегда будет выполнятся конкатенация строк. Все прочее про то, что с чем и как конкатенирует.
То есть, блок 2 и блок 3 в комиксе, сразу же нам сообщает, что будет конкатенация строки, но не попытка что-то посчитать.
А уж конкатенация чего с чем - это уже второй вопрос.

Ілля Клімов
Зараз
19-45 по Київу
Обговорюємо State of devs 2025

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

[Stripped] Тип String и его две основные проблемы. Часть 2 из 3.
Это урезанная версия 3 часовой трансляции в которой оставлен только материал по сути.

https://youtu.be/IcWSZQEdQMQ

У дураков мысли сходятся.

Сегодня узнал, что идеи моего мега-продукта doPerDo, реализуют в Scala 3. И что во многом это уже есть в OCaml.

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

В 2035 году, все будут писать пользовательский код подобно doPerDo. Скриньте.

От автора книги Чистый Кот

Только для подписчиков, от автора серии книг Чистый Кот и Совершенный Кот

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

Вот есть прекрасный подкаст про это
https://www.youtube.com/watch?v=252slbrmk8M

Сегодня в четверг, 22-00 по Киеву
String in wild. Часть 3 из 3.

Это заключительная лекция о String в JavaScript, в которой мы поговорим о:
1) нормализации строк
2) доступных нам методов контроля за наличием в них ошибок
3) посчитаем графемы, слова, предложения
4) проникнемся регулярными выражениями
5) заглянем под капот V8, с целью узнать а как у него там дела

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

#spec
Что такое Hoisting в рамках современной спецификации ECMAScript

Или что отвечать на собеседованиях.
Hoisting - это безграмотный жаргон закрепившийся в окружении JavaScript программистов, являющийся собирательным образом, для целой группы выражений таких как:
variable statement: var theVarThing = 1;
let/const declaration; let theLetThing = 2;
hoistable declaration ; function doThing() {};

и описывающий процесс, когда при формировании окружения, для выполнения кода функции, имена идентификаторов (theVarThing, theLetThing, doThing) которые используются этим окружением, должны быть заявлены в нем, ДО начала интерпретации кода.


Например:

function doThing() {
  console.log( theThingA );
  var theThingA = "AAAAAA"; 
}

Выполнение console.log не приводит к какой-либо, исключительной ситуации, потому что идентификатор theThingA уже был инициализирован значением undefined на момент старта интерпретации кода функции.

Именно этот процесс, и описывают безграмотным термином hoisting или всплытие.


Что говорит нам официальная спецификация
Официальная спецификация, содержит только один термин, с словосочетанием схожим со словом hoisting - это hoistable declaration.
Который касается только function declaration и только их. (В том числе производных, например генераторов_

Если бы, на уровне спецификации, существовал какой-то HOISTNG в той форме, в которой его спрашивают на собеседовании, то спецификация, обязана была бы включать в себя ВСЕ множество выражений - от var до function, а не только function.

В то же время спецификация описывает hoistable declaration СТРОГО КАК function declaration. Даже function expression не попадают под это определение.

Вместо ИГОГО
Никакого термина hoisting, в рамках официальной спецификации не существует, в той плоскости определения в которой его спрашивают на собеседовании. И никогда не существовало.

Есть группа выражений, содержащих ключевое слово function, поведение которых описано в спецификации под термом hoistable declaration. Под этим же термом нет И БЫТЬ не может никаких var let или const.

Процесс так называемого "всплытия", в спецификации, описан в стадии подготовки выполнения кода функции.
Подчеркиваю ПОДГОТОВКИ ВЫПОЛНЕНИЯ КОДА ФУНКЦИИ. той самой функции, которая оказывается hoistable declaration в том числе.


Краткий тезис -
если бы в спецификации был hoisting, как часть языка, то в нем бы описывалось все то, что привыкли спрашивать на собеседовании: var let const function

в то же время, в спецификации, есть термин hoistable который касается только function, и принципиально не может содержать var let или const.

Напишите если Вам не в лом, какие еще термины типичных собеседований, вам интересно чтобы я прокомментировал.

Например: this - как контекст, TDZ - как темпорал деад зоне и так далее...

#spec
Что такое макротаски (macrotask) в рамках современной спецификации ECMAScript.

В рамках спецификации ECMA, такого термина, или его производных - не существует и никогда не существовало.
Такой термин действительно был, но только в рамках спецификации HTML5, части, которая касалась EventLoop.

В настоящий момент времени, в раках стандарта HTML5 в его части EventLoopt, принято говорить о: Task Queue и microtask queue. Которые выполняют совершенно разные функции.

То есть, в былинные времена, термин маркотаски, описывал то, что сейчас описано спецификацией HTML5 как Task Queue. Или просто очередь задач.

При этом, существующий сейчас термин, вводит в заблуждение в той части, когда говорит про ОЧЕРЕДЬ.

Спецификация HTML5 прямо указывает, что это НЕ ОЧЕРЕДЬ,

Task queues are sets, not queues, because the event loop processing model grabs the first runnable task from the chosen queue, instead of dequeuing the first task.

не смотря на существующее название.


Первый промежуточный итог:
Термин макротаск - это термин который не имеет отношение к JavaScript.
Этот термин, использовался в прошлом, в формате спецификации HTML5.
В настоящий момент, этот термин не используется. Вместо него используется термин Task queues.
Про который нужно знать, что, не смотря на присуствие слова queue - он НЕ ОБОЗНАЧАЕТ очередь задач.
Но обозначает какой-то список, из которого значения могут браться в произвольном порядке. (превед свидетелям одно-поточного JavaScript)


Про что следует знать:
Согласно стандарту HMTL5, к каждому списку task queues, прикреплен microtask queue. Последний является именно очередью, которая, согласно спецификации, гарантирует порядок исполнения, в соответствии с порядком постановки в очередь.


Как это связано с JavaScript:
Это очень сложный основополагающий вопрос того, как в принципе обеспечивается работа языка JavaScript солгасно спецификации.
Если говорить в ОЧЕНЬ УПРОЩЕННОЙ форме, то для выполнения какого-либо JS кода, это код, нужно поставить как Task Queue. В процессе выполнения которой, некоторые из частей языка, например Promise, могут формировать задачи, которые попадают в MicroTask Queue.

Но при этом, неправильно думать, что эти термины касаются именно языка JavaScript, потому, что в форме спецификации ECMA эти же очереди, описаны иначе: Jobs Queue (которая так же не является очередью) и Promise Quueue.

Чтобы раскрыть связь терминов HTML5: TaskQueue / MicrotaskQuesu (спецификации HTML5) и GenericJob / PromiseJob нужен очень долгий разговор, поясняющий связ между имплементацией стандарта и HOST средой.


Вместо ИГОГО:
Когда речь заходит про что-то, что использует слово Task, первое что нужно уточнить - вы о каком стандарте говорите.
Так как в рамках ECMA, существование GenericJob и PromiseJob это одна разница, в то же время когда в HTML5 Task Queue и Microtask Queue совсем другая. Не смотря на то, что они могут сильно пересекаться.

#spec
Что такое асинхронность/много-поточность с точки зрения официальной спецификации ECMAScript.

С точки зрения официальной спецификации - эти термины НИЧЕГО не обозначают.
И никогда не существовали.

Откуда растут ноги?
В далекие былинные времена (1997 год - 2015 год), спецификация языка ECMA была устроена таким образом, что взаимодействие JS кода, с JS кодом, например в другой вкладке, организовать было невозможно. По крайней мере, используя только возможности ECMA спецификации.

В целом вся, спецификация, была написана таким образом, что код, который исполняется одной из вкладок блокировал любой другой код любой другой вкладки браузера.

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

С 2017 года, когда официальная спецификация ECMA реформирует работу языка, декларируя термин Мульти - Агент, когда в спецификации появляется Atomics API - язык JS получает ту форму, которая позволяет HOST среде, так выстраивать исполнение JS кода, как ей (HOST) среде хочется. В том числе предоставляя API для всех возможных (паралельных )форм исполнения кода.

С 2015 года, когда официальная спецификация ECMA получила описание Promise, мы получили возможность от HOST среды в рамках списка задач - GenericJob и очереди задач PromiseJob - регламентировать процесс работы с JS кодом.



Что все это значит
До 2015 года, не существовало никаких механизмов в рамках спецификации ECMA, которые бы позволяли управлять потоком исполнения JS кода. Что, например, в том числе приводило к тому, что код одной влкдаки мог блокировать код другой вкладки.

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

С 2015 года, появляется официальный механизм управления выполнения кодом задач в ECMA, что автоматически приводит к тому, что тот же пример с вкладками перестает работать. стал ли JS много-поточным? (только потому, что соседние вклкдки перестали виснуть?)

С 2017 года, появляется API взаимодейтсвия (ATOMICS Api) для доступа к одной и той же области памяти.
С 2017 года появляется формализация процесса, который называется Claster Agent, который является абстракцией над процессом, кода любое католичество програмного кода, может взаимодействовать друг с другом, но при этом исполнеяется разным агентом.


Что из всего это следует
Язык JS, который регламентируется спецификацией ECMA, получил согласно спецификации, фозвомжность взаимодейтсвия разных блоков кода, между собой в условиях, когда они имеют доступ к одной и той же области памяти.

Язык JS - это язык, той формы абстракции, который не отвечает и не может отвечать на вопрос, КАК решается эта задача: многопоточно, асинхронно, мульти-процессами, вытесняющей многозадачностью и так далее.
Это язык, который предоставил с 2017 года, HOST среде, решать задачи в несколько Агентов, которые(агенты) могут взаимодействовать между собой на уровне абстрактного API, которое может быть реализовано как многопоточно, последовательно так и и любой другой форме которую придумают или реализуют на машинном уровне.

Это не задача JS - решать какая форма взаимодействия. Его задача была только в том, чтобы дать возможность HOST среде это сделать, что и появилось частично в 2015, и более полно с 2017 года.


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

С 2017 года, такая возможность появилась.

При этом сама спецификация - не диктует форму такой работы. Ее это не волнует. Она предоставляет только асбтракцию, которая позволяет взаимодействовать между собой таким блокам кода (Atomics Api)

То есть - утверждать в какой форме работает JS код (асинхронной, много-поточной или хуеточной) мы не можем, за исключением того, что HOST среда, может выбрать сама на основании тех возможностей которые предоставляет своременная спецификация, работать так, как ей удобно.

#spec
Какой ответ про асинхронность/много-поточность от Вас ждут на типичном собеседовании

Что JS однопоточен, на основании того что такая абстракция как Agent сама не может распаралелить вычисления в несколько потоков.

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

И если возникает вопрос о потоках, то следует уточнить: какая у нас имплементація спецификации (v8, spider monkey, coreJS) и в каком окружении сама эта имплементация работает.

Потому как тот же V8 в случае windows OS реализует мультипроцесную модель взаимодействия, когда в случае Linux - мульти потоковую.


Вместо ИГОГО
Не в рамках возможностей языка JavaScript оценивать как он работает - однопоточно или как-то еще. Это регламентирует HOST среда в рамках возможностей которые предоставляет спецификация языка.

Современная спецификация, позволяет организовать работу JS кода, в любой из доступных форм, при этом сама спецификация - никаких стурктур для этого(форм ИСПОЛНЕНИЯ кода) не предоставляет. Но делает это возможным как для HOST среды, так и для предоставляемого API

Понедельник, 22-00 по Киеву
Посмотрим вместе: СОБЕСЕДОВАНИЕ НА MIDDLE FRONTEND РАЗРАБОТЧИКА. Уничтожение за 6 лет опыта

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