Xilian

В любом это все можно написать. Таких приложений - сотни.

Дональд Кнут - искусство программирования. Все алгоритмы и типы данных разложены по полочкам.

Дональд Кнут - основа. Все остальное базируется на нем.

>>Допустим, у нас есть какие-то данные о геометрических примитивах, их цвете, их расположении в какие-то ключевые моменты.

Это векторный формат выходит. Это не совсем видео.

>>С помощью каких библиотек их отрисовывают попиксельно и в итоге соединяют все кадры?

С помощью SDK конкретной операционной системы. Они радикально различаются. Можешь посмотреть код того же mplayer/VLC как кроссплатформенный.

>>Какие языки программирования чаще всего для этого используют?

Си/ASM/OpenCL/CUDA.

Сами алгоритмы невероятно сложные. Для обработки того-же mp4/avc/h264/h265 куча постпроцессинговых фильтров используется. Там очень много нетривиальной математики.

С++ и VHDL всегда были самыми денежными.

>>Но по некоторым своим причинам просто не перевариваю sql.

SQL вообще-то крайне простой язык программирования. Можно использовать ORM или DataAware инструменты. Но их эффективность чуть ниже, чем никакой.

А документацию по используемому API уже читать ну совсем не обязательно? Компилятор выдаст ошибку, если вы перекрываете уже существующее поле.

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

Купить готовый POS будет дешевле. Даже если ЗП программиста 10к в месяц. Это я еще штрафы и простой оборудования не учитываю.

>>есть еще какие то нюансы, которые я упускаю?

Исчисляются сотнями. Та же основная/операционная касса, выемка/инкассация.

>> Атол и Штрих ввиду их наибольшей массовости

Ну Атол это выходцы из Штрих. Все у них работает - просто вылизано все до предела и проблем практически нет. Это тебе не node.js/react с кучей криворукой школоты с тупыми вопросами.

Программисты старой школы пишут через cmp

>>Требуется некий интерфейс по взаимодействию между приложениями.

Или CLI или TCP/UDP. Если в node.мусорка можно сделать микросервис, то в проприетарном приложении нужно реализовать интерфейс или для "дергания" микросервиса, или встроенный HTTP транспорт.

Тут нужен не "Драйвер", а как говорят в IT "преобразователь потока". Нужна служба (win) или демон (linux). Который будет брать данные с com-порта и переупаковывать в udp/tcp. Я бы делал на пуле потоков.

Хранить в регистровом файле или памяти. Если возникают такие вопросы - вам явно не нужен ассемблер. Смотрите Arduino.

Дональд Кнут. Остальное производное.

Если функцию можно реализовать без класса и замыканий, надо делать просто функцию.

>>Что надёжнее, что безопаснее? 500 000 записей в БД против 500 000 файлов json.

Прямые руки безопаснее всего.
СУБД проще масштабировать и обслуживать. 500к записей - это вообще не о чем.

Веб магазин только ленивый не написал еще. Тот же 1С / Bitrix все давно умеет.

>>или эффективно и по уродски.

Что за бред?

>>(типо микро сервисы).

Вот это уже по уродски

>>Кода не много, но наверное его стоило бы разместить в отдельном объекте?

У тебя уже микросервис, который должен быть в своем АП и иметь свою иерархию объектов, или в нормальном случае - вообще ее не иметь.