| I did a lot of work on intentional programming at Microsoft back in the 90s on C++, and also intentional software later. Our approach was quite a bit different to Kiczales at the time. We had "attribute providers" which were essentially compiler plugin DLLs. These plugins could register themselves at various parse points and add work like enzymes on the AST. So here we have a compile time attribute that writes all the boilerplate to add windowing support to a class. Adding message maps, hooking up the dispatch, life cycle etc. [Window]
class MyWindow { }; It worked, but as others pointed out, it suffers from combinatorial explosion, and issues with debug ability. That said, as long as you stick within well defined verticals it was still very useful and saved a lot of typing, and reduced cognitive load. I have thought quite a lot about modern versions of this using LLMs and I can see why the article notices a parallel to prompts or spec based designs. At some point I tried to make a version of the system we built almost 30 years ago, but using an LLM as the preprocessor instead of rigid AST hackery. It works a lot better, and you can approach a more continuous interpolations between intent blocks and generated code. Even the combinatorial problem largely disappears. I stopped working on it though because I couldn't really see anyone wanting to adopt a new language or some whacked out extensions these days. Maybe it does have its place though in certain fields. It might be worth having another go at it with fresh hindsight. |
On the 'experimental' side you have Jonathan Blow's language, Jai, which has integrated codegen (AST macros that look like code) + type inference into the language on a very deep level, and from the podcasts I've listened to with veteran C programmers, was that during the 90s, when the mass adoption of OOP began, but performance still mattered a lot - there were a lot of ideas around OOP that were different from how C++ ended up doing this.
The most famous example I guess being COM, which is a C object model, that solves a bunch of issues that plague C++ to this day, such as reflection and code reusability, among others.
But COM is C and entirely incompatible with C++. And the big issue imo with C++ is that like AOP here, it has elevated a bunch of arbitrary magic behavior to language level, that honestly could've been done very differently, and the C++ implementation often ends up worse (multiple inheritence is a typical example).
A similar battle played out in Linux-land, with GTK creating its GObject system, which was roughly analogous to COM, and Qt opting to hack up C++, not unlike MFC.