Filosofia de engenharia: Guido van Rossum, legibilidade conta

Pontos principais

• Código é lido muito mais vezes do que é escrito, então van Rossum otimizou Python para o ser humano que vai ler a linha depois, não para a máquina nem para o autor naquele instante.
• O espaço em branco significativo torna a leitura honesta – a indentação que você vê é a estrutura de blocos que roda, então a aparência de um programa em Python não pode mentir sobre o que ele faz.
• “Deveria haver uma maneira óbvia de fazer algo” significa que código escrito por estranhos ainda se lê como se tivesse saído de uma única mão – a convergência em torno de um único idioma é um presente para todo leitor futuro.
• O Zen de Python é de Tim Peters, não de van Rossum – uma atribuição equivocada comum. Peters destilou valores que já estavam embutidos na linguagem.

O princípio

“Uma das percepções centrais de Guido é que código é lido muito mais vezes do que é escrito.” – PEP 8, atribuindo a percepção a Guido van Rossum¹

Essa percepção é a afirmação revolucionária mais silenciosa do design de linguagens, e quase todo mundo concorda com a cabeça e depois a ignora. Leia a frase devagar. Código é lido muito mais vezes do que é escrito. Uma linha que você digita uma vez será lida dezenas de vezes – pelo revisor que a aprova, pelo colega que a estende, pelo estranho que a herda e, com mais frequência, por você, seis meses depois, tentando lembrar o que quis dizer. Se isso é verdade, então o público do código-fonte não é a máquina nem o autor no momento da escrita. É o ser humano que o lê depois. E uma linguagem deveria ser otimizada para seu público real.

Quase nenhuma linguagem foi. As linguagens de sistema dos anos 1980 eram otimizadas para o compilador e para a máquina; as linguagens de script eram otimizadas para a conveniência do autor no momento, e é por isso que tantas delas se tornavam ilegíveis no dia seguinte ao de terem sido escritas. A aposta de Guido van Rossum foi que você poderia otimizar para o leitor – que a clareza, tornada o padrão e imposta pela própria gramática, se acumularia ao longo de uma comunidade inteira por décadas. Ele estava certo por uma margem que quase ninguém previu. O Zen de Python destila esse mesmo valor em duas palavras que todo programador Python já leu: “Legibilidade conta.”²

Essa convicção é a mesma que sustenta o argumento de que o bom gosto é um sistema técnico, e não uma vibe que você simplesmente declara. Legibilidade não é uma preferência leve que você acopla depois com um guia de estilo. Em Python ela é estrutural – embutida na sintaxe, de modo que a linguagem não deixa você escrever a versão ilegível com a mesma facilidade da versão legível. A aposta de van Rossum foi que, se você fizer da coisa clara o caminho de menor resistência, um ecossistema inteiro vai derivar rumo à clareza sem que ninguém precise mandar.

Contexto

Guido van Rossum nasceu em 31 de janeiro de 1956 em Haia, Holanda, e obteve um mestrado em matemática e ciência da computação pela Universidade de Amsterdã em 1982.³ Foi trabalhar no Centrum Wiskunde & Informatica (CWI), o instituto nacional holandês de pesquisa em matemática e ciência da computação em Amsterdã, onde a experiência formadora de sua carreira o aguardava: a linguagem de programação ABC.

ABC, projetada no CWI por Leo Geurts, Lambert Meertens e Steven Pemberton, era uma linguagem de ensino feita para ser fácil de aprender e de ler, e van Rossum passou vários anos em meados da década de 1980 trabalhando em sua implementação.⁴ ABC fez duas escolhas que ecoariam por tudo o que ele faria depois: usava indentação para marcar a estrutura de blocos – a “off-side rule”, sem chaves, sem begin/end – e tratava a legibilidade como um objetivo primário de projeto, com programas tipicamente um quarto do tamanho do equivalente em Pascal ou C.⁴ Van Rossum passou a amar a ideia da indentação; ele diria mais tarde que ela acabava com as guerras religiosas inúteis sobre onde colocar as chaves.⁵ Mas ABC também tinha falhas fatais – uma implementação monolítica, um design fechado e difícil de estender, um insularismo acadêmico que a mantinha distante dos programadores Unix de verdade. Ele havia usado a linguagem legível e visto as duas metades da lição: quais ideias eram genuinamente boas e quais eram os erros que a mataram.

