Дмитрий Беляев

Агрегация/Ассоциация/Композиция - это всё виды взаимоотношений между разными типами. Это не принципы
Абстракция - это просто сама возможность вводить какие-то новые абстракции, поверх уже существующих. Ради этого ООП и придумано.

ИМХО, вот эти все попытки выделить основные принципы ООП в современном мире не имеют смысла, тк языки сейчас мультипарадигменные и постоянно добавляют и убирают какие-то части.

И уже споров о глубинном смысле трёх волшебных слов была целая куча (а ведь если бы кто-то когда-то не решил всё уместить в одиночные слова - этой неразберихи бы не было)

Так что из всех принципов, которые объединяют все более-менее ООП-языки остаётся только:

1. Всё есть объект, и объект объединяет под собой некоторые данные (которые могут быть не доступны публично) и операции (методы или функции), которые можно произвести над совокупностью этих данных.
2. Имеется какой-нибудь механизм для полиморфизма.

В общем-то первый такой принцип можно назвать этой самой абстракцией и, отчасти, инкапсуляцией.

Роутер то какой стоит??
Скорее всего он просто перегревается. И стоит 700р))

У Кинетика есть хорошие модели

Можно микротик поставить, Hap AC - ему 15 клиентов вообще лафа)))

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

https://habr.com/ru/company/htmlacademy/blog/546500/

Основных поинтов использования семантики 3.
1) Использование подходящих элементов делает их использование удобнее. Несколько раз встречал когда ссылки делали дивами с js поверх. Нет возможности нажать на них колёсиком чтобы открылаьс в новой вкладке или правой кнопкой с соответствующем ссылке контекстным меню. Это отвратительно неудобно.
2) это помощь людям с ограниченными возможностями для понимания контекста происходящего на экране. Наглядный пример это ссылки внутри тэга nav. Можно побаловаться со скрин ридером и будет понятно о чём речь.
Если коротко: ссылки в div будут озвучены как: *ссылка*.
Ссылки в nav: "ссылка, навигация"
https://vc.ru/promo/132280-kak-zvuchat-sayty-nezry...
https://www.youtube.com/watch?v=RQiN1Hhrxu0
3) Помощь поисковым ботам понимать контекст и формировать снипеты в поисковой выдаче. Пример есть в статье выше.
https://siteclinic.ru/blog/technical-aspects/html5...

с какой-либо из «сторон дела»: пользователя, верстки, программирования, поисковых систем?

1) Про пользователей выше
2) Про вёрстку - удобнее читать
3) Про программирование - использование верных тэгов соответствующим образом влияет на работу с этими элементами в JS либо избавляет от необходимости в JS в принципе.
4) Про поисковые системы выше.

Rust создавался при разработке браузера Mozilla чтобы закрыть конкретные дефекты С++. Системообразующие дефекты такие как NPE, Buffer Overflow e.t.c. Сегодня доля Rust файлов в сорцах мозиллы составляет 40% от общего количества файлов. Это - достаточно чтобы считать успехом мероприятие.

Нужно ли брать Rust при разработке игровых движков? ХЗ. Я-бы сказал что Rust важнее для тех приложений где важна инфо-безопасность. Я не спец в Rust, но я чисто из любопытва смотрел например как в Rust открыть файл (мне надо было парсить логи). Так вот открыв файл ты не просто не получаешь файловую переменную. Ты получаешь монаду Either (там кажется она называется Result<>) и вот пока ты ее паттерн матчингом не проверишь - никакого файла не получишь. Тоесть протокол работы с файлами строгий настолько, насколько это возможно. Срезать поворот - не получается. Это в сях можно взять fopen(..) и результат проe..ать.

Вобщем rust по уровню строгости напоминает... ну не знаю Haskell наверное. Хотя в Rust тоже можно творить безпредел - но по крайней мере ты будешь явно декларировать операции как usafe. Это слишком очевидно вобщем-то. Дело техники на code-review просто отделить опасное и принять решение стоит ли так кодить или нет.

Да и один финский парень обещал что в Rust скоро зайдет как второй язык разработки ядра Linux. Ждем пока.

Потому-что точки с запятой ставить нужно.

