Python e o caminho do meio

A maneira como Python trata variáveis faz muito sentido, e exemplifica uma característica que eu gosto muito na linguagem: a opção pelo caminho do meio.

A maioria das linguagens segue um de dois caminhos extremos no tratamento de variáveis.

Um dos caminhos é aquele que exige que cada variável seja declarada, como ocorre em C, Pascal, Java etc. O curioso é que várias linguagens obrigam o programador a declarar uma variável, mas nem todas elas obrigam o programador a inicializar a variável antes de usá-la, o que gera bugs que às vezes são difíceis de achar.

Ou seja, tornar obrigatória a declaração da variável é algo que facilita a vida do compilador, mas não necessariamente resolve o problema do programador. Claro que os compiladores modernos reclamam quando encontram variáveis que nunca foram inicializadas em expressões, mas isso é um remendo.

O outro caminho, radical na direção oposta, é o das linguagens que não obrigam a declaração da variável e nem a sua inicialização. É uma tentativa equivocada de simplificar a vida do programador. Linguagens que seguem essa linha são JavaScript, PHP, Perl, Basic e outras chamadas "linguagens de scripting". Em algumas delas (Perl, VisualBasic) você pode mandar o interpretador reclamar quando encontra uma variável não declarada, mas esta opção não costuma ser o default. Em alguns casos a variável não inicializada tem um valor especial como "undefined" ou "null".

Nestas linguagens, a ocorrência de uma variável não inicializada em uma expressão geralmente faz com que ela seja avaliada com algum valor default, tipo 0 (zero) se for uma expressão numérica ou "" (string vazia) etc. Tudo isso faz com que ocorram bugs muito chatos de encontrar, porque se o nome de uma variável é soletrado incorretamente, o programador não é avisado e um valor sem sentido é introduzido no programa. Em projetos grandes, isso se torna um problema muito grave, e é um dos motivos pelos quais os adeptos de abordagens mais rigorosas consideram que as linguagens de scripting não são "sérias".

Python escolheu o caminho do meio, o mais sensato na minha opinião. Não é preciso declarar variáveis, até porque tal declaração não teria muita utilidade em uma linguagem de tipagem dinâmica onde o tipo está vinculado ao objeto, e não à variável. Mas Python exige que você inicialize uma variável antes de usá-la. Veja:

>>> b = a + 1
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

Então isso obriga você a escrever:

>>> a = 3
>>> b = a + 1
>>> print a, b
3 4

Note que como toda variável precisa obrigatoriamente ser inicializada, isso é mais útil do que a exigência de que ela seja simplesmente declarada. Porque evita valores inválidos, e o momento da atribuição acaba funcionando como uma declaração também.

O modo como Python lida com identificadores, não só neste aspecto, mas também no seu sofisticado sistema de namespaces, evita conflitos de nomes e é um dos fatores que torna Python atraente para projetos de larga escala. Ruby adota a mesma filosofia de Python quanto à inicialização de variáveis, mas não tem o suporte a namespaces.

Este é apenas mais um exemplo de como Python é uma linguagem "simples e correta", como definiu meu amigo Geraldo Coen.

Python vai migrar para Mercurial. Uebaaa!!!!

Perdõem a falta de objetividade no título, mas eu adorei esta decisão dos core developers da linguagem Python: entre os principais sistemas de controle de versão distribuídos, o Guido van Rossum optou pelo Mercurial, também conhecido como Hg, seu símbolo na tabela periódica.

No primeiro dia da conferência o Brett Cannon (perfil no Ohloh) fez uma palestra relâmpago explicando que os desenvolvedores do Python haviam decidido migrar do sistema de controle de versão atual, o Subversion, para um DVCS (sistema distribuído de controle de versões) e que ultimamente três sistemas tinham sido avaliados: Bazaar, Mercurial e Git.

Na mesma palestra-relâmpago, Brett disse que o Git havia sido descartado por ser o menos popular entre os principais desenvolvedores da linguagem Python e por não ser adequadamente suportado no Windows. Também pesou, mas não foi decisivo, o fato de que o Mercurial e o Bazaar são escritos em Python com partes em C, mas o Git é praticamente C puro com alguma coisa escrita em Perl. O vídeo da primeira sessão de palestras relâmpago, incluindo esta do Brett Cannon, já está no Blip.tv.

Chegando no Hg

Uma vez descartado o Git, foram apenas mais dois dias de suspense até que o Guido anunciou sua decisão favorável ao Hg, baseada principalmente nas preferências pessoais dos core developers que lhe enviaram e-mails ou twittaram sobre o tema. Segundo ele, o Git tem muitos fãs mas também um alto índice de rejeição, e o Hg tem ainda mais fãs que o Bazaar, com menos oposição. Então é isso, Mercurial na cabeça!

Gostei muito dessa escolha, porque passei bastante tempo tentando me acostumar com a idéia de usar um DVCS em vez do Subversion. Inicialmente brinquei com o Bazaar, mas só entendi realmente a idéia quando experimentei o Mercurial. Não sei se é a documentação dele que é melhor, ou seus comandos fazem mais sentido para mim, mas o fato é que com o manual do Mercurial a coisa toda finalmente fez sentido para mim.

Na verdade, eu vou mais longe, acho que aprender a usar o Mercurial é mais fácil que aprender a usar o Subversion, então se você ainda não usa um sistema de controle de versões, chegou a hora de começar!

Git e eu

Depois que eu já havia adotado o Mercurial eu resolvi aprender o Git porque estava na moda, e muita gente que eu respeito falava muito bem dele. Achei a documentação do Git horrenda, e suas mensagens de erro estão entre as piores que eu já vi. Ele foi desenvolvido pelo Linus e outros kernel hackers para uso próprio, e a documentação deixa claro que eles não se importam minimamente se meros mortais vão usar a ferramenta. Daí a comunidade Rails adotou o Git e com seu talento evangelista transformaram o Git em mais um ritual de sua religião.

Acontece que a maioria dos defensores do Git que eu conheço nunca experimentaram o Mercurial, e quase todas as vantagens do Git que eles apregoam por aí se aplicam perfeitamente ao Mercurial e até ao Bazaar.

Para mim as únicas vantagens objetivas do Git sobre o Mercurial são o desempenho e o Github.

A vantagem do desempenho é relativa, porque a gente não gerencia milhões de linhas de código como o Linus e os kernel hackers, então na prática isso significa que o Git faz em 0.01s algo que o Hg leva 0.1s para fazer.

Só que esta vantagem é anulada pelas armadilhas anti-usuário do Git. Cada vez que você perde 20 minutos tentando desfazer um erro lutando contra a interface hostil do Git, lá se vão 1200 segundos, ou seja, você acabou de perder a vantagem de desempenho equivalente a milhares de operações!

O Github é muito legal pelo seu componente social (virou uma espécie de Orkut de programadores), e continua sendo a melhor razão objetiva para usar o Git.

Agora com essa decisão da comunidade Python, o Bitbucket.org deve ficar mais popular, e funcionalmente ele é bem parecido com o Github.

Tentei muito gostar do Git, mas estou muito contente por poder deixá-lo de lado e voltar a me concentrar no Mercurial.

Na órbita de Mercurial

Vale notar que o Hg também foi adotado pelos core developers da linguagem Java e do projeto Mozilla (Firefox), então estamos na companhia de mega projetos (lista de usuários do Hg).

Com a adesão da comunidade Python ao Hg, vou migrar meus projetos relacionados a Python do Github para o Bitbucket.org. Nos vemos lá!