I'm increasingly of the opinion that "basically a data warehouse, but incrementally maintained materialized views under the hood as an implementation detail" (e.g. Materialize, Feldera, anything based on Differential Dataflow / DBSP) is a good point in the design space. I get that they're more complicated than batch, and for many orgs the low latency isn't necessary for pure analytics/dashboards.

I wonder if there's a place for such architecture in the operational path, not just analytics. If you squint, "this microservice reads data from this operational DB and passes it to this other microservice / puts it in a cache / sends it in response to a request" looks sort of like an "ad hoc, informally specified, bug-ridden, slow"[0] implementation of incremental view maintenance (in that a cache, or a service's data model in memory, is a sort of "materialized view" over the source data). I've seen some success in replacing a tangle of imperative-languages-and-network-requests with a declarative, incrementally maintained model in SQL, if the read latency can be kept under control.

I'm curious about the "some amount of streaming influence moving back into the batch systems, particularly as object storage gives us the ability to run stateful workloads with less operational headache" part. could you expand on that?

[and yes, I do find these sort of problems interesting! :)]

[0] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

I’m not sure you have to squint; an mview is just a cached query. The only difference between an mview and a cache is the “incremental” part of the equation.

That is, my only disagreement is the lack of gusto

I’m not opposed to this but, curious, what do we gain from such reconceptualization?

It's not a new or exotic conceptualization, it's a recovery of the semantics that Codd had in mind and well defined in fact-oriented modeling approaches like object-role modeling / NIAM and FCO-IM. It provides conceptual parsimony: attributes are just relationships between entities and values, and n-ary relationships are handled consistently rather than being reduced to binary relationships, among other things. And if more people adopted this, we might get better data abstraction layers incorporated into development frameworks than object-relational mappers (which should rather be renamed to "network data model to SQL mappers").

Oh, okay, I get the value prop now. Thank you. They should hire you to write their marketing copy, you did a better job than the landing page.

Tana is basically a programming environment disguised as a text editor (in this way, it follows in the grand tradition of emacs you could say)

doh, good point. will fix this, I acknowledge I sort of handwaved the example. thanks for the correction!

yeah I mean, to be clear, I'm less proposing "What if we add even more syntax and semantics to CSS" and more "what if we steal ideas from CSS, notice their similarity to logic / relational query languages, and use them to build something new". I probably could have articulated some of this better.

eg this example:

  [data-theme="dark"] [data-theme="light"] :focus {
      outline-color: black;
  }

means, in English/pseudocode, roughly: "If you have an element X with attribute data-theme="dark", and X has a child Y with attribute data-theme="light", and Y is focused, then the outline-color of Y is black".

so we could write this also as, e.g.:

  outline-color(Y, black) if 
    data-theme(X, "dark") and
    parent(X, Y) and
    data-theme(Y, "light") and
    focused(Y)

that's Datalog, except I went ahead and replaced :- with "if" and "," with "and".

if we want even more syntax sugar, we could do:

  Y.outline_color := black if
    X.data-theme == dark and
    Y.parent == X and
    Y.data-theme == dark and
    Y.focused

imagine `X.attr == val` <==> `attr(X, val)` as a kind of UFCS for Datalog to make it palatable to Regular Programmers, right

the declaration and scope of these variables is implicit here; if you want something even more ALGOL-family, we could write

  forall Y {
    Y.outline_color := black if 
       Y.data_theme == "dark" and
       Y.focused and
       Y.parent.data_theme == "light"
  }

here we've explicitly introduced Y, and made one of our joins implicit, and it looks even more like Regular Programming now, except the Datalog engine (or equivalent) is kind of running all these loops for you, every time one of their dependencies changes, in an efficient way ...

one more, for completeness:

  SELECT 'black' AS outline_color
  FROM elements parent
  JOIN elements child ON parent.id = child.parent_id
  WHERE parent.data_theme = 'light'
    AND child.data_theme = 'dark'
    AND child.focused = true

there's a lot of ways to express the same thing! it's interesting to notice the connections between them, I think, and their strengths and weaknesses, e.g. I probably wouldn't want to write my whole design system in SQL, but since it's relational queries over the elements structure and properties, you could.

oh this is fun

> we copy and reapply patterns in different contexts and that might enable unexpected things

yeah, that's exactly what I am trying to do here. Mostly it doesn't go anywhere, but it's interesting for the hacker spirit within me :)

yeah sometimes you end up making something very cool almost by accident. i tried to make shell pipelines properly concatenative like forth and friends and that had a lot of unexpected neat digressions in metaprogramming

tbh, this started as a connection of two disparate ideas ("hey, this thing looks like this other thing"), and then just kind of explores it in different directions.

I think the conclusion (which I may not have made clear enough) is less like "These are limitations of modern CSS which ought to be fixed" and more "Maybe a CSS-like syntax could be added to a Datalog-like system and that would be helpful for making it more accessible to more engineers, navigating tree-shaped data, etc"

thanks for the feedback, anyway!

oh this is neat! Feels like exactly the sort of thing I was gesturing towards. Thanks :)

I broadly agree with you, so I want to pick your brain a bit:

What would your ideal RDBMS / tooling look like, that facilitates 6nf effectively? Do you think it's more a limitation of the query/storage engine, or the query language (SQL), or the user interface? Do you think founding on Datalog (or similar), which kinda lends itself to "narrow" relations, instead of SQL which kinda lends itself to "wide" relations, would help here?

(I ask as one of my personal hobby-horses is trying to design better query languages and tooling, and 6nf/datalog maintains a kinda special place in my heart)

Is there a good way to contact you - ideally something like IM or Teams/Slack/Zoom?

sure! You can email me at notches_hoses_58@icloud.com (throwaway email), and we could go from there?

Reply sent just now.