const url = 'https://jsonplaceholder.typicode.com/todos/1';

(async () => {
	
	console.log(url)
})()

Всё это умеет systemd, не нужно велосипедить.

Bower давно мёртв. NPM точно есть у всех и мало нынче отличается от Yarn. Но при этом многие используют Yarn. Если речь про свой собственный сайт, то возьмите монетку, загадайте для каждой стороны NPM и Yarn, подкиньте её и получите ответ. Если встанет на ребро - берите Bower, Вселенная пытается вам что-то сказать.

Promise.resolve(value) - это статический метод, возвращающий промис в состоянии fulfilled с указанным значением.
Эквивалент new Promise((resolve) => resolve(value))

И можно как-то выполнить промис без аргументов?

Что значит "выполнить"? Создать можно, сменить статус с pending на fulfilled нельзя, на rejected можно по исключению.
P.S. Если вас смущает то, что и там и там используется resolve, то в new Promise это всего лишь название переменной для каллбэка в функции. Оно может быть любым.

new Promise((แก้ไข) => แก้ไข('Решено'));
//Promise { <state>: "fulfilled", <value>: "Решено" }

В целом - так исторически сложилось, что в C# используется знаковый тип для индексации массивов.
В Java вообще, например, нет беззнаковых типов. (думаю, из-за этого и в C# для индексации используется int)
В новых языках, например в Rust от этого сразу уходят - в нём для индексации массивов используется usize (беззнаковый, размером с указатель на целевой машине)

Если завернуть объект в Proxy, можно будет изменять ключи при обращениях к объекту:

const obj = new Proxy({}, {
  get(target, key) {
    const lowerKey = key.toLowerCase();
    return target[Object.hasOwn(target, lowerKey) ? lowerKey : key];
  },
  set(target, key, val) {
    target[key.toLowerCase()] = val;
    return true;
  },
  has(target, key) {
    return key in target || key.toLowerCase() in target;
  },
  defineProperty(target, key, descriptor) {
    return Object.defineProperty(target, key.toLowerCase(), descriptor);
  },
  deleteProperty(target, key) {
    return delete target[key.toLowerCase()];
  },
  getOwnPropertyDescriptor(target, key) {
    return Object.getOwnPropertyDescriptor(target, key.toLowerCase());
  },
});

1. Встраивают интерпретатор нужного языка, при необходимости урезают стандартную библиотеку (чтобы не давать коду плагинов лишних возможностей) и подсовывают туда средства общения с хост-программой.
2. Если нет нужды изолировать плагин от остальной программы, то полагаю что да, накладные расходы на поддержку плагинов уменьшатся в случае, когда плагин написан на том же языке, что и программа. В противном случае организация "песочницы" может занять столько же усилий, сколько встраивание интерпретатора.
3. Лучше, если язык плагина является или интерпретируемым (как Lua или JS), или компилируется в байткод (как Python/Java/C#). Также желательно, чтобы язык плагина имел средства интроспекции.

Интерпретатор lua (в случае Love2D и Cocos), и Mono (в случае Unity) можно подключить, как обычную сишную библиотеку.
В этом случае C++ не нужно "понимать" чужой язык, достаточно лишь понимать, какие сишные функции надо вызывать, чтобы запустить код на "чужом" языке, и как туда передать доступ к функциям движка (это делается, обычно, путём передачи указателей на функции)

Мужик, async/await - это просто сахар над Promise. Любая async функция возвращает Promise по определению, любой await этот Promise разрешает.

async function setLegalLevel(): Promise<string> {
  ...
  await axios.post
  ...
}
...
const val: string = await setLegalLevel();

[].concat()

function mergeArrays(arr1, arr2) {
 let arr3 = arr1.concat(arr2);
 console.log(arr1, arr2, arr3);
}

mergeArrays([1,2,3,4], [5,6,7,8]);

Тебя вообще касаться не должно что там пользователь делает через консоль браузера.
И любой js код юзер может изменить. Даже взять полностью код и вырезать лишнее.
Есть например расширение "User Javascript and Css", с его помощью можно на любую страницу свой код впихнуть.
Если это какая-то игра и тебе нужно ждать проигрывания анимации, то привяжи данные к серверу