My French is so bad

Bon matin

that's nut bad!

:man-facepalming::skin-tone-2:

No, it's nut good!

:drum_with_drumsticks:

Y'all are nuts 🙂

ya I think this is a key benefit of “data-driven” (like the directions taken in bidi and reitit etc). On the other hand maybe (?) the analog of this in the static typed functional languages are combinators (not sure)

'data is the interface' is something we say a lot in our team 🙂

Interesting, there's certainly an algebra for that

Something else I've been thinking about is how a schema is a bit like a query, and a mechanism to translate schemas to queries

Yeah. I think if we organize the code in the correct abstract level it's much easier to maintain and compose stuff.

@UK0810AQ2 you got the keyword. Many “advanced patterns” in Haskell etc (from Monad onwards) boils down to using math to make something more “algebra like” (i.e. you’ve got a bunch of operators of the form D x D x D… -> D and can pretty much freely compose with other operators)

@U04V5VAUN perhaps a bit more remark: I come across similar “pattern/thoughts” of using data-driven + function that generate data to tackle complex SQL query by making it possible to implement abstractions and then compose (like the by-name function above), and have loved it since then…

… alas, times have changed. If you’re stuck in legacy SQL/RDBMS, then that’s pretty much still almost the state-of-the-art to the best of my knowledge (perhaps generating query guided by the schema is more cutting edge). Then come datalog (and alternative DB architecture) and everything changed.

(speaking of which, the walkable library is worth taking a look at)

(Reason for “everything changed” - imo, although I previously conceptualised the query language and the underlying/physical architecture as two separate component of a DB, I later changed my view into “they are different aspects, but can be tightly coupled” and “in the best case, innovations in these two are synergistic” )