Python não é uma linguagem adequada para ciência de dados

• Em tarefas de dados não relacionadas a deep learning, como análise, visualização e resumo de dados, Python tem recursos suficientes, mas a experiência de uso tende a ficar complexa e ineficiente
• Em vários casos de laboratório, observou-se repetidamente que, mesmo para transformações simples de gráficos e cálculos estatísticos, Python tende a exigir mais código e mais tempo do que R
• Mesmo usando pandas, matplotlib e NumPy, a sintaxe, a indexação, os parênteses e a estrutura de encadeamento de métodos frequentemente fazem com que a atenção se prenda mais aos detalhes de implementação (logistics) do que à lógica
• Em contraste, o tidyverse do R expressa o fluxo de processamento de dados em um nível próximo da linguagem natural, o que facilita transformar a lógica do trabalho diretamente em código
• Como linguagem para ciência de dados, Python tem limitações estruturais na separação entre lógica e logística, e isso decorre de problemas de projeto da linguagem e do ecossistema

---

Comparação da experiência real de uso entre Python e R

• Os membros do laboratório podem escolher livremente a linguagem, mas há muitos usuários de Python, e aparece de forma consistente um padrão em que eles não conseguem responder rapidamente a pedidos simples de análise adicional
  • Até mudanças de visualização como boxplot → violin plot, histograma → gráfico de densidade, ou gráfico de linhas → heatmap não são fáceis de fazer de imediato
  • No R, tarefas resolvidas em poucas linhas passam a parecer, em Python, algo do tipo “preciso voltar para minha mesa e recodificar isso”
• Mesmo em aulas conjuntas com especialistas em Python, fica evidente uma grande diferença em extensão e complexidade do código necessário em comparação com R
  • A reação “por que isso precisa ser tão complexo?” aparece repetidamente em várias situações, e isso parece decorrer não de habilidade individual, mas de uma diferença estrutural na arquitetura da linguagem e das bibliotecas
  • Mesmo com a mesma lógica, em Python é preciso combinar indexação, separação de dados, remontagem e vários métodos, o que torna a estrutura prolixa
  • O tidyverse do R permite expressão direta com encadeamentos naturais como filter → group_by → summarize

Por que Python é tão usado, e quais são seus limites

• A posição do Python em ciência de dados se baseia mais em difusão histórica, propósito geral e tamanho do ecossistema do que em adequação intrínseca
  • Na área de deep learning, Python é claramente o centro graças ao PyTorch e ao ecossistema de IA
  • Porém, em limpeza, exploração, visualização e modelagem estatística de dados, ainda há muito atrito
• Trata-se de uma popularidade “quase como um acidente histórico”, e a estrutura mais pesada da linguagem em relação ao R aparece repetidamente em vários exemplos

O que define uma boa linguagem para ciência de dados

• Em trabalhos centrados em exploração, resumo, ajuste de modelos e visualização de dados, o mais importante é ambiente interativo, baixo custo de configuração e iteração rápida
  • Linguagens interpretadas e orientadas a script são mais adequadas do que linguagens compiladas
  • Mais do que desempenho, a prioridade é simplicidade do código, redução do risco de erros e minimização da carga cognitiva
  • Se necessário, basta reescrever apenas algumas operações em uma linguagem de alto desempenho, como Rust, em vez de tudo
• Na prática, as linguagens realisticamente consideradas são R e Python
  • Matlab, Mathematica e afins são comerciais ou têm ecossistemas limitados
  • Julia é citada com frequência, mas o autor prefere suspender o julgamento por não tê-la usado o suficiente

O problema de “lógica vs. logística”

• Uma linguagem de análise de dados deve separar o que calcular (lógica) de como calcular (logística)
  • Se for preciso se preocupar com tipos de dados, índices, loops e montagem manual, então a pessoa já está presa à logística
• No exemplo do Palmer Penguins, o tidyverse do R expressa o cálculo de média e desvio-padrão com um fluxo próximo da linguagem natural
  • Não é necessário desmontar o fluxo de dados para depois montá-lo de novo
• O pandas oferece funcionalidades parecidas, mas a especificação por strings, os parênteses, o encadeamento de métodos e tarefas auxiliares como reset_index aumentam o trabalho, prejudicando legibilidade e simplicidade
• Ao implementar a mesma tarefa apenas com Python puro
  • montar loops → criar chaves de grupo → dividir → calcular média → calcular variância → calcular desvio-padrão → remontar → ordenar etc.
  • tudo precisa ser feito manualmente, tornando-se um caso típico em que o código de logística domina a lógica

Conclusão e prévia do conteúdo seguinte

