Flint — Linguagem de visualização para a era da IA

 (microsoft.github.io)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Flint é uma linguagem de visualização que decide automaticamente parsing, eixos, formatação e cores com base no significado dos campos de dados, permitindo criar e modificar gráficos sem configurações de baixo nível
  • Infere as configurações detalhadas necessárias para a codificação visual a partir de tipos semânticos (semantic types) como Rank, YearMonth, Delta e Temperature
  • Ajusta tamanho, espaçamento e posicionamento com um modelo de layout elástico e princípios de banking; quando um gráfico cresce, expande o canvas e reduz a largura das bandas para lidar com composições mais densas
  • Suporta 50 tipos de gráficos em Vega-Lite, ECharts, Chart.js e Plotly, e também gera gráficos nativos do Excel editáveis via Office.js
  • Em uma única interface, permite alternar backends e aproveitar os pontos fortes de cada ferramenta, como sunbursts hierárquicos do ECharts, traces estatísticos e analíticos do Plotly e edição dentro da pasta de trabalho no Excel

Especificação baseada em semântica e otimização automática

  • O Flint infere parsing, escalas, eixos, formatação e esquemas de cores a partir de tipos semânticos que representam o significado dos campos de dados, como Rank, YearMonth, Delta e Temperature
    • Em um heatmap que mostra a variação líquida de novos usuários por jogo e por mês, game é definido como Category, period como YearMonth e newUsers como Profit
    • De acordo com a semântica definida, ele decide automaticamente o parser de valores temporais, a formatação dos eixos, o esquema de cores divergente e o ponto médio
  • A otimização automática de layout aplica um modelo de layout elástico e princípios de banking para gerenciar dinamicamente tamanho, espaçamento e posicionamento de acordo com o canvas
    • Quando um gráfico de barras agrupadas cresce de uma composição esparsa 5 × 3 para uma composição densa 22 × 3, ele expande o canvas e reduz a largura das bandas
    • Funciona de modo semelhante a molas se acomodando dentro de um contêiner expansível
  • É possível mudar o design apenas com a troca do tipo de gráfico e a religação da codificação visual, sem lidar diretamente com parâmetros frágeis de baixo nível
    • Um gráfico de barras facetado que mostra a distribuição da população dos EUA em 2000 por sexo e idade é convertido em um gráfico de pirâmide apenas trocando o tipo de gráfico; o restante das configurações de baixo nível é tratado pelo compilador