Então veio a famosa história de origem, e ela realmente aconteceu do jeito que a lenda conta. “Há mais de seis anos, em dezembro de 1989”, escreveu van Rossum, “eu estava procurando um projeto de programação de ‘hobby’ que me mantivesse ocupado durante a semana do Natal.”⁶ Seu escritório no CWI estava fechado para as festas. Ele decidiu construir uma linguagem de script que conservasse as melhores ideias de ABC – a legibilidade, a indentação – e corrigisse seus erros, mirando desta vez nos hackers Unix/C que ABC nunca havia alcançado. Para o nome, “estando num humor levemente irreverente (e sendo um grande fã do Monty Python’s Flying Circus)”, ele escolheu Python.⁶ Não a cobra. O grupo de comédia. Ele lançou a primeira versão publicamente em 1991.³

O trabalho

Legibilidade e espaço em branco significativo

A decisão de projeto mais consequente que van Rossum trouxe de ABC é justamente aquela sobre a qual os novatos discutem e que os veteranos param de notar: indentação é sintaxe. Na maioria das linguagens a estrutura de blocos é marcada por chaves ou palavras-chave, e a indentação é apenas decoração que o olho humano usa e o compilador ignora. O que significa que as duas podem discordar. As chaves podem dizer uma coisa enquanto a indentação diz outra, e o código pode parecer fazer uma coisa enquanto roda outra – o clássico bug da indentação enganosa, a família de erros que produziu a infame falha de SSL goto fail da Apple, em que uma segunda linha indentada perdida ficava fora de um if que visualmente parecia contê-la.

Python torna essa classe de bug estruturalmente impossível. A indentação que você vê é a estrutura de blocos que roda. Não existe uma segunda verdade, oculta, da qual ela possa divergir. Van Rossum herdou isso de ABC porque acabava com os debates sobre posicionamento de chaves, mas o ganho mais profundo é exatamente o seu princípio: torna a leitura honesta. O que o olho do leitor percebe como o formato do programa é, por definição, o formato que o interpretador executa.⁴⁵

A estrutura honesta também é o motivo pelo qual Python tem a aparência que tem para um não programador: parece um pseudocódigo estruturado que por acaso roda. Esse era o ponto. Van Rossum, por sua própria descrição uma pessoa muito visual, projetou a superfície para ser acessível e a estrutura para ser visível, de modo que a distância entre “ler o código” e “entender o programa” seja a menor que a gramática consegue produzir.

O Zen de Python e a “uma maneira óbvia”

Em 1999, o desenvolvedor central de longa data Tim Peters registrou os valores de design que animavam Python em vinte aforismos. Eles acabaram consagrados como a PEP 20, o Zen de Python, e vêm dentro da própria linguagem: digite import this num prompt Python e eles aparecem impressos. O crédito importa e costuma ser dado errado: Tim Peters escreveu o texto, não van Rossum.² Mas o Zen é uma destilação da sensibilidade de design de Guido – Peters estava articulando os valores que já estavam na linguagem, do jeito que um bom crítico articula a intenção de um artista melhor do que o próprio artista consegue.

