thats important! but how do the error messages compare with a decent compiler? youre gonna have more errors in your llm corrective edits loop if you dont hew to that tier of clarifying.
to be clear: youre taking this feedback wonderfully well and i appreciate that maturity :).
im just cranky with the current opportunity market and mucking with attacking a classical markov chain conjecture while i hurry up & wait to hear back from places XOR slowly build some stuff in the harness space that i hope can hit the equivalent of sublime text tier but for harnesses (is there even a market for a prosumer/pro tier harness, im not sure!)
Fair hit on "language". I keep forgetting YAML stands for "YAML Ain't Markup Language". What we built is a declarative spec written in YAML, and that's deliberate. Think of it as HTML for boards rather than a programming language. The tradeoff is readability and structure versus flexibility.
That lack of flexibility is actually a feature for one of the bigger problems we're solving: lineage, or knowing where a number came from. If the chart layer can't transform data, the logic stays in SQL, where you can version, test and audit it.
It's also a choice about who this is for. The data community already works in SQL, Jinja and YAML every day, so there's no new language to learn.
I've worked in data for 15 years and I've never heard this argument. I love it :)!
Who knows, with AI this may be the future. Visualizations were created to help us understand data. Florence Nightingale published them "to affect thro' the Eyes what we fail to convey to the public through their word-proof ears."
Often a formula better represents a situation. But I'm not sure how much impact they'd have in spreading that understanding outside of a formula-minded audience.
I worked deep in big data briefly. Billions is too big for humans so we got creative how we visualized and filtered.
AI slop has a "smell" meaning there's an abstracted data filter that results in rose or poop output. Shakespeare variable says the name doesn't matter.
So this is a fairly domain specific (dashboards) spec and we intentionally avoid getting too generic.
The raw HTML/SVG or base libraries approach may well win out, but it does make it quite hard or impossible for humans to follow along and verify for instance where the numbers on a chart came from.
I think in a future where AI's doing all that verifying (or we just trust it), the AI might still prefer to use a DSL like ours because the abstraction maintains consistency, lowers maintenance, and saves a lot of tokens.
But the most helpful bits of a structured DSL are for sure still for humans. The structured format ensures things are readable and testable. Ours also enables a generative UI, which for now at least is still a much faster way to make visual edits while working with an AI, vs always through it.
I think we're still ways out until companies will blindly trust AI that the data they pulled is correct. If a data team member sees a dashboard or chart, their first questions is "Is the SQL below this chart correct?". The easier it is to see the SQL that pulled the data, the better.
Hi HN, I'm Dave the founder of Chartio (YC'10 now Atlassian Analytics), announcing today dbt Charts, an open source YAML dialect and tool for declaring and rendering dashboards.
When making dashboards with claude or other agents, a lot of free-form artifacts are created that makes it hard to audit and scale. dbt Charts is a simple YAML dialect that declares and renders a chart (think markdown but for dashboards). Along with dbt its Apache 2.0 and launched today.
We hope this language + AI help make the BI space more open with dashboards as concise auditable code. Would love any thoughts and feedback.
We already have variables and links (which work with variables)[1]. Variables create interactive menus that update urls, queries and charts. If you have a variable `region` and you set it the url will add a get param ?region=<value>
Each chart also has a basic `link:` property can use to link to the existing or other urls with the variables set. For example
type: bar
x: revenue
y: region
link: '?region={{ region }}'
The result is a big range of flexibility, for example [2] here's an example of Conways Game of Life inside of dbt Charts.
I assume the goal is to get rid of all foreignObject uses eventually? (Otherwise it would be easier yo render one big foreignObject and convert everything to HTML)
Anyways, impressive, but what I’d really love to see is flexbox for SVG ;)
Yeah, my use case would have required a heavy node or playwright import to convert the SVGs to other formats or show them correctly outside of browsers. This keeps it all SVG and it looks and feels good and lighter.
I love that the recipe example is still being used as one of the main promising use cases for computers and now AGI. One day hopefully computers will solve that pressing problem...
> dct validate <file.yml>
Or any of the other commands that read the file will quickly fail with any syntax or SQL issues. It’s not just an open schema.
reply