Is there a specific explanation about how this is better or different than vega itself? https://vega.github.io/vega/docs/specification/

My understanding is that Vega was already an expressive DSL for visualizations and its probably already well spread through LLM training data.

▲

chenglong-hn 3 hours ago | parent [-]

Vega was a high-level language in the past for human, but now they can be a bit too low-level for AI agents! AI agents have to write a lot of low-level params just to make charts looking good, and the result is that programs are hard to write reliably for AI agents.

Flint is a higher-level abstraction, with simpler much shorter spec, and the compiler derives low-level decisions so that charts are looking good.

So: flint lets agent write short program that achieving good looking charts that had to be done with lengthy program in the past.

▲

NicuCalcea 3 hours ago | parent [-]

I'm sorry, but as someone who creates data visualisation as a big part of my job, I wouldn't say the charts on the website look good. Most aren't awful either, but by no means are they an improvement over what I'd get by telling any coding agent to make a chart with Vega-Lite or Observable Plot, and probably worse than if I had some decent instructions/skills.

I don't quite get what the goal of this is other than abstracting away a little bit of the complexity at the expense of flexibility. To me, the promise of LLMs is the opposite, I can get flexibility and customisation without the cost of complexity.

▲

chenglong-hn 2 hours ago | parent [-]

Some composite charts are quite annoying to be generated well (like bullet, waterfall etc), their Vega-Lite equivalent can be quite long if just starting from scratch.

The intention here is that Flint is a simpler abstraction to get basic setups right and any followup edits can be done on top of the first compiled outputs (thus not limiting expressiveness). It also makes it easier for user to manipulate (like swapping axes, click to change something, which can be very hard if LLM generates a complex chart spec upfront).

But for many basic stuff your intuition is completely right.

▲

NicuCalcea 2 hours ago | parent [-]

That's fair, I generally make charts for publication, so I spend much more time and effort on the details. But I can understand this being useful for quick exploration for some people.

Generally speaking, I suggest anyone interested in learning to make charts get familiar with grammar of graphics [0] libraries like Vega-Lite, Observable Plot, ggplot2, Altair. There is a bit of a learning curve if you're used to selecting chart types like in Excel, but once it clicks, it gives you virtually unlimited choices in the kinds of charts you can make. And with ggplot or Observable Plot [1], it's about the same number of lines as something like Flint.

0: https://data.europa.eu/apps/data-visualisation-guide/why-you...

1: https://observablehq.com/@observablehq/plot-gallery

▲

chenglong-hn 2 hours ago | parent [-]

Grammar of graphics has been the foundation of a lot of stuff and definitely worth learning for everyone!

A challenge with GoG is that it assumes configurations as second-class stuff, which makes it quite difficult for users to deal with things like changing formatter, scale, annotations. Flint kinda want to hide this aways (so Flint sets them on behalf of the agent or the user). But yeah, GoG is still the foundation for expressivenss.

▲

NicuCalcea an hour ago | parent [-]

Can you elaborate on what you mean? Why is it more difficult to deal with formatters, scales, annotations compared with other solutions? Unless I'm misunderstanding something, the defaults are similar to what you would get in Flint, and if you want to add or customise anything, it's usually just one extra line. That's kind of the entire point of the grammar of graphics.

	▲	chenglong-hn an hour ago \| parent [-]
		https://microsoft.github.io/flint-chart/#/ The "how it works" section explains a little bit of this. For example, for the heatmap example showing temporal data, for a "good-looking" chart, we need to (1) reconcile the conflict between banded discrete steps and continuous temporal axis, and it requires understanding and setting stepsize and time parser, (2) for the correlation color, we need to set domain etc under the color axis. These are supposed to be handled automatically as system defaults, but the tricky part is that these decisions are "semantical", thus requires us to understand the data and design principles, thus existing languages won't stretch that far. And the actual good looking spec is actually over 40 lines of json spec with many low-level paramters, way beyond the simple 5 line encoding promised by GoG. Flint uses semantic type and a layout optimization algorithm to handle this, so 5 lines of encoding + data semantic types can derive rest parameters automatically. Some examples in the gallery are more extreme: like the waterfall chart example is way over 100 lines of code, and sunbusrt, rose chart are even more since compositions are quite difficult in GoG. Glad to have a discussion on this level! In fact, we wrote a paper about this, will be putting it online in a week or so!