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

А что, стрелочные функции не принимают аргументов или не возвращают результат? Или делают это как-то иначе? Или они не являются функциями?
Вопросы риторические.

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

супермозговывертный вызов можно сократить до
console[level].apply(console, argsWithFormat)

console[level] - некая функция из консоли, например, console.error. Но в IE9 у неё нет apply, и вызов через точку не сработает. Потому берется стандартный Function.prototype.apply и вызывается через call, так что console[level] станет для него как this (как то, что перед точкой), а остальное - аргументами.

Да, в общем-то русским (английским) по черному написано - data_process.c включает data_process.h, который первым определил функцию normalization().
А потом сам data_process.c определил функцию normalization() чуть пониже - ессно компилятор выдает замечание о переопределении, ибо оно есть :)

Похоже на какие-нибудь циклические инклуды.
У вас в data_process.h случайно не включается data_process.c?
Так делать не надо.

СУБД на стороне клиента разработчику нужно воспринимать только в качестве разновидности кеша данных, для которого по счастливому случаю предусмотрен API в виде SQL.
Какие проблемы?
- Все те, что есть у любой подсистемы, что обеспечивает кеширование. То есть, нужно следить, чтобы в ней находились только актуальные данные. Обеспечивать своевременную синхронизацию данных с сервером, решать конфликты кеша и данных сервера. Если у вас для пользователя предусмотрено ведение учетной записи, то в локальную базу данных не должно загружаться никаких данных, не предусмотренные правами доступа пользователя.

В любом случае, у вас эксклюзивная часть приложения, в которой, например, ведутся сведения об учетных записях пользователей, хранится состояние лицензий, должна находится на сервере. И там будет нормальная, взрослая СУБД.

Суть в том, что имеющие SQL запросы (INSERT, JOINT LEFT - RIGT) делать на стороне клиента, и я задался вопросом себе, насколько это нужная задача, и какие аргументы мог бы противопоставить, что это нужно - не нужно?

Если вы хотите собирать текст запросов на клиенте, передавать на сервер, и там исполнять.
Не самый хороший вариант, но терпимо только в одном случае, если учетная запись пользователя в точности соответствует учетной записи в СУБД, и доступ к данным в СУБД четко ограничен правами доступа - из учетной записи в СУБД нельзя дотянуться ни до каких данных, не принадлежащих только этому пользователю.
Но такое редко бывает, так что воздержитесь от этой практики, воспользуйтесь лучше GraphQL/TreeQL, чтобы ограничить API только тем функционалом и теми данными, которые необходимы для конкретного пользователя.

Зависит от многих факторов:
1. Если это полноценное офлайн приложение:
- Если необходима полноценная СУБД (SQL Server, Postgres, MySql) - то нет. Мало кто захочет дополнительно себе устанавливать такие тяжелые зависимости, они всегда могут ее удалить и тогда уже не восстановить, обновления ПО либо не будут возможны, либо трудны
- Если это встраиваемая СУБД (SQLite) - то вполне да, так многие приложения делают (на андроиде слышал SQLite часто используют)
2. Если это онлайн приложение в браузере:
- localStorage - это key/value хранилище
- web sql - устаревшая технология
- куки - могут пропасть в любое время
3. Если это корпоративные клиенты, то можно навязать им свои требования по необходимости запуска СУБД на каждой машине

Тут все зависит от того, что под БД подразумевается и для каких целей это нужно

UPD: SQL запросы из клиента напрямую в БД - очень плохая идея, не надо так (обновления, безопасность, гибкость и т.д. - все постарадает)

DI, Dependecy Injection - это сам процесс внедрения зависимостей (например, когда ты зависимости через конструктор получаешь)
Пример:

class User
{
    IService _service;
    
    // DI
    User(IService service)
    {
          _service = service;
    }
}

DI-Container - это специальный контейнер, который может необходимую зависимость предоставить. Сначала ты в него регистрируешь все зависимости, а потом вызываешь метод по типу .getService("UserService") и он сам понимает какой сервис ты хочешь, какая у него реализация и как его создать (возможно для него нужны другие зависимости)
Пример

// DI-контейнер
var container = new DependencyContainer();
container.Register(typeof(IService), new ConcreteService());

var service = container.Get<IService>();

Сервис-локатор - это (анти) паттерн, когда, грубо говоря, у тебя есть статический класс этого DI контейнера, к которому обращаются все сервисы. Т.е. вместо того, чтобы использовать тот же самый DI или передавать интерфейс DI контейнера они напрямую обращаются к конкретному DI-контейнеру. Так делать не надо - будут трудности с тестированием, обновлением и всем сопутствующим
Пример

// Сервис-локатор
class ServiceRegistry
{
     IService Service;
     static IService GetService()
     {
           return Service;
     }
}

class User
{
     void DoSomething()
     {
           var service = ServiceRegistry.GetService();
           service.MakeStuff();
     }
}

Если файл лежит в папке со скриптом - надо открывать его, используя путь к пкапке со скриптом, а не надеяться на то, что текущий каталог совпадёт. Под виндой тоже всё зависит от способа запуска скрипта.
Так что читай про sys.argv[0] и модуль pathlib. Пригодится.

Убедитесь, что ваш сервер правильно отвечает на запросы OPTIONS. Добавьте OPTIONS в список Access-Control-Allow-Methods.
CORS Preflight

например тот же ксамарин.

а вообще практика обычна - ядро пилится на одном, гуишки на нативе под платформу.

Под плюсы довольно много кросс-платформенных библиотек для GUI, самая известная, видимо, Qt.
Сам язык и его стандартная библиотека вполне кросс-платформенны. Но в разных компиляторах и в разных реализациях стандартной библиотеки могут быть свои нюансы.

Сейчас меня будут бить

Лично я бы посоветовал бы вас начать с C++. Сразу кажу, не из-за того что... Да чёрт его знает. В двух словах. Питон отличается от других языков программирования (Императивно - Декларативных), так что не очень хороший старт. Почему? Потому что у вас будет направление только Питон и, масимум Реакт. Я НЕ ГОВОРЮ ЧТО ЭТО ПЛОХОЙ СТЕК.

Для примера, почему я предлагаю начать с C++. Вы детально разберёте работу с памятью, типами данных, структурами и алгоритмами. Отсюда у вас буде уже очень мощная база для выхода куда угодно, та хоть в микроконтроллеры. Вообще отсюда можно идти уже во многих направлениях, C#, php, Java и т.д.

Но опять же, это моё субъективное мнение, что я считаю C++ лучше чем Python

UPD: да и C++ могли лучше прокачивает чем Python. На Python обычно очень много школьников начинают, на C++ работают инженеры)) Илон Маск начинал с программирования на C++ )))