Duas linhas carregam a filosofia inteira. “Legibilidade conta.” E: “Deveria haver uma – e preferencialmente apenas uma – maneira óbvia de fazer algo.”² Essa segunda linha é a inversão deliberada do célebre lema de Perl, “Há mais de uma maneira de fazer algo”. A Python de van Rossum aposta no sentido oposto: uma linguagem que oferece uma maneira óbvia é uma linguagem cujo código tem sempre a mesma cara, não importa quem o escreveu, o que significa que qualquer um pode ler o código de qualquer outro. A convergência em torno de um único idioma não é uma restrição sobre o autor; é um presente para todo leitor futuro. (Até a pontuação do próprio aforismo – os travessões em torno de “e preferencialmente apenas uma” – é uma piada sutil sobre a regra ser levemente violada ao ser enunciada.)

BDFL e governança: a renúncia em 2018

Durante a maior parte da vida de Python, van Rossum teve a palavra final sobre o design da linguagem, sob um título cunhado meio de brincadeira num encontro Python de 1995 e tornado permanente por Barry Warsaw: BDFL, Benevolent Dictator For Life (Ditador Benevolente Vitalício).⁷ Era um modelo de governança real. As mudanças na linguagem fluíam pelo processo PEP – Python Enhancement Proposals, o mecanismo aberto, escrito e arquivado pelo qual qualquer mudança é proposta, debatida e decidida – mas, quando o consenso falhava, o BDFL decidia. Por décadas isso funcionou, porque o bom gosto de van Rossum era aquilo em que a comunidade confiava.

Acabou por causa de um único operador. A PEP 572 introduziu a expressão de atribuição “walrus”, :=, e o debate foi excepcionalmente amargo – van Rossum a empurrou contra uma oposição barulhenta e persistente. Em 12 de julho de 2018, dias depois de ela ser aceita, ele postou um e-mail intitulado “Transfer of power” na lista python-committers. “Agora que a PEP 572 está pronta”, escreveu ele, “nunca mais quero ter de brigar tanto por uma PEP e descobrir que tanta gente despreza minhas decisões.” Concedeu a si mesmo “umas férias permanentes de ser BDFL” e – a parte consequente – recusou-se categoricamente a nomear um sucessor (“não vou nomear um sucessor”), deixando que a comunidade inventasse seu próprio governo.⁸ E ela inventou: um Steering Council eleito de cinco membros, ratificado pela PEP 8016, agora governa Python. O ditador benevolente deliberadamente aboliu a ditadura.

O alcance de Python

A aposta na legibilidade se acumulou em um dos maiores resultados da história do software. Porque Python era a linguagem que as pessoas conseguiam ler, ela se tornou a linguagem que as pessoas conseguiam ensinar – hoje é a linguagem introdutória dominante em universidades no mundo inteiro. Porque era legível e extensível, tornou-se a cola da computação científica: NumPy, SciPy, pandas, toda a stack de ciência de dados. E porque a stack de ciência de dados já estava em Python, a revolução do aprendizado profundo também foi construída em Python – PyTorch, TensorFlow, JAX e praticamente todo modelo de que você já ouviu falar são guiados por uma linguagem que um programador holandês projetou ao longo de um recesso de Natal para ser fácil aos olhos humanos. O próprio van Rossum saiu da aposentadoria em 2020 para entrar na Microsoft e trabalhar no projeto Faster CPython, um esforço para tornar o interpretador cerca de duas vezes mais rápido – voltando, nas palavras dele, às suas raízes.⁹

O método

O método é uma convicção – otimizar para o leitor – perseguida com uma consistência incomum por trinta e cinco anos.

Otimize para o ser humano que lê o código. Não para a máquina, não para o autor no momento. Cada decisão de superfície – indentação, o pequeno vocabulário de palavras-chave, a insistência na clareza – serve à pessoa que vai ler a linha depois, porque essa pessoa é o público real e há muito mais delas.¹

Torne a estrutura visível e a leitura honesta. A indentação é a estrutura de blocos, então o que o olho percebe é o que o interpretador roda. A linguagem se recusa a deixar a aparência do código e seu comportamento divergirem.⁴

Prefira uma maneira óbvia. Resista a oferecer cinco idiomas para a mesma tarefa. A convergência em torno de um único idioma claro significa que código escrito por estranhos ainda se lê como se tivesse saído de uma única mão.²