• Em análise de dados, Python revela repetidamente um problema estrutural que leva o usuário a se concentrar mais nos detalhes de implementação do que na lógica
  • Isso parece ser resultado da combinação entre características da própria linguagem, limites de projeto das bibliotecas e convenções de todo o ecossistema
• Em um texto posterior, o autor pretende tratar das causas técnicas concretas que fazem Python tornar a análise de dados mais difícil do que R

Discussões adicionais e perspectivas de comparação (incluindo feedback dos leitores)

• Há quem diga que o tidyverse pode ser mais verboso que o R básico, mas continua forte em expressividade, consistência e abstração do processamento de dados
• Por outro lado, também se argumenta que o R tem grandes desvantagens do ponto de vista de desenvolvimento de software, como modularização, testes e implementação de CLI
• Python oferece uma boa experiência para desenvolvedores em aspectos como logging, ambientes virtuais, empacotamento e estrutura de classes, mas
  • o matplotlib tem um design pouco intuitivo,
  • o pandas tem uma sintaxe inconsistente,
  • e o scikit-learn é frequentemente criticado por problemas de projeto
• Algumas opiniões veem Python como uma “linguagem que produz rapidamente código instável e de baixa qualidade”, e afirmam que, para desenvolvimento sustentável, linguagens com tipagem estática são melhores

[kaydash]

Com o aumento da complexidade e do volume dos dados, se passa a ser necessário um processamento dividido em etapas, além de tratar dados não estruturados, modelos estruturados e até processamento por meio de LLMs; como há muitos casos de uso, talvez não seja a linguagem mais adequada?

[GN⁺]

Opiniões no Hacker News

• Foram dados vários exemplos de transformações, como trocar um boxplot por um violin plot ou um line plot por um heatmap
  Na prática, essa discussão é mais sobre matplotlib do que sobre Python
  Se você quer o design do ggplot em Python, basta usar plotnine
  O motivo de o código em R parecer mais conciso é a avaliação não padrão (non-standard evaluation) do R
  Python não permite esse tipo de extensão no nível da linguagem
  Veja também Computing on the language

  • No fim, isso acaba sendo uma discussão sobre as diferenças entre Python e R
    A avaliação não padrão é conveniente em ambientes interativos, mas ao escrever código de análise mais complexo ela acaba virando uma desvantagem
    Até tarefas simples às vezes precisam ser feitas de forma indireta
  • É estranho ver código em R com o pipe no fim da linha
    Acho melhor colocar o operador pipe no começo, como em Elixir
    Python também pode imitar uma sintaxe parecida com truques como getattr, mas no fim isso é mais uma questão de design de API de biblioteca do que da linguagem em si
  • “Como seria fazer trabalho de logística em R sem bibliotecas?” Só de imaginar já parece horrível
    R só é fácil quando existem bibliotecas e receitas prontas; sem isso fica realmente difícil, e na maioria das vezes as pessoas simplesmente não fazem
  • Para esse tipo de objetivo, seaborn é apropriado
    Ele abstrai a falta de ergonomia do matplotlib e ainda oferece recursos ricos
    Tutorial do Seaborn
  • No fundo, o ponto principal parece não ser Python, mas sim falar sobre o que R consegue fazer e Python não

• Fico me perguntando por que, em linguagens de programação, tabelas não são objetos de primeira classe
  Na maioria das linguagens, é preciso aprender APIs separadas como pandas ou polars para lidar com tabelas
  Em R, data.frame chega perto de ser um objeto de primeira classe, mas na prática usa-se mais o tibble do dplyr
  Ainda não existe uma linguagem de expressão padronizada para trabalhar com dados tabulares
  Polars e dplyr compartilham uma filosofia parecida, mas no fim o SQL parece ser a única base comum
  Python não é perfeito nisso, mas acho que com R acontece o mesmo

  • Dá a sensação de que faltam muitas estruturas no nível da linguagem
    Estruturas como tabelas, matrizes, grafos e máquinas de estado não têm suporte no nível da linguagem, o que limita seu uso
    As ferramentas incluídas por padrão em uma linguagem acabam definindo o “caminho bonito” dela
    Antigamente até key-value store era algo de biblioteca externa, mas hoje virou praticamente padrão
  • Linguagens como Q, Rye e Lil tratam tabelas como tipos de dados realmente de primeira classe
    Imagino que, em algum momento, linguagens mais populares também vão absorver esse tipo de programação orientada a tabelas
    Linguagem Q, texto comparando Rye, ferramenta experimental Lil
  • tibble e data.table herdam de data.frame, então as funções básicas do R continuam funcionando normalmente
    A conversão entre os três objetos também é muito simples
  • Quando o tamanho da tabela cresce para 1 milhão, 1 bilhão ou 1 trilhão de linhas, a natureza do problema muda completamente
    Não é fácil projetar uma API padrão que lide com elegância com diferenças tão grandes de escala
  • O data.table do R é excelente
    Mas o dplyr venceu em documentação e onboarding, e por isso ganhou adoção na indústria

