Ну MFC это и есть "более высокоуровневый инструмент"

Пытался им пользоваться... не понравилось. Претензии теже, фиг поймешь, где что надо, в какой таблице какое событие описывать, что кодить во View, что в Controler'е и что в Document'е.

Для простых задач, создать окошко, нарисовать две-три кнопки, подцепить окно и диалоги - вот реально WinApi и проще и короче. Самое главное, что код ПОНЯТНЫЙ, хорошо документированный (документация на WinApi) и гарантированна надежность работы.

Проблема в том, что пытаясь упростить WinApi, для понимания которой достаточно 2-3 тоненьких книжек (в 1990-х была хорошая серия от компании Диалог) и доступ к документации reference от MS, создают библиотеки, что бы разобраться в которых и что-то начать делать, нужно прочитать до 5-7 тысяч страниц.

Например высокоуровневый фреймворк Oracle ADF. Реально, читал все книжки, 5-7 тысяч страниц. На ряд интересующих в тот момент меня вопросов - ответов даже не нашел (нужно было сделать взаимодействие ADF и кастомного JavaScript с MapView ). Сделать то сделал, по примерам: поставьте такой триггер, вызовете такую функцию, сообщение передастся. Для видимости работы - достаточно. Но например описание механики работы рендеренга страниц, описание работы бизнес компонент для работы с базой - в документации нет, места в 7 тыс. страниц не хватило.

Сложность программирования "на WinApi" подменили кажущейся простотой библиотек / FrameWork'ов, которые, на самом деле, имеют сложность в разы, а то и на порядки большую, чем низкоуровневое средство, которое они подменяют. И значительно хуже документированные, а внутренности работы часто вообще не документированы.

Самое большая засада, что в библиотеках еще и свои парадигмы придумывают. Что добавляет и глюков, и сложности в освоении и миграции на новые хайповые технологии.

Конструктор - сложно... это же память корректно в диструкторе очищать надо. Сделаем GC... сделали.. зато похерили диструкторы. В результате вместо относительно понятного memory leak (который программист ожидает ) получили мало понятный resource leak.

Т.к. начинающий программист в лучшем случае считает, что система все сделает за него... а вот фиг... А в худшем случае , начинает пихать код в finallize, даже не понимаю, что это НЕ диструктор и код очистки ресурсов туда пихать не надо и даже нельзя .

А потом ловим глюки. В JVM добавляем еще более мало понятные ключи настройки (глубина очереди вызовов finallyze в GC) и прочее и прочее.

В результате, в реальном проекте работающем с RMI (remote method invocation), отхватываем тот же самый memory leak, которого в Java не бывает ))), и в течение нескольких месяцев пытаемся понять: толи программисты виноваты, толи настройки GC не правильные, толи оно так и должно работать. Т.к. в дампе памяти, висят гигабайты прокси от RMI, которые вроде как программисты и не создавали (оно само), должны непонятно как очищаться (дабы ссылки на данные объекты не локальные, а через RMI) и что уж совсем не понятно - что же с этим делать. Дока от GC приводит пару штук ключей, но как работают, как это мониторить, общедоступная дока нифига не описывает.

Уже было. Рождалось. Много раз. Даже есть более-менее живое.

Но продолжают "рождаться" и продолжаем "ожидать"

Ладно с языком. Требования даже на нормальном русском/английском и то сложно описывать. Знаю:

Oracle AIM
RUP

Если говорить об описании

UML

Но не взлетает. Если взлетает, то летит низенко-низенко хотя и переводит тонны денег

но вот сейчас появились анотации... и заживем!

Может пропасть и существует. Но как много людей в этой конференции реально этим пользовались? Какие успехи?

Бог с ней с пропастью. Пусть на русском бизнес-требования в структурированном виде опишут. Но нет этого

Ну и тот же UML создавался/рекламировался как средство кодогенерации. Я не пользовался, не знаю. Но об эффективности результата подозреваю.

Сталкивался со множеством графорисовалок программ/бизнес процессов с помощью мышки:

Oracle BPM
Oracle Workflow
Oracle Scripting
Oracle Data Integrator (ETL)

Результаты разные. От нарисовать - повесить на стенку. Нарисовать - обработать напильником. Вплоть до нарисовать и оно даже работает в продакшене до сих пор.

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

AFAIK