devlog

Alguns dias atrás, alguém fez a seguinte busca no google: "Pylons é melhor do que turbogears?" e acabou caindo aqui no blog. Dizer qual entre dois frameworks é o melhor é uma tarefa difícil, e pode causar convulsões em algum fanboy (talvez não seja o caso, já que ambos estão ficando em segundo plano por causa do Django, ao menos aqui no Brasil). Porém isso não nos impede de dar uma pequena olhada nos pontos em que esses frameworks se diferenciam e onde está o poder de cada um deles.

Ok, depois de compilar o v8, eu pensei: e agora? Após ler sobre o tracemonkey, minha idéia caiu no seguinte: eu compilo o tracemonkey e faço testes com ambos.

Eu adaptei o shell script que roda o benchmark do tracemonkey para rodar o mesmo benchmark, só que usando o v8.

Sobre as duas VMS:

• O líder do desenvolvimento do V8 é Lars Bak, que foi o líder técnico do Strongtalk e do HotSpot (Java) e também um grande contribuidor da maquina virtual original do Self. Segundo o projeto, o V8 é otimizado para acesso de propriedades e tem um coletor de lixo agressivo.
• O Tracemonkey usa código do Tamarin, a máquina virtual de JavaScript da Adobe, que doou o código para a Mozilla Foundation. A otimização e o JIT é feito usando um processo chamado Tracing Trees. Se você estiver disposto a ler um paper comprido, complicado e interessante, pode ler o Incremental Dynamic Code Generation With Trace Trees.

No geral, o tempo total dos testes foi menor para o tracemonkey, embora comparando os quadros, não teve uma máquina virtual que tenha vencido em todos os testes.

