Existe um encanto particular nas palestras de aceitação do Prêmio Turing. Enquanto a maioria dessas conferências se resume a formalidades e banalidades, algumas se destacam como verdadeiros manifestos. John Backus, em 1977, questionou se a programação poderia ser liberta do estilo von Neumann, inspirando paradigmas que originaram linguagens funcionais como Haskell. Kenneth Thompson, em 1984, demonstrou os perigos de compiladores adulterados em sua reflexão sobre a confiança. Edsger Dijkstra, em 1972, advertiu sobre os perigos da esperteza excessiva.
Para o tema em questão, merece destaque a palestra de 1979 de Kenneth Iverson, Notation as a Tool of Thought (Notação como Ferramenta do Pensamento). Iverson demonstrou que notações matemáticas não são apenas abreviações convenientes, mas ferramentas que possibilitam novas descobertas. O matemático Alfred North Whitehead exprimiu essa ideia com clareza: ao aliviar o cérebro de trabalho desnecessário, uma boa notação permite que ele se concentre em problemas mais avançados.
Iverson recebeu o Prêmio Turing pela linguagem APL, uma linguagem de programação peculiar que começou como um sistema de notação para unir linguagens. Nos primórdios da computação científica, os programadores precisavam pensar em uma linguagem (notação matemática) mas programar em outra (como Fortran). O APL foi projetado para que operações complexas pudessem ser escritas de forma tão compacta quanto equações. Embora tenha sido mais influente do que adotada, a linguagem demonstrou que duas linguagens poderiam ser fusionadas em uma.
O ano de 2026 marca sessenta anos desde a introdução do APL, e um novo tipo de problema das duas linguagens atormenta o campo da computação científica. A linguagem dominante é o Python, mas ela reigns não como um conquistador robusto, mas como um rei decadente. O Python, em outras palavras, é terrivelmente lento — uma falha que até seus defensores mais ardorosos não negariam.
Daí surge o problema: pesquisadores prototipam em Python, lento e amigável, mas para partes críticas de desempenho, reescrevem em linguagens mais rápidas, porém menos amigáveis, como C++ ou Rust. Essa limitação não pode ser resolvida por agentes de programação com inteligência artificial, porque por mais que você otimize uma linguagem lenta, uma mais rápida sempre será superior.
Em 2012, quatro cientistas da computação com sólida formação matemática se reuniram para abordar o problema moderno das duas linguagens. Em um breve ensaio chamado Why We Created Julia (Por Que Criamos a Julia), eles declararam que embarcaram no projeto “porque somos gananciosos”. O texto começa como uma carta de amor às linguagens de programação: “Somos usuários avançados de MATLAB. Alguns de nós são hackers de Lisp. Outros são pythonistas, rubyistas, ou programadores de Perl… Geramos mais gráficos em R do que qualquer pessoa sensata deveria. C é nossa linguagem de programação da ilha deserta.”
Mas cada uma dessas linguagens, escreveram eles, “é perfeita para alguns aspectos do trabalho e terrível para outros”. Ganciosos como eram, queriam “uma linguagem de código aberto, com licença liberal… Algo simples de aprender, mas que mantenha os hackers mais sérios felizes.” A Julia seria a linguagem única para uni-los.
A primeira encounters com a Julia ocorreu por acaso em 2017, um ano antes de sua sintaxe estabilizar, quando o autor assistiu a palestras de Sebastian Seung, um neurocientista que a usava para mapear conectomas, o mapa completo das vias neurais no cérebro. A primeira impressão foi do nome encantador, que desafiava a nomenclatura desajeitada comum na área: o inelegante PL/I, o feio Erlang, o tipograficamente desajeitado C++ e o literalmente patológico MUMPS.
Também ficou evidente que pensamento sério foi aplicado no projeto da Julia. Após estudar os muitos perigosos nos quais outras linguagens cairam, os criadores reuniram ideias organizadas de diferentes linguagens — um testamento de que observação cuidadosa deve preceder a empreitada de criar uma nova linguagem.
Em 2026, a Julia atraiu uma comunidade sóbria de adultos — o que não pode ser dito de muitas comunidades de linguagens. Entusiastas de linguagens são um grupo emocional e barulhento (muitas amizades foram rompidas por diferenças de opinião sobre sintaxe), mas a comunidade Julia ainda não foi agitada por nenhum drama importante. Ela tende ao acadêmico, atraindo mais cientistas do que hackers. Mas diferentemente de outras linguagens também usadas por acadêmicos, a Julia não se torna muito extravagante (como Haskell), nem atrai fãs adoradores (também como Haskell) ou se envolve em jogos intelectuais.
Na conferência anual Julia-Con, você ouvirá histórias triunfantes de reescrita de código MATLAB em Julia com ganhos de velocidade de sessenta vezes. Em algumas comparações, código em Julia pode rodar de dez a mil vezes mais rápido que Python.
Mas você não encontrará a Julia nos gráficos anuais de linguagens mais populares do Stack Overflow. Ela não substituiu o Python, no final — nem de perto. Por quê? O que deu errado?
Primeiro, assim como uma linguagem humana depende do corpo de textos escritos nela, uma linguagem de programação só é tão boa quanto seu ecossistema e ferramentas. O ecossistema do Python é robusto demais para ser deslocado. Segundo, a Julia não foi adotada pelas grandes empresas de tecnologia. No passado, quando uma linguagem menor foi tirada do obscurity e alcançou proeminência, foi graças a esse tipo de patrocínio corporativo: Objective-C pela Apple para desenvolvimento de iOS, Kotlin pelo Google para desenvolvimento de Android.
Terceiro, e esta é a resposta: nada deu errado. A Julia é uma linguagem niche, e para o que faz, é bastante bem-sucedida. Provavelmente, a Julia continuará existindo, pequena mas amada. É usada para trabalhos monumentais em instituições como ASML, CERN e NASA e em empreitadas sérias como descoberta de medicamentos e aprendizado de máquina avançado.
Mesmo que a Julia substitua o Python algum dia, não estou convencido de que possa resolver o problema das duas linguagens — ou que qualquer linguagem possa. Embora o problema seja comumente citado na computação científica, existe em todos os domínios de software. Em jogos, motores são escritos em C++ mas escritos em Lua. Em servidores, há uma variedade de linguagens mais fáceis — Python, Ruby, JavaScript — mas quando desempenho real é necessário, o trabalho é feito em Go ou Rust. Por outro lado, esforços valentes para usar Go ou Rust no desenvolvimento de front-end falharam completamente.
Mas quem sou eu para dizer que ficaremos presos aqui para sempre? Talvez algum dia alguém tão perspicaz quanto Iverson descubra como preencher a lacuna de uma vez por todas. Quando isso acontecer, certifique-se de acompanhar a palestra de Turing.
Fonte: Feed: All Latest
