mickeyp

Your... solution to bad ETL data is to go "let's keep it this way"?

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.

That's just another word for priority queueing.

Who would trust the classifiers, though? I would not.

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.

I find the value of someone steering an AI session to be practically nil for nearly everything. Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists.

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.

Because SAX parsing is a thing, and the visitor pattern makes it easy to elide searches in sub-trees if an attribute does not match.

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.

XML is unfairly maligned. Yes, people bought into it too much 26 years ago, but then you would too if you had to maintain someone else's massive packed struct dumped into a file and documented in a poorly-maintained word document --- or worse, a brace of dumb IETF RFCs that contradict eachother.

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.

But people do 3d print frames for drones and gliders. It's undoubtedly worse than carbon fibre, I guess, but I found it interesting enough to share that you can buy especially lightweight filaments designed for aeronautic stuff.

The same way other databases do it. With join mechanics and proper query planning. You're confusing functionality with implementation.

Fair --- but I feel my criticism stands. It's awful. Don't get me started on 80% of all deployment uses of neo4j...

They're a cool feature but honestly a bit tricky to use well, IMHO. And be careful with PII lingering in a temporal void somewhere for a long time :-)

These things exist to eliminate the risk of ever serving stale information from a materialised view. I.e., their benefit is political/reputational as much as they are technical in the sense that they save you effort like remembering to invalidate a MV after an ingest operation.

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.

I mean I don't disagree with you, but they did just add a graph database feature, which is about as orthogonal to relational database design as you can get.

The graph database feature looks interesting, but I wonder...

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.

Oh no doubt. I'm no drone expert!

You know you're doing a great job, OP, when the peanut gallery here has nothing more substantial to add than to critique your em-dashes; greek-latin root word mix-ups despite the common vernacular having moved on from that; and lack of title brevity.

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.

Because numa topology is an optimisation problem with a wide solution space, and that its configuration and setup depends on the amount of physical cpus and cores; how the RAM is connected to which lanes; and on and on it goes.

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

Mhmm.

This is a really cool project. And it's so small, too, when you consider what it unlocks and the opportunities it creates.

Really awesome!

GPU speedups are welcome, but you don't need a shader and a gpu to insert a flashy effect.

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.

What? London is one of the greenest cities in the world.

Impressive work. But the problem is not the 30 tok/s which is fine for agentic coding and chat.

It's prefill; slow prefill kills agentic workloads dead.

If you have 100,000 tokens at ~150tok/s per the OP, you're looking at:

    You have: 100000 / (150/s)

    You want: hms

     11 min + 6.6666667 sec

Which is quite a wait indeed.

No the insight here is that you went _back_ and got your PhD with years of experience building professional software.

Expecting a 20-year old undergrad or a 23-year old postgrad to do as well as someone who left and came back to uni to finish their degree(s) is... uncharitable.

This test would be a lot more useful if the author used images the models obviously hadn't seen before. Pulling images from Wikipedia? They'll have seen 'em before, and the metadata, and all the pages they were casually linked to.

The premise that the long prompt only made the model think 'a second longer' may have more to do with the fact that it knows about the images. So why think harder if you know the answer?

At no point does the author contemplate that.

Indeed. Kitbashing is a thing, and it was always a thing. Designers I worked with would spend hours doomscrolling pinterest, google images, etc. looking for their, uh... 'spark' when they were given a briefing.

This is just a really cool way of building.

I'm impressed. I tried Google Stitch but it was slow and useless. Sad, because Gemini has a pretty good creative flair, ironically enough.

I'll go one further and say that if you're reaching for DISTINCT and you have joins, you may have joined the data the wrong way. It's not a RULE, but it's ALWAYS a 'smell' when I see a query that uses DISTINCT to shove away duplicate matches. I always add a comment for the exceptions.

Right. But faceting data is also part of what a good database designer does. That includes views over the data; materialisation, if it is justified; stored procedures and cursors.

I've never had to do 18 joins to extract information in my career. I'm sure these cases do legitimately exist but they are of course rare, even in large enterprises. Most companies are more than capable of distinguishing OLTP from OLAP and real-time from batch and design (or redesign) accordingly.

Databases and their designs shift with the use case.

You say that with the wisdom of experience.

But there's still value in people exploring new spaces they find interesting, even if they do not meet your personal definition of pareto-optimal.

If you're ok with a model provider that goes down all the time and has such a poor inference engine setup that once you get past 50k tokens you're going to get stuck in endless reasoning loops.

The old joke Zawinski made about picking regex "and now you have two problems" applies here.

If you pick Elasticsearch, useful as it is, you now have more than two problems. You have Elastic the company; Elasticsearch the tool; and also the clay-footed colossus, Java, to contend with.

It doesn't help that academia loooves ColBERT and will happily tell you how amazing -- and, look, for how tiny the models are, 20M params and super fast on a CPU, it is -- they are at seemingly everything if only you...

- Chunk properly;

- Elide "obviously useless files" that give mixed signals;

- Re-rank and rechunk the whole files for top scoring matches;

- Throw in a little BM25 but with better stemming;

- Carry around a list of preferred files and ideally also terms to help re-rank;

And so on. Works great when you're an academic benchmaxing your toy Master's project. Try building a scalable vector search that runs on any codebase without knowing anything at all about it and get a decent signal out of it.

Ha.

Such a fun site back in the day, and novel. There's the Erdos number version for academia.

There was that other site that tried to guess what you were thinking. It'd ask you a series of questions to try and guess --- that one was eerily good at it, too. Feels like a similar sort of thing: how quickly you can converge on a solution.

Having said that, that article seems more interested in talking about things adjacent to the Oracle of Bacon and what its author finds interesting rather than the site itself. Not sure why?