Os testes foram feitos usando a revisão 110 do v8 (disponível em http://v8.googlecode.com/svn/trunk) e a revisão db4260e7ee13 do tracemonkey (disponível em http://hg.mozilla.org/tracemonkey/), e foi usado o próprio benchmark do tracemonkey para testar as duas VMs.

Agora a pouco, eu refiz os testes com as últimas versões das máquinas virtuais, e os resultados se alteraram um pouco:

Diferente do teste do Brendan Eich, foi testado apenas VM e não o desempenho dela dentro do navegador, mas no geral, os resultados do meu teste aqui condizem com o dele.

Mais sobre o v8 e assuntos relacionados

• Benchmarks no Google Chrome (Alexander Limi)
• Ruby rodando no V8
• Tentando aplicar várias técnicas dos novos runtimes de JS para as linguagens dinâmicas da JVM - discussão na lista JVM-Languages, uma lista que agrega muitas pessoas que estão trabalhando em linguagens dinâmicas na JVM (JRuby, Jython, Scala e muitas outras).
• Lua JIT x Javascript

Desenvolvimento web hoje em dia é quase sinônimo de algum tipo de framework. Mesmo PHP, que é por tradição uma linguagem com tendência à certa desorganização, tem se adaptado e bons frameworks tem surgido nessa linguagem.

Minha linguagem preferida, como todos sabe, é Python. E nesse universo, frameworks é o que não faltam. O momentum agora é do Django, mas Zope/Plone tem seu espaço garantido. TurboGears já alcançou alguma reputação. Até o minimalista webpy tem o seu lugar. Nessa miríade de opções, a minha escolha recaiu sobre o Pylons. Assim como o TurboGears, o Pylons não é um framework full-stack, mas se define como um código cola entre outros componentes. Provavelmente, o Pylons seja melhor definido como um meta-framework do que como um framework. Talvez fique num lugar intermediário entre os dois, e já explico o por quê.

Uma das coisas que eu penso que define um framework é o fato de que ele toma decisões por você. Como é dito no jargão Rails, um framework é um software com opnião. O Rails já pressupõe que você usará o ActiveRecord, assim como o Django pressupõe que você usará o ORM do Django – que eu penso que já merecia um nome. O admin do Django depende de você usar o ORM do Django. É até possível que você use SQLAlchemy com o Django, mas perderá o admin, que é uma ferramenta poderosa. Essa á uma decisão mais ou menos incontestável que o framework tomou por você.

Já com o Pylons, a quantidade de decisões que o framework toma é miníma. A premissa básica é que tudo gira em torno de WSGI e seus middlewares. WSGI define um padrão de comunicação entre o servidor web que você for usar (por exemplo, o Apache) e o framework que você for usar. Mas também define que diversas camadas de possam ser encapsuladas dentro da sua aplicação antes da resposta ser entre ao servidor. Esse é um ponto central no Pylons, tão central atualmente que o controlador básico do Pylons é o WSGIController e todos os seus controladores estendem dele.

Fora isso, o seu projeto criado com o Pylons tem uma pasta model, mas não define se você deve usar SQLAlchemy, Storm ou a DB-API diretamente. O SQLAlchemy trabalha com o padrão DataMapper e você não gosta disso? Tudo bem, você pode escolher usar o Elixir, uma pequena camada que empacota o SQLAlchemy como ActiveRecord. Pylons não opta por nenhuma biblioteca JavaScript, embora o módulo Paginator possua extensões para as principais bibliotecas de JavaScript disponíveis atualmente. Não existe uma forma padrão de se construir formulários. Você pode ir desde o simples HTML, sendo validado com formencode, passando por ToscaWidgets e chegando até o formalchemy, mas nada disso é obrigatório. Você pode usar o Authkit como uma forma de implementar autenticação – e fique avisado que ele tem uma má-fama na comunidade, pelo menos no canal #pylons do FreeNode –, ou pode implantar a sua própria forma de autenticação. Como template, você pode escolher entre Mako, Genshi, Jinja, Kid, Cheetah. Como você pode ver, cada projeto Pylons pode ser bem diferente do outro.

Parece um pouco perigoso caminhar com tantas variáveis no caminho, ainda mais que no geral a funcionalidade ganha com isso seja pouca. E obviamente eu não o único preocupado com isso. Recentemente surgiu uma discussão sobre integridade conceitual, e de como o Django e o Pylons atingem ou não tal alvo. Eu ainda penso que é possível manter um framework plugável e atingir a tal da integridade conceitual. No mais, não existe magia negra no Pylons. e você tem a sensação de estar trabalhando com Python mesmo. Mas, como você viu acima, provavelmente estamos falando mais a respeito de um meta-framework do que de um framework completo. E isso pra mim é bom.

Um dos problemas atuais do Pylons é a relativa falta de estabilidade de suas APIS. Isso é parcialmente explicado pelo fato de ser versão 0.x ainda, e o fato de que muitas APIs dos componentes que ele agrega estão mudando. Algumas APIs que foram adaptadas do Rails form implementadas de forma pouco "pitônica" ou tem alguns problemas estruturais e vão mudar também (Routes e WebHelpers). É preciso estar dentro da lista de discussão, no IRC pra poder acompanhar o que está acontecendo.

A documentação não é ruim, mas com a mudança das APIs, ela se desatualiza rapidamente. E como o projeto agrega outros, muitas vezes você precisa visitar diversos sites até achar ou criar sua solução. Não chega a ser um empecilho, já que não são muitos lugares onde se preocupar (minhas principais dúvidas acabam girando entre o próprio Pylons e SQLAlchemy), mas pode frustrar os mais ansiosos. Com a versão 0.97 será possível criar um projeto já utilizando SQLAlchemy, que eu penso que tem tudo pra se tornar o padrão oficial do Pylons.

WSGI é uma parte interessantíssima. Na comunidade internacional, tem se falado mais de componentes WSGI do que middlewares, já que as aplicações tem se tornado mais e mais dependentes desses middlewares, e isso faz todo o sentido. Um exemplo do que pode ser feito com WSGI: com versões anteriores do ToscaWidgets, para que eles funcionassem e tivessem a aparência correta, era preciso inserir no seu template a chamada aos Javascripts e CSS do ToscaWidgets. Com as últimas versões, ao adicionar o middleware do ToscaWidgets, você especifica se quer que ele injete os recursos no seu HTML. Um avanço interessante, e um bom exemplo do que pode ser feito através dos middlewares WSGI. O Django inclui o conceito de middlewares, de forma um tanto quanto parecida com os middlewares WSGI.

Veja como ficaria esse exemplo, ao configurar os middlewares

Podemos embutir uma aplicação que fale WSGI como um controller no Pylons – como por exemplo, o Trac ou o MoinMoin. Muita coisa no Python está convergindo para WSGI: o antes monolítico Zope, na versão 3 foi quebrado em vários componentes e tem alguma integração com WSGI, embora eu não saiba dizer no momento como isso é feito. Django e TurboGears também falam WSGI, mas no Pylons isso está bem mais explícito, para o bem e para o mal.

Uma coisa que eu gostaria de ter feito e ainda não fiz são alguns experimentos com REST no Pylons. O deploy de uma aplicação WSGI sobre o Apache, usando FastCGI ou CGI não é complexo. Ainda não testei o mod_wsgi. Mas algumas coisas podem acontecer. Recentemente mudei minha aplicação para usar OpenID. Rodando ela no servidor do Paste, tudo correu bem. Ao fazer o deploy usando Apache, WSGI e Flup, um erro ocorreu. Após alguma pesquisa e ajuda no #pylons, descobri que o authkit está retornando um tamanho de página como inteiro, ao passo que o Flup esperava uma string. Uma modificação fácil de ser feita, mas que no mínimo provou que o Authkit nunca foi testado nesse ambiente.

Tendo dito isso, hoje o Pylons pode não ser o framework para a comunidade Python por uma série de razões, mas é o framework para mim.

Links sobre a discussão sobre integridade Conceitual

• Questionamento de Adam Gona
• Resposta de Mike Ramm
• Resposta de James Bennet
• Considerações de Marcus Cavanaugh

Segundo a notícia do Tiobe, Python foi eleita a linguagem do ano de 2007.O ranking do Tiobe é uma espécie de medida de popularidade das linguagens de programação.

Para os amantes de linguagens dinâmicas, o ranking tem dado boas notícias. Ruby foi declarada a linguagem do ano de 2006 e Python de 2007. E um amante de Lua como eu, não poderia deixar de notar o crescimento de Lua.

Nesse ano, muitas coisas boas aconteceram na comunidade Python. O Django vem se firmando quase que como uma escolha natural para o desenvolvimento web em Python – embora minha escolha seja outra. WSGI está se tornando um padrão de facto. Embora eu não goste muito desses, Zope 3 e Plone 3 estão aí, mais componentizáveis e tendo algumas de suas partesutilizáveis como componentes WSGI. SQLAlchemy está bem maduro, e Storm parece ser uma alternativa bem interessante.

Eu apenas lamento que muita coisa no Brasil seja centrada em Zope/Plone. Talvez haja uma luz no fim desse túnel. Eu ainda não vi.

Dignas de nota são as considerações de Paul Jensen:

• Python foi declarada a linguagem de programação de 2007. Foi uma disputa acirrada, mas no fim Python pareceu ter o maior crescimento percentual no período de um ano (2.04%). Não está claro porque Python teve esse grande salto em 2007. No último mês, pela primeira vez na história, Python ultrapassou Perl, o que é uma indicação clara que Python se tornou "de facto" a linguagem cola no nível do sistema. É especialmente amada por administradores de sistema e gerentes de build. Graças ao lançamento próximo de Python 3, as chances de Python se popularizar ainda mais são altas.
• Uma porção de tendências interessantes pode ser derivada dos dados de 2007. Primeiro, linguagens sem coleta de lixo automática estão perdendo chão rapidamente. As linguagens mais populares com gerenciamento explícito de memória, C e C++, perderam ambas 2% em um ano. Outra tendência é que a batalha entre as linguagens de script parece estar acontecendo ao fundo. Há um fluxo contínuo de novas linguagens. Em 2006, Ruby entrou na cena principal, seguida esse ano por Lua. Na lista das 50 mais, Groovy e Factor entraram em cena. nenhuma dessas novas linguagens de script para ficar permanentemente, são apenas substituídas por sucessores.
• Quem fez e aconteceu em 2007? Quem caiu? Os grandes vencedores são Lua pulou da 46ª posição para a 16ª), Groovy (da 66ª para a 31ª), Focus (da 78ª para 41ª), e Factor (surgindo em 45º lugar). As grandes quedas ficam por cnota de ABAP (da 15ª para a 29ª) e IDL (da 23ª para 48ª).
• O que esperar de 2008? O que aconteceu com nossas previsões em 2007? No início de 2007, eu pensei que C# e D seriam os vencedores e Perl e Delphi os perdedores. De fato, C# foi um dos grandes vencedores, e Perl um dos grandes perdedores. Mas as previsões para D e Delphi estavam completamente erradas. D não avançou. Por outro lado, Delphi ficou em 10º lugar... E sobre 2008? C, C++ e Perl continuarão a cair. C e C++ porque não tem coleta de lixo automática. C++ irá ter uma pedra no sapato ainda maior porque a Microsoft não está mais suportando a linguagem. Perl está morto. Java e C# irão finalmenente ser as 2 linguagens mais populares. Parece-me que elas crescerão em 2008. Adivinhar quais novas linguagens estarão na lista das 20 mais em 2008 é uma tarefa difícil, mas eu acho que ActionScript e Groovy são bons candidatos.

Caio Moritz fez uma pequena análise também, bem interessante. E você, o que pensa de tudo isso?