Автоматическая генерация типизированных структур данных для Си

Groovy тоже вполне себе подходит, хотя он где-то на уровне Ruby по поддержке метапрограммирования.

Очень расплывчатая на самом деле задача.

Ну, это я сформулировал только часть инженерных требований.
Концептуально этот метод предназначался для решения более широких задач.

Например одним из требований был уход от графической репрезентации UML диаграмм в сторону принципиально другого процесса разработки и проектирования.
Т.е. вначале должен строиться язык предметной области, фактически DSL, но не в том, урезанном виде, как то сегодня понимается.
И только потом проблема должна была быть описана в рамках этого конкретного DSL и эффективно оттранслирована в исполняемый код.

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

Там много было, амбициозная штука была.

В качестве примера приведу одно предложение по финальному тесту.

#include "NLP2SQL.h"
#include "Война и Мир"

В результате должен был быть проанализирован текст на естественном языке, существительные выделены как сущности, глаголы как отношения, прилагательные как атрибуты-модификаторы и в случае нахождения противоречий или неопределенностей — печать их списка.
А в случае ненахождения таковых — печать SQL схемы.
:-)

Т.е. это конечно тест фантастичный, я не думаю, что до этого бы дошло, но как «загоризонтная цель» — это было сформулировано.
Разумеется Лев Толстой не особо интересовал, но вот полуформальное описание предметной области на входе — это было бы спасением для реально крупных задач.
Или юридические тексты — относительно неплохо формализуемые, бухгалтерские, спецификации, просто список артефактов системы.

Опять таки, описание задачи в виде DSL позволяло довести безбажность вплоть до формальной верификации на самом раннем уровне. А наличие транслятора из DSL в реальный язык программирования сохраняло безбажность далее на всех этапах.
В теории конечно, но выглядело на тот момент крайне заманчиво.

(a) на практике это толком никому не нужно,

Ну, нам в тех проектах это было точно нужно.
Тем более, что тогда С++ с его темплейтами (крайне убогими по сравнению с этой техникой) продвигался в том числе и как средство создания DSL.
А темплейтов нам точно было недостаточно, особенно учитывая их возможности верификации.

(b) если и нужно — то *гораздо* проще оформить свои изменения в четко выделенном плагине к компилятору, а все эти итеративные изыскания выделить в систему сборки (а ля makefiles)

Не, это проще, но для одного проекта.
Когда проекты идут потоком — это придется делать каждый раз для каждого нового DSL.
А программист, который владеет препроцессором и который может написать плагин — стоят разных денег.
:-)

Если все то же самое, но без изменения парсера — то по сути любой язык, в котором есть какие-то code blocks и closures можно считать языком метапрограммирования, в котором на пустом месте можно сделать любые управляющие структуры — хоть if-then, хоть exceptions, хоть guarded commands, хоть что. Чемпионом на этом поле лет 10 назад был Perl, сейчас вроде как все активно любят Scala или в крайнем случае Ruby (хотя там парсер куда более примитивный, чем в Scala).

Да, разумеется.
Но нас интересовала возможность универсального решения, не зависящего от языка (хотя основная ниша планировалась на С).
Ядро — средство работы с AST, универсальное.
Подставив в ядро начальную грамматику Perl — мы дальше пишем все на Perl (дав, в середине кода #include «java» — перейдя на другой язык).
Опять же, на тот момент для нас была критична производительность, что опять приводило к С, даже не к С++ — если кто помнит, у ранних компиляторов С++ была например веселая привычка прятать скрытый try/catch в конструктор, что несколько тормозило результирующую программу — аж в 40 раз бывало.
Версию правда сказать не могу, но не позже g++ 3.х
Но было.

Кроме того в ходе анализа мы заметили одну вещь — писать на объектных языках в таком ключе достаточно тяжело, кто не верит, пусть попробует реанимировать openC++. Причина — огромное количество синтаксических плюшек, которые приходится обрабатывать.

Если рассматривать с точки зрения правильного lingua franca — то, боюсь, путь code transformation а ля haXe (или тот же pyrb) — единственно практически разумный.

Хз, когда-то ADF+SDF считался единственно разумным, с его помощью COBOL на С++ массово переводили.
Сейчас многое не имеет смысла просто потому, что критерии поменялись, стоимость проекта уже не так критична, зато более критична документация, поддержка. Стабильность уже не так играет — код, который живет 10 лет без переделок никому не нужен.
Фактически тот, что придумает робота-программиста убъет индустрию.
Ну если индустрия не убьет его самого.
:-)

Соответственно снижение издержек в процессе разработки ПО может как угодно декларироваться, но мы ведь все понимаем, что означают эти декларации.
:-)
Особенно если посчитать в деньгах например стоимость ввода в эксплуатацию нового языка программирования.

Говорить о том, что «каждый пишет на своем языке, а потом все это работает вместе» — можно, но на практике нужно не это.

При наличии частичной верифицируемости и зафиксированных интерфейсов — почему нет?
Они ведь все равно пишут каждый по своему, бангалорец или пекинец.
И ревью кода не так уж и сильно ведь помогает, а времени кушает. Ценного между прочим времени.

И опять же, то, что я описал — это был путь снижения непродуктивных издержек разработки. Что сегодня неактуально, сегодня актуально наоборот завысить сложность проекта, взять под завышенную сложность лишних людей и не забыть тестеров, чтобы все баги лишних людей фиксили.
:-)
Структура рынка поменялась.

Нужно, чтобы не машины понимали друг друга (с этим, внезапно, фактически-то проблем и нет уже лет 30 как), а чтобы люди понимали — а эта проблема — она не в средствах, а в головах.

Внезапно, большинство современных технологий — UI-driven.
Языковой интерфейс может понять и человек и робот, и робот может передать информацию другому роботу по цепочке, складывая из мелких строительных блоков более крупные конструкции.
На конце UI всегда стоит человек. И, следовательно, для создания более крупных вещей он всегда там будет стоять, тормозя всю систему и внося ошибки.

В web 1.0 контент выделялся роботом без проблем.
А сейчас — пишут интеллектуальные программки, которые по лейауту определяют баннеры, рекламные блоки и вырезают их.

Не то чтобы я агитировал за web 1.0…
:-)

У haXe, надо отметить, тоже проблем практических мильён. Основная — в stdlibs, которые очень так себе map'ятся в многообразие стандартных структур и библиотек во всех поддерживаемых таргетах.

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

Ну и опять-же, дать возможность программисту создавать свой язык под задачу с такой же легкостью, с какой он создает bash-скрипт — имхо многого бы стоило.
Правда что бы получилось в результате и насколько бы это было практично — никто не знает, т.к. начальное R&D было свернуто, даже до пилота не дошло.
MetaC который появился позже чем-то похож на этот проект, только у него ядро заточено под С, а не универсальное.
Это все-таки больше препроцессор, судя по той документации.
Но даже для MetaC я вижу применение сегодня, не массовое конечно, но есть.

Недостаток макро-подхода — сложность отладки. Это верно даже для более мощного М4 — достаточно вспомнить приснопамятные Auto{conf,make}, что уж там говорить про унылый препроцессор Си и его «тесную» интеграцию с собственно компилятором.
Кроме того, подобные решения плохо масштабируются — очень скоро настает момент, когда сложность макро-кода начинает препятствовать добавлению новой функциональности.