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

==========================================


Если правильно Вас понял, основное беспокойство вызывает нерациональность ВСЕХ сегодняшних языков прграммирования, в т.ч. и HiAsm. А вопросы входа в код, удобства или неудобства этой процедуры, рассматриваются Вами (это мое предположение) именно в этом контексте.
Эта обеспокоенность большое уважение вызывает. И оценки в 5К "себестоимости" пустой формы примерно правильны (вообще-то, должно быть по-меньше).
Вот только кажется, что это достижимо ЗНАЧИТЕЛЬНО большими усилиями, чем простенькой доработкой генератора кодов в HiAsm. Давайте называть вещи своими именами: Генератор Кодов - это Компилятор.
И стратегические направления, которые Вы предлагаете, видимо верные. Пример KOL, в моем понимании. демонстрирует полное несоответствие объема ИИ, заложенного в современные компиляторы, требованиям ООП. Поэтому и библиотека написана в "старом" стиле. Есть другие примеры, правда сам не смотрел, говорю со слов Dilma. Там тоже, вроде, НЕ применение ООП дает выигрыш по эффективности.

Теоретически возможна такая постановка вопроса: пусть интерфейс с пользователем будет Крайне-Объектно-Ориентирован, но это не накладывает никаких ограничений на компилятор - он будет генерировать коды по максимально рациональной схеме. Эффективность такого подхода Кладов и доказал делами, а не рассуждениями, как мне кажется.
Вопрос: можно ли ПОЛНОСТЬЮ изменить генератор кодов в HiAsm, сохранив внешний интерфейс Под полным изменением понимаю перехват ВСЕХ функций компилятора по созданию объектно-ориентированного кода. И именно HiAsm, опираясь на схему и коды (или скрипты) элементов оставил только подпрограммы, сам решил где (в динамике или нет) хранить поля объектов как простые данные, заменил лишние функциональные вызовы на inline, и т.д. (все оптимизационные задачи, но в рамках всего проекта). Ну вот тогда и можно получить 1-2К EXE-шник на пустую форму (если и KOL понимать как скрипты элементов и включить его коды в оптимизационную переработку).

Мне представляется, что аналогичная постановка достойна уважения. Одна беда - это не есть простенькая доработка..........