Suporte a backends e lançamentos recentes

  • Suporta 50 tipos de gráficos em Vega-Lite, ECharts, Chart.js e Plotly, e a galeria tem 121 exemplos por backend
    • A interface unificada oculta APIs e modelos de programação diferentes de cada backend
    • O ECharts pode ser usado para sunbursts hierárquicos, e o Plotly para traces estatísticos e analíticos
    • Via Office.js, gera gráficos nativos do Excel que podem ser inseridos e editados em pastas de trabalho
  • v0.4.0 adicionou, em 24 de julho de 2026, 38 tipos de gráficos Plotly e 18 templates de gráficos nativos do Excel editáveis
  • v0.3.0 adicionou, em 19 de julho de 2026, um widget de gráfico dinâmico para alternar tipos de gráfico e modificar propriedades no próprio local
  • A v0.2.2 adicionou, em 15 de julho de 2026, o modo compact dodge e layout de violin agrupado

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • Mesmo na era da IA, considero a API do ggplot a melhor API de gráficos. “Grammar of Graphics” não era só um slogan de marketing, mas uma tentativa real de criar uma gramática capaz de expressar todos os gráficos qualitativos possíveis
    Esse processo está registrado em https://link.springer.com/book/10.1007/0-387-28695-0. Encontrei esse livro ao pesquisar gráficos antigos feitos em papel e caneta; os gráficos dos relatórios anuais do Banco Central da Austrália das décadas de 1960 a 1980 tinham personalidade, enquanto no começo dos anos 2000 foram substituídos por gráficos sem graça do Excel
    Mesmo que o ggplot não recrie totalmente o charme dos gráficos antigos, parece ter se inspirado bastante na forma como eles transmitiam informação. A seção 20.1 recria o gráfico de Minard sobre a campanha de Napoleão na Rússia, e um exemplo parecido pode ser visto em https://www.andrewheiss.com/blog/2017/08/10/exploring-minard...
    O resultado visual é melhor do que o do pyplot e das APIs construídas sobre ele, e o pyplot parece ter limitações grandes em renderização baseada em raster e no tratamento de texto. O ggplot está no ecossistema R e por isso é menos conhecido entre engenheiros de software, mas eu gostaria que os ecossistemas de Node.js e Python se inspirassem mais nessa API

    • O Grammar of Graphics de Wilkinson foi a inspiração para o ggplot, e esse livro nem sequer menciona o ggplot
      Também publiquei o Algraf, uma DSL criada com a mesma filosofia: https://williamcotton.github.io/algraf/demos. As demos incluem o gráfico de Minard
    • Vale a pena conferir também o plotnine para Python: https://raw.githubusercontent.com/rstudio/cheatsheets/main/p...
      Ele foi desenvolvido no ecossistema da RStudio, onde Hadley Wickham, criador do ggplot, trabalhava, e hoje recebe apoio da Posit, onde ele trabalha atualmente
    • A especificação JSON do backend Vega-Lite também segue em grande parte as ideias do Grammar of Graphics. Gostei mais do ggsql que apareceu recentemente no HN: https://ggsql.org/
    • A semântica do Grammar of Graphics já é ideal tanto para humanos quanto para agentes. O ggsql implementa isso como funções definidas pelo usuário em SQL, então os agentes conseguem lidar com isso mais facilmente; por isso, não sei o que mais o Flint oferece
    • Se você quer um charme de desenho à mão e está disposto a usar METAPOST, existe o fiziko: https://github.com/jemmybutton/fiziko

  • Testei tanto o Flint quanto a abordagem de fazer a IA gerar diretamente especificações Vega-Lite, e o Flint não foi uma solução melhor
    O Flint é aceitável para personalizar em baixo nível tipos de gráfico predefinidos, mas, quando agentes ou subagentes criam diretamente uma especificação Vega, dá para obter visualizações bem mais flexíveis e de maior qualidade, como marcar mínimo e máximo em séries temporais ou adicionar anotações em datas de eventos específicos
    Ainda assim, o Vega-Lite exige validação de especificação e instruções concretas, além de lidar continuamente com bugs e comportamentos estranhos. Se a ideia é começar rápido sem construir a criação de gráficos como uma tecnologia separada, o Flint é mais estável

  • Parece uma tentativa de tratar vários backends de gráficos com uma única interface, mas, se a IA consegue escrever Flint, não faria mais sentido fazê-la escrever o código do backend diretamente? Não está claro por que seria necessário tornar o backend intercambiável
    Ainda assim, se a ideia for uma API simples para LLMs, há a vantagem de melhorar a eficiência de tokens

    • Cada backend de gráficos suporta tipos diferentes. Se, como no exemplo do projeto, fosse fácil alternar entre um sunburst do ECharts e um gráfico de barras facetado do Vega-Lite, isso seria muito útil

  • O Microsoft/Flint-Chart também foi apresentado em 2 de julho de 2026: https://github.com/microsoft/flint-chart, https://news.ycombinator.com/item?id=48756577
    Em 8 de julho, voltou a aparecer como “Show HN: Microsoft releases Flint, a visualization language for AI agents”: https://microsoft.github.io/flint-chart/#/, https://news.ycombinator.com/item?id=48834924

  • Qual é exatamente o problema de simplesmente pedir “faça um gráfico XYZ em plotly”?

    • Em visualização de dados automatizada, esse método exige um sandbox para executar o código JavaScript ou Python gerado. Com uma especificação como a do Flint, dá para validar primeiro e renderizar em seguida; se o LLM gerar Flint melhor do que Vega-Lite, isso pode ser útil

  • Houve uma discussão maior sobre isso também 22 dias atrás: https://news.ycombinator.com/item?id=48834924

  • Uma DSL para IA não parece muito justificável. Os modelos foram treinados com bibliotecas gráficas existentes e já lidam com isso razoavelmente bem
    No longo prazo, depois de lançar o Flint, até daria para laboratórios criarem um “benchmark gráfico” para fazer overfitting nessa DSL, mas isso parece exigir trabalho demais

  • Não sei a partir de que ponto a abstração passa a ser excessiva. Fico em dúvida se Plotly ou Plotly Express já não bastam, e como mais uma especificação JSON abriria uma nova era

  • É interessante, mas não sei se é realmente necessário. Já existem muitas bibliotecas de gráficos maduras, incluindo Apache ECharts, e no fim isso parece apenas reinventar a roda
    Um novo instrumento é lançado, funções continuam sendo adicionadas, e depois outro instrumento com design e sintaxe um pouco diferentes acaba substituindo o original — esse ciclo se repete
    Também dá para aproveitar as vantagens específicas de cada backend: ECharts para sunbursts hierárquicos, Plotly para rastros estatísticos e analíticos, Excel para gráficos que serão editados dentro de uma planilha. Ou então escolher uma biblioteca de gráficos de que você goste e aprender seus recursos de verdade, em vez de misturar apenas presets de várias bibliotecas sem ajustar os detalhes