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.
The Roslyn C# has a very developed system for injecting code at compile time in a very similar manner to what you described.
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.
> Housing demand is back up. Not just single family homes but also condos.
Hmmm, the median house price is $2.1M.
> It's a good time to live in SF.
It seems pretty K shaped.
Great time to live in SF and Bay Area iff you are an AI researcher, founder, VC, executive at one of the hyper-scalers, or a senior engineer with massive equity package in the few winning companies.
Not entirely sure if it's a great time to live in SF if you work at a bakery, are a Barista at Starbucks or even a mid tier SWE.
The San Francisco Bay area has only been affordable for the rich for decades; it's nothing new.
Fifteen years ago, I worked with someone who bought a $300,000 house, in his hometown ~150 miles away, and a $150,000 airplane, to commute to his job near the San Carlos airport, because it was much, much cheaper than living in the SF Bay area.
Just as a reminder, Google DeepMind is right here in the UK, and there are hundreds, thousands of top AI researchers that are foundational to everything that the US is doing, as much, if more so than the Chinese contributions.
We need compute, yes, but we certainly aren't short of talent if we put our minds to it, and many of them are already here.
It is a good example that what Europe lacks is capital. And there is an rich get richer phenomenon where wealth flows to the USA, and successful European companies gets sold (and many talented Europeans ends up working for American companies). In many ways the dynamic is one of a colony.
The more I learn about modern economics, the less I feel I know. Right now, the sense I have is that the flow of money from Europe to the USA is more like using the US as a flag of convenience than a material loss of wealth, especially given how many "American" companies have European offices filled with European staff and how much money is made selling space for ads from European companies to European users.
Does it matter in which countries the offices with the staff who develop some of these models are? I think so, for a number of reasons too long to go into.
Re "US citizens only", the question I'd have right now for all the AI companies is: can any new better-or-as-good-as Fable AI model actually be released?
If not, stop development of better models. That's the single most expensive thing any of them are doing.
Export controls on software is somewhere between "hard" and "impossible", so "US citizens only" means something between "nobody" and "perhaps some government agents", but the latter don't pay enough to justify the cost.
I'm working on a durable ECS system, mostly for games, though generally useful. It's to exercise a storage engine I have been building with Git like properties.
Should be able to turn the computer off at the mains half way through, then restart and instantly carry on without any loading phase as if nothing had happened.
Well that's the dream.
Now the lower layers work I'm mapping out the actual ECS part and what the API will be like.
I'm quite enjoying it and it's a really fun challenge.
Half of me wonders if it was all a live simulation/drill, to practice what happens if a much more serious event occurs, and a model needed to be quickly shut down.
Under such conditions we would be looking at Amazon's actions through a much more benevolent lens.
Not saying it has been, but it certainly crossed my mind as something worth doing regardless.
Even if it's not intended to be a drill, this dynamic is why I can't take Anthropic's side here. If you believe what they claim to believe about the future of AI, which I at least do, there are going to be future cases where an emergency block is required for much more real threats than this one. Why in the world would Amodei think that the model provider, with massive financial incentives to keep the money flowing, should be allowed to make the final shutdown call?
If a team of researchers at Netflix discovers a few days after release that GPT 6.0 has a safety-compromising jailbreak, I want Sam Altman initiating a shutdown the second he gets that call, and I had thought until Friday that Anthropic agreed with me.
That's certainly one way to do it, but where would you place them?
No, but seriously, you could imagine what we witnessed playing out in a high stakes Tom Clancy or Michael Crichton style fable.
The fiery blowhard Pentagon chief, the arrogant know it all tech bro lab head, an alarm being called in from a remote office and surfaced through Amazon.
I wonder how this is going to work given half the people working at the AI labs are Chinese foreign nationals, and even more interesting, DeepMind is based in the UK. Plus there is an awful lot of AI research going on all across Europe, especially Switzerland, that is feeding straight into the US major labs.
Banning foreign nationals from using your technology only makes sense if you don't rely on foreign nationals to build it in the first place.
Or are we so far along now we think we don't need them anymore.
I'm wondering if they might go for a restricted access model that goes beyond passport or citizenship, where people can still use it, but you have to be individually vetted, and put on a list to get security clearance.
Right, but I am talking about the general government response trajectory.
And also, even though Anthropic may not have labs themselves directly, there is a funnel of research that comes in the form of papers and conference tracks.
The AI community is pretty tight knit, and not having access to frontier models affects everyone.
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.