Dino Winchester

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

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

Как сортировать по нескольким параметрам:

const sorted = (data, keys) => Array
  .from(data, n => [ n ].concat(keys(n)))
  .sort((a, b) => {
    let diff = 0;
    for (let i = 0; ++i < a.length && !(diff = ((a[i] < b[i]) ? -1 : +(a[i] > b[i])));) ;
    return diff;
  })
  .map(n => n[0]);

Как сортировать дочерние элементы:

const sortChildren = (el, keys) =>
  el.append(...sorted(el.children, keys));

Сортируем:

const ul = document.querySelector('ul');

ul.addEventListener('change', e => sortChildren(
  e.currentTarget,
  el => [
    -el.querySelector('input').checked,
    el.innerText.trim().toLowerCase(),
  ]
));

ul.dispatchEvent(new Event('change'));

const rows = 8;
const cols = 8;

document.body.innerHTML = Array
  .from({ length: rows }, (_, i) => Array
    .from({ length: cols }, (_, j) => (i ^ j) & 1)
    .join(''))
  .join('<br>');

Собрать новый массив:

const newArr = arr.reduce((acc, n) => (
  acc.push({ ...n, fractionTotal: n.fraction + (acc.at(-1)?.fractionTotal ?? 0) }),
  acc
), []);

// или

const newArr = arr.map(function({ ...n }) {
  n.fractionTotal = this[0] += n.fraction;
  return n;
}, [ 0 ]);

Изменить существующий:

arr.forEach((n, i, a) => n.fractionTotal = n.fraction + (i && a[i - 1].fractionTotal));

// или

arr.reduce((acc, n) => n.fractionTotal = acc + n.fraction, 0);

const createArr = length =>
  Array.from({ length }, (_, i) =>
    Array.from({ length }, (_, j) =>
      (i === j || i === length - j - 1) +
      ((i <= j && i <= length - j - 1) || (i >= j && i >= length - j - 1))
    )
  );

Можно начальный индекс вырезания подстроки менять, и часы забирать только когда длиннее часа:

-    console.log(new Date(media.duration * 1000).toISOString().slice(11, 19));
+    console.log(new Date(media.duration * 1000).toISOString().slice(media.duration > 3600 ? 11 : 14, 19));

const merge = (key, ...arrs) =>
  Object.values(arrs.flat().reduce((acc, n) => (
    Object.assign(acc[n[key]] ??= {}, n),
    acc
  ), {}));


const result = merge('id', sum, arr1, arr2);

или

const merge = (key, ...arrs) =>
  Array.from(arrs.reduce((acc, arr) => arr.reduce((acc, n) => {
    const k = key(n);
    return acc.set(k, Object.assign(acc.get(k) ?? {}, n));
  }, acc), new Map).values());


const result = merge(n => n.id, sum, arr1, arr2);

должен быть более лаконичный способ, чем плодить такие переменные

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

Или это считается нормальной практикой?

Да, считается. У говнокодеров.

const result = arr.map(function(n) {
  return this[n];
}, Object.fromEntries(sum.map(n => [ n.id, n.name ])));

// или

const names = new Map(sum.map(n => [ n.id, n.name ]));
const result = arr.map(n => names.get(n));

// или

const result = arr.map(n => sum.find(m => m.id === n)?.name);

Но что если в массиве sum отсутствуют некоторые из нужных элементов, а получать undefined внутри массива с результатами не хочется?

Можно подставлять вместо отсутствующих элементов какое-нибудь дефолтное значение:

const result = arr.map(function(n) {
  return this[n] ?? 'объекта с таким id нет';
}, Object.fromEntries(sum.map(n => [ n.id, n.name ])));

Или есть вариант получать только то, что существует:

const names = new Map(sum.map(n => [ n.id, n.name ]));
const result = arr.reduce((acc, n) => (names.has(n) && acc.push(names.get(n)), acc), []);

1. понимать, как устроены веб запросы (чем GET принципиально отличается от POST и PUT)
   
2. уметь спланировать и создать таблицу в базе данных
   
3. работать с базой данных в PHP: подключаться, вставлять новые записи, находить существующие
   
4. принимать и обрабатывать веб-запросы на PHP, фильтровать и валидировать данные. Возвращать ответы и сообщать о возможных ошибках.
   
5. узнать, что все эти задачи – типовые, часто востребованные, и поэтому есть масса готовых решений – и научиться их находить и использовать
   

Держи, сделал небольшой набросок.

а если они касаются друг друга, они приобретают цвет другого элемента

Эту часть уже лень делать. Хотя это не сложно, нужно только добавить еще две таких же кляксы и посчитать расстояние между их центрами, что бы понять пересекаются ли они и нужно ли у них менять цвет.

Вопрос только к полю password, если это настоящий пароль.

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

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

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

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

Правильным способом будет не использовать сеттеры. Вот моя статья на эту тему:
https://habr.com/ru/post/469323/

Более подробно: каждый класс нужно проектирвовать так, чтобы данные внутри были максимально связаны. Например каждый метод работать должен в хорошем случае с максимальным числом полей класса, тогда у него высокий cohesion... В тоже время снаружи наужно работать с максимальн омалым числом метода, тогда будет низкая связанность (coupling). Это пара принципов из GRASP.
Когда вы делаете сеттеры и геттеры, то у вас данные внутри между собой почти никак не взаимодействут: с геттером работают снаружи, с сеттером работаю снаружи — весь класс нараспашку, а в нем в 100% случаев появляются данные, которые вместе не должны находиться и никак не связаны — анрушена и абстракция и инвариант и много чего еще...

Про инвариант отдельно: например есть платеж, у него есть значение, с которым платеж инициирвоан (initValue), есть значение холда (holdAmount) и есть значение чарджа на списание (chargeAmount)
Когда вы работаете с платежом, контролируя ивнариант в самом классе, то ваш каждый метод првоеряет др значения и позволяет перейти к др состоянию... методов будет 2-3, все инкапсулировано и безопасно.

Например:

class Payment {
     pub func charge(amount int) void {
          if (this.holdAmount < amount && this.initAmount < amount) {
               throw new PaymentException('Unavailable charge amount')
          }

           if (this.status === PaymentStatus:finish) {
               throw new PaymentException('Payment already fisnished')
          }

          this.chargeAmount = amount
          this.holdAmount -= amount
          this.status = PaymentStatus:finish
     }
}

Тут в одном методе полные проверки и класс сам контролирует все состояние внутри, также соблюдается закон Деметры. У даннго кода высокий cohesion (из GRASP), тк внутри идет плотная работа с внутр данными (значит они корректно тут закроекны) и низкий coupling ( с теми данными для данного кейса только один метод работы, все внутри)

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