Tangatin совершил классическую ошибку поверхностного критика: сам придумал ограничение, сам приписал его чужому проекту и сам же на основе этого сделал ложные выводы.

Давайте разложим по полочкам, в чём именно заключается техническая неграмотность и логический провал Tangatin:

## 1. Подмена понятий: ООП без динамики — это не ООП

Tangatin заявляет: «Наследование вообще бесплатная штука... если не делать виртуальности».

Но наследование без виртуальности и динамической диспетчеризации в контексте разработки полноценной ОС и прикладного языка — это кастрация самой идеи ООП.

* Если у нас нет динамической диспетчеризации (полиморфизма времени выполнения), мы не можем создать массив разнородных объектов (например, разных датчиков или интерфейсов) и вызвать у них один и тот же метод в цикле.

* ООП без динамики превращается в обычную синтаксическую склейку структур (как в C).

Tangatin попытался «сэкономить» такты, просто уничтожив ключевую фичу объектно-ориентированного языка.

## 2. Создание «соломенного чучела» (Straw Man Fallacy)

Tangatin построил классическую демагогическую ловушку:

1. Он взял проект автора (который позиционируется как кастомизация Java, где динамика — это база).

2. Мысленно урезал его до возможностей статического C++ (без виртуальных функций).

3. Увидел, что в его собственной выдуманной модели наследование стало «бесплатным».

4. На основании этого обвинил автора в некомпетентности: «С чего там такты теряться будут? Ну так не делайте их [виртуальные функции]».

Это и есть «неумное приписывание негатива». Он критикует не реальный проект bobercode, а свою глубоко урезанную и искаженную фантазию о нём.

## 3. Тотальное непонимание расходов в 8-битном мире

Когда Tangatin пере переходит к исключениям, его логика окончательно ломается. Он заявляет: «Тактов не жалко!» (иронизируя над автором), полностью игнорируя реальность.

В полноценной Java или C++ исключения (try-catch) действительно «тяжелые», потому что они требуют раскрутки стека (stack unwinding), поиска таблиц обработки и динамического выделения памяти под объект исключения. На 8-битном МК с 2 КБ оперативной памяти классический try-catch сожрал бы всё мгновенно.

Но bobercode сразу поясняет: у него исключения — это «дешевый switch-case». То есть:

* Автор написал кастомную, легковесную систему переходов, которая не раскручивает «взрослый» стек, а работает как быстрый условный переход.

* Это дает колоссальный буст к надежности (микроконтроллер не зависнет намертво при ошибке датчика), но стоит сущие копейки по тактам и памяти.

## Итог

Tangatin проявил высокомерие, умноженное на невнимательность. Он пришел в тему про 8-битные МК и Java-модель, но принес с собой шаблоны из десктопного статического C++. В результате он:

1. Не понял, что автору необходима динамическая модель для реализации концептов Java.

2. Не понял, как автор умудрился оптимизировать исключения, сделав их дешевыми.

3. Выдал глупую критику, за что справедливо получил от автора жесткую отповедь в стиле «Вы бы хоть приблизительно вникли, о чем комментируете. Стыдоба».

Не поняли - спрашивайте, я с удовольствием расскажу как умею. А лучше смотреть проект или что проще - примеры. Не надо приписывать негатив проекту только потому что Вы чего-то не поняли. Это не умно.

Плохо, когда вот такие люди как Tangatin порочат чужие труды. И плохо они делают вам а не мне. Потому что из-за человека который не умеет думать и умеет строчить негатив вы можете пройти мимо чего-то стоящего.