Pegue as boas ideias e corrija os erros. Python é a legibilidade e a indentação de ABC, menos o design monolítico, fechado e inextensível de ABC. Van Rossum não inventou do nada; foi um editor criterioso do que veio antes.⁴⁵

Governe abertamente, e saiba a hora de soltar. O processo PEP tornou as decisões de design públicas e escritas. E quando ser a autoridade final passou a ser um custo para a comunidade em vez de um serviço a ela, ele se removeu – e recusou-se a ungir um substituto, forçando a formação de uma instituição duradoura em seu lugar.⁸

Cadeia de influência

Quem o moldou

ABC, e Lambert Meertens, Leo Geurts e Steven Pemberton no CWI. ABC entregou a van Rossum suas duas ideias definidoras – indentação como sintaxe e legibilidade como objetivo primário – e, ao fracassar, ensinou-lhe as lições negativas: não construa um monolito, não feche o design, não ignore o programador que está na prática. Python é a metade boa de ABC, resgatada. (Influência direta e formadora)

Modula-3. Seu design limpo de módulos e exceções influenciou o próprio design de Python, um lembrete de que van Rossum tomou de empréstimo deliberadamente de linguagens que admirava em vez de reinventar cada roda. (Influência direta)

C e a cultura Unix. C deu a Python sua linguagem de implementação (CPython é escrito em C) e seu público-alvo – os hackers Unix/C que ABC nunca alcançou. Python foi concebida para ser a camada de script legível acima de C, extensível em C, cola para um mundo C. (Influência formadora)

Quem ele moldou

A maior comunidade de programação do planeta. Python é, pela maioria das métricas, hoje a linguagem de programação mais usada do mundo, e a primeira linguagem padrão ensinada a iniciantes. Uma geração aprendeu a pensar sobre programas numa sintaxe projetada para ser lida.

Ciência de dados, IA e computação científica. NumPy, pandas, PyTorch, TensorFlow – o ferramental de toda a era moderna da IA se assenta sobre Python porque Python era a linguagem que os pesquisadores conseguiam ler e estender. A aposta na legibilidade é, indiretamente, estrutural para o campo em que eu trabalho.

Governança de código aberto. O modelo BDFL, e sua dissolução deliberada em um Steering Council eleito, tornou-se um modelo estudado de como um projeto liderado pelo bom gosto de uma pessoa pode sobreviver à autoridade dessa pessoa.

O fio condutor

Yukihiro Matsumoto projetou Ruby para a felicidade do programador e o princípio da menor surpresa; van Rossum projetou Python para o leitor. São as duas grandes linguagens da “alegria”, e são o mesmo instinto apontado para alvos ligeiramente diferentes – Matz otimiza para como se sente ao escrever, van Rossum para como se sente ao ler – e é por isso que elas convergem com tanta frequência e por que suas comunidades se reconhecem. Donald Knuth chegou ao mesmo destino vindo da academia com a programação literária: a afirmação radical de que um programa é uma obra de literatura escrita para humanos, e a capacidade da máquina de executá-lo é quase um efeito colateral. Van Rossum embutiu essa convicção na gramática de uma linguagem em vez de numa metodologia. E onde Bjarne Stroustrup colocou o desempenho de custo zero em primeiro lugar e deixou C++ crescer até virar uma linguagem que leva anos para se ler com fluência, van Rossum colocou a legibilidade em primeiro lugar e aceitou a lentidão do interpretador como o preço – dois projetistas, prioridades máximas opostas, cada um pagando na moeda que o outro se recusava a gastar. (Ponte da série)

O que eu levo disto

A lição que guardo é que legibilidade não é gentileza; é o produto de verdade. O código é lido muito mais do que é escrito, então a versão que é clara de ler é a versão que vale mais – e “depois eu limpo” é uma promessa a um leitor que estou silenciosamente traindo agora. O movimento de van Rossum é fazer da versão clara o padrão, para que fazer a coisa certa seja o caminho de menor resistência em vez de um ato de disciplina. É o mesmo padrão de a qualidade ser a única variável: a pergunta nunca é “isto roda?”, mas “a próxima pessoa que ler isto vai entender tão rápido quanto precisa?”.

