chenglong-hn

5 ms·

1.
by chenglong-hn 3mo ago
no yet! that's a good direction!
2.
by chenglong-hn 3mo ago
Mostly for expressiveness and reliability & cost trade-off. Flint has advantage of being an intermediate language that allow agents to generate good-looking stuff without additional refinement loops, since the compiler derives lower-lev
3.
by chenglong-hn 3mo ago
Both, it's a combination of latency / reliability / expressivenss. I think when models are more powerful, we will also more naturally want to create more expressive stuff.
4.
by chenglong-hn 3mo ago
This is awesome!
5.
by chenglong-hn 3mo ago
We struggled the same, especially when deploying an agent to end users, they are even more frustrated with any mistakes from agents than us!
6.
by chenglong-hn 3mo ago
This is a formal language that compiler can take! The natural language and clarify loop helps the LLM to generate Flint spec that can render.
7.
by chenglong-hn 3mo ago
We made an intentional decision to make it non-compositional for now, and we are using chart-type based approach to handle more expressive charts. (e.g., CDF charts) But! We have a new project coming in to work on annotation machanism and i
8.
by chenglong-hn 3mo ago
Thanks a lot for the suggestion, I do think we will need to work on accessibility support in Flint, this is a perfect place to centrally handle accessibility issues. I added an issue to track this https://github.com/microsof
9.
by chenglong-hn 3mo ago
We will link it on github and the project page! https://github.com/microsoft/flint-chart
10.
by chenglong-hn 3mo ago
We find an additional dimension where previous language doesn't explicitly use (semantic type) as the key part of the specification, which turned out to be the root reason of why certain low-level parameters are set. Effectively Flint
11.
by chenglong-hn 3mo ago
That's the best option for now. But it can also be frustrating to ask AI to do small edits on D3 just to fix some idioms (like switching order etc) and they kept messing up with other stuff accidentally. Thus I still believe have a lan
12.
by chenglong-hn 3mo ago
I find it lacks some easy way to do alignments or grouping, which makes editing frustrating. Could be a good language re-design opportunity.
13.
by chenglong-hn 3mo ago
great point, I feel both the low-level foundation language and the high-level abstraction should evolve together, just like how human programming language evolves (e.g., frontend frameworks and libraries).
14.
by chenglong-hn 3mo ago
Yes! correctness, expressiveness, reliability and cost (token + time)
15.
by chenglong-hn 3mo ago
the design here has some constructs (i.e., semantic types) that AI can use better than human at generation time; and then the generated spec can be easy for user to edit since there is no need for hard-coded low-level parameters!
16.
by chenglong-hn 3mo ago
Also guidelines sent to the agent may or may not get ignored if they are just part of the context :(
17.
by chenglong-hn 3mo ago
more like, instead of watching the AI agent 20 minutes to create a polished chart with 100k tokens, Flint lets you get there in 20 second with 200 tokens with a 95% polished chart. :)
18.
by chenglong-hn 3mo ago
It's often comes with missing keys, use wrong value type (e.g., list over dictionaries). Mostly a small model issue and open source models, they don't follow instructions on the structure guidance that well, and there is no easy w
19.
by chenglong-hn 3mo ago
You are absolutely right. But note that we are actually on the same point here. This is exactly why this is an intermediate language designed to get 95% stuff right easily (for expressiveness and reliability purpose), while 5% of more advan
20.
by chenglong-hn 3mo ago
A little bit more than that! Here shows why a higher-level abstraction can be helpful for chart generation: https://github.com/microsoft/flint-chart#features
21.
by chenglong-hn 3mo ago
It's a white box! We built a demo here: https://microsoft.github.io/flint-chart/#/documentation/char... We use a fun elastic algorithm to decide dimension etc within the developer's constraint.
22.
by chenglong-hn 3mo ago
also user interaction afterwards -- if can be frustrating if the only way the user can interact with the chart is to chat with the agent again (simple spec allows easy UI interaction!)
23.
by chenglong-hn 3mo ago
JSON schema can do it to some degree, I think?
24.
by chenglong-hn 3mo ago
Seems a bit more like https://mermaid.js.org use cases!
25.
by chenglong-hn 3mo ago
I felt conflicted as well, json is portable and easy to parse / validate and edit. But many models do still struggle. There are some stuff from functional programming might be worth bringing back here.
26.
by chenglong-hn 3mo ago
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 n
27.
by chenglong-hn 3mo ago
I actually made a chart with Flint to show MSFT stock, and with sparkline chart to compare with other companies... :)
28.
by chenglong-hn 3mo ago
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 th
29.
by chenglong-hn 3mo ago
I do find the chartType part is not quite elegant, since templates should be more extensible. We will need to fix that. For other parts, it's quite common in visualization and diagram etc libraries to have json, since they are easily p
30.
by chenglong-hn 3mo ago
This comes with a bit of last mile issue, if just chatting with GPT in the chat panel and keep steering it, it's generally fine (as a power user). But when building it in a tool that serve end users, we are starting to see that a 80% s

More ›