1. Use a declarative-style format for config, which is fine, I guess; 2. ... and when that inevitably fails, you... use a programming language?

Some people -- not all, but some -- may prefer to skip the first step and go straight for the second option. Particularly if it's a complex thing indeed like a build system and not, y'know, configuring your blog.

You can already "store whatever you want" in a serious database that respects types by default. It's called a blob or if you must, a text/varchar.

A team of professionals will trust a gateway they built themselves -- by an AI, most likely, as that is boring work -- that works for their organisation and whatever weird quirks and house styles they have. In a year or two when things are a bit more stabilised that'll be dozens of subagents each testing a little thing each in isolation plus a bevvy of software that looks for antipatterns in addition to running tests and linters and what have you. It'll be tested against the ground truth specification and not the boring crap in the middle.

At no point will anybody's session matter. Results count; nothing more.

So I'm not sure why people going "chop, chop" and "nah make it more red and bigger" is a useful signal of much of anything.

No, the future is a complex "gate" that checks, weighs and measures everything before it gets committed --- a local (or remote) "CI" but... more granular and far more specific and turned to the needs of the project you work on.

So if name == "foobar" then read; else ignore. For a 500 GiB XML file that makes a difference.

As for your other point about an "AST" (it's actually just a DOM.) That's the the benefit? And you're in for a surprise when you learn that reaching into a deeply-nested JSON structure deserialised into whatever memory format most appropriate for your pet language is also an abstract data type that you act on with getters/accessors/what-have-yous that is in all but name a DOM.

And we do have tools to deal with it: XSLT for transformation. For querying? XPath.

I am glad that younger generations are looking at it with fresh eyes. XML is a useful format; it has its place in your toolbox. Ignore the haters.

Stale MV is a thing you only ever burn your fingers on once. Like how "It's not DNS" is a common meme in networking.

SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));

That is _awful_ syntax; it is reminiscent of neo4j, which is surely not a tool anyone serious should copy from outright in 2026.

And of course the final thing I am left wondering is if it's fast. Row-level security is such a useful feature and yet only a fool would contemplate building anything serious with Postgres', as the planner goes haywire and does per-row-matching, nuking performance.

Congratulations --- this is a super cool project. I wonder if you've considered using ultralight filaments and 3dprinting the frame? PLA is stiff but brittle, and I know Bambu and a few others sell specialised versions that supposedly weigh less than normal.

> If it does not, I cannot consider it ready for this century.

Mhmm.

Really awesome!

Emacs has had this for decades: `pulse.el`. And building your own is very simple also.

You'll still need someone to write the glue code to trigger the pulse, but then a gpu patch on the backend wouldn't give you that either.

I'm sure someone on MELPA/Github has written code to do just this already.