No mundo em que construo agora – agentes, loops de ferramentas, prompts, código de estrutura local que outros agentes e o eu-do-futuro vão ler às 2 da manhã – a tentação é o oposto de “legibilidade conta”: one-liners espertos, estado implícito, cinco maneiras de fazer a mesma coisa espalhadas por uma base de código que ninguém consegue segurar na cabeça. O movimento de van Rossum é escolher a única maneira óbvia e tornar a estrutura honesta, de modo que aquilo que você lê seja aquilo que roda. Essa convicção – de que a clareza, tornada estrutural e imposta pela gramática do sistema em vez de deixada à força de vontade, se acumula em todos que a leem depois – é o fio condutor que liga um projeto-hobby de Natal de 1989 a uma estrutura local de agentes de 2026. O leitor é o público. Construa para ele.

Perguntas frequentes

Qual é a filosofia de engenharia de Guido van Rossum?

A convicção central de van Rossum é que código é lido muito mais vezes do que é escrito, então uma linguagem deveria ser otimizada para o ser humano que o lê.¹ Ele construiu Python em torno da legibilidade como um objetivo primário e estrutural – não uma diretriz de estilo acoplada depois, mas embutida na gramática por meio da indentação significativa, de um pequeno vocabulário de palavras-chave e do princípio de que deveria haver “uma maneira óbvia de fazer algo”.² Ele combinou isso com governar a linguagem abertamente pelo processo PEP e, em 2018, renunciar deliberadamente ao posto de autoridade final.⁸

Por que Python usa indentação em vez de chaves?

Van Rossum adotou a estrutura de blocos baseada em indentação (a “off-side rule”) da linguagem ABC, na qual trabalhou no CWI nos anos 1980; ele gostava de que ela acabava com as discussões intermináveis sobre onde colocar as chaves.⁴⁵ A razão mais profunda pela qual ela perdura é que torna a leitura honesta: em linguagens com chaves a indentação é decorativa e pode discordar das chaves, então o código pode parecer fazer uma coisa enquanto roda outra (o bug da indentação enganosa). Em Python a indentação que você vê é a estrutura de blocos que executa – não existe uma segunda verdade, oculta, da qual ela possa divergir.

Quem escreveu o Zen de Python?

Tim Peters, um desenvolvedor central de Python de longa data, escreveu o Zen de Python – os vinte aforismos consagrados como a PEP 20 e impressos quando você executa import this. Ele não foi escrito por Guido van Rossum, uma atribuição equivocada comum.² O que ele faz é destilar os próprios valores de design de van Rossum em forma memorável – linhas como “Legibilidade conta” e “Deveria haver uma – e preferencialmente apenas uma – maneira óbvia de fazer algo” articulam a sensibilidade que já estava embutida na linguagem.

Por que Guido van Rossum renunciou ao posto de BDFL de Python?

Van Rossum liderou Python por décadas como seu BDFL – Benevolent Dictator For Life (Ditador Benevolente Vitalício), um título cunhado meio de brincadeira num encontro Python de 1995.⁷ Ele renunciou em 12 de julho de 2018, dias depois da contenciosa aceitação da PEP 572 (o operador walrus :=), que ele havia empurrado contra forte oposição. Em um e-mail intitulado “Transfer of power”, escreveu: “Agora que a PEP 572 está pronta, nunca mais quero ter de brigar tanto por uma PEP e descobrir que tanta gente despreza minhas decisões”, concedeu a si mesmo “umas férias permanentes de ser BDFL” e recusou-se enfaticamente a nomear um sucessor.⁸ A comunidade o substituiu por um Steering Council eleito de cinco membros.

Fontes