• A ideia central do texto é boa, mas é uma pena que o autor tenha revelado muito cedo a base da própria argumentação
  R é forte em manipulação de dataframes, mas fraco em gestão de arquivos e manutenção
  Se esse tipo de trabalho aparece bastante, Python é melhor; e, se velocidade também importa, a preferência começa a pender para Julia
  A escolha da linguagem muda conforme as prioridades
  Vejo com frequência estudantes tentando resolver problemas não tabulares, como grafos, com pandas; nesses casos é melhor repensar a escolha da ferramenta

  • O código de exemplo em Python é inadequado
    Com numpy, o cálculo de média e variância já vem pronto
    Tanto Python quanto R têm dificuldade de aprendizado parecida, mas o ponto forte de Python é a integração com outras aplicações
  • A segunda parte do texto pode ser vista aqui
  • Eu também uso Python e R meio a meio
    Para processar arquivos grandes, Python; para analisar dados resumidos, R é mais eficiente
    O certo é usar cada linguagem como a ferramenta adequada para o contexto

• Como programador de Python, também já usei R, e Python é uma “linguagem que faz quase tudo razoavelmente bem, mas sem ser perfeita”
  Se você passa o dia inteiro fazendo análise de dados, faz sentido aprender R
  R é uma linguagem projetada de acordo com a forma de pensar dos estatísticos
  No começo isso parece estranho, mas essa mudança de mentalidade acaba ajudando
  Mesmo assim, eu trabalho principalmente em Python

• Dá para fazer ciência de dados com pandas, mas achei a experiência truncada e complexa
  Com polars melhorou um pouco, mas quando comecei a usar duckdb tudo mudou
  Eu executo consultas SQL diretamente no notebook e faço análises em arquivos parquet
  Misturar células de SQL com células de Python deixa o código mais limpo
  Ao ver a comparação final entre Python e R no texto, pensei: “isso não ficaria muito melhor em SQL?”

  • Eu prefiro algo mais centrado em dataframes, resolvendo tudo dentro da própria linguagem, em vez de SQL
  • Uso polars com frequência, mas agora fiquei com vontade de testar duckdb também

• O último exemplo em Python é desnecessariamente verboso
  Usando defaultdict e statistics.stddev, ele ficaria bem mais conciso

  • Foi interessante colocar a correção de Bessel manualmente
    Muita gente implementa isso sem nem pensar se a correção faz sentido
    Na verdade, o nome correto seria sample_std_dev
  • Também daria para usar itertools.groupby
    O código não fica menor, mas expressa a intenção com mais clareza
  • O código original é mais fácil de ler
    Não vale a pena sacrificar a legibilidade só para encurtar

• Tentei implementar o mesmo exemplo em Julia com TidierData.jl, e o resultado ficou quase idêntico à versão em R
  A sintaxe de macros como @chain, @group_by e @summarize é parecida com a do tidyverse no R

• Não entendo muito bem a insatisfação do autor
  É óbvio que Python não foi otimizado para ciência de dados
  Python não é uma DSL, e até MATLAB, que foi feito para computação científica, não é uma linguagem popular
  Uma boa linguagem é mais como uma cidade boa para viver do que como um clima perfeito
  Python é como “uma cidade nórdica próspera, mas com clima ruim”
  Acho que o tema do texto é um tanto caça-cliques, então não parece uma discussão muito produtiva

• Gostaria que Julia fosse mais usada
  No passado reimplementei em Julia um algoritmo para um artigo de psicometria, e ele rodou três vezes mais rápido que em MATLAB
  Link para o artigo relacionado

  • Fico curioso sobre quanto esses 40 minutos economizados de execução realmente importaram no cronograma total de escrita do artigo

• O exemplo final não parece código Python realista, e sim uma espécie de paródia anti-Python
  Implementar desvio padrão na mão é coisa de tarefa de graduação
  Na prática, tanto R quanto Python estão rodando esse tipo de loop por baixo dos panos

  • Entendo que o texto esteja focado em um contexto acadêmico/laboratorial
    Mas, em ambientes industriais reais, Python é muito mais fácil para colaborar com equipes de engenharia
    Já tive de colocar código em R em produção, e foi bem instável
    R é excelente para análise exploratória de dados (EDA), mas inadequado para desenvolvimento de software em larga escala