Pylons e TurboGears
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.
TurboGears
O TurboGears é um framework construído por diversas partes (ao contrário do Django, onde toda a stack parte de um mesmo lugar). Atualmente, usa o CherryPy, SQLObject para mapeamento objeto relacional, Kid para templates MochiKit para JavaScript e AJAX. O Framework foi criado por Kevin Dangoor, e teve seu desenvolvimento iniciado no começo de 2005.
Pylons
O desenvolvimento do Pylons começou no início de 2006, e tinha como um dos objetivos, na época, ser uma resposta ao Ruby on Rails, tanto que possui alguns componentes portados do próprio Rails, como o sistema de roteamento de URLS e controladores (Routes) e o WebHelpers. Outra decisão que direciona o projeto até hoje é o fato dele dar extremo valor ao padrão WSGI. Atualmente, o projeto está chegando a versão 0.97. O WebHelpers está sendo praticamente reescrito - a geração de código javascript, e as funções link_to_remote, por exemplo, estão caindo em desuso. Segundo os autores, o framework não deve ser acoplado a nenhuma biblioteca JavaScript, até porque elas estão em constante evolução e a biblioteca da vez sempre muda, o que faria com que sempre alguém ficasse descontente por não ter sua biblioteca preferida suportada. Segundo o Charleno Pires, o Pylons é de certa forma semelhante ao Merb (Ruby), ao prover um framework pequeno e bastante personalizavel.
TurboGears 2
Um julho de 2007, uma surpresa aconteceu: após um sprint, o pessoal do TurboGears decidiu implementar o TurboGears 2 usando o Pylons como fundamento (trocando então o CherryPy). Na época algumas pessoas acharam esquisito implementar um framework sobre o outro (porém, o mesmo acontece com zope, ao pesarmos em CMF>Plone>Archetypes), e houve até uma especulação sobre um possível merge dos dois projetos. Porém, os dois projetos tem propósitos e visões diferentes. Enquanto o Pylons é mais um meta-framework, uma base crua sobre a qual idéias podem ser desenvolvidas, o TurboGears já pressupõe que você irá usar um banco de dados relacional (suposição que o Pylons não faz), possui algumas ferramentas para geração de formulários, ou seja, provê de certa forma uma estrada mais pavimentada para o usuário do framework. Você pode encontrar mais informações sobre o porquê desse merge não ter acontecido na documentação do TurboGears.
E o resultado é...
Entender a história dos frameworks, junto com a experiência de uso deles, é a melhor forma de fazer uma boa escolha. Espero ter contribuído com essa escolha ao detalhar um pouco da história desses dois frameworks!
Links
- Rum - Um 'gerador de CRUD para SQLAlchemy, feito pelo Alberto Valverde.
- Uma introdução ao WSGI - Ian Bicking
- WSGI - a resposta para a questão definitiva sobre Python, a web e tudo mais? - Humberto Diógenes
- Pylons Book Livro sobre o Pylons (em fase de escrita ainda)
- Documentação do TurboGears 2
- Documentação da versão 0.97 do Pylons
por Walter Cruz em Python, Ruby, Rails, Pylons
V8 x Tracemonkey
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
por Walter Cruz em Google, JavaScript, Ruby
Progressos no Jython
Algumas semanas atrás o Marcos me passou um link interessante: O Django estava rodando no Jython. Na época, estava rodando em um branch do Jython, o Modern. Atualmente, já foi feito o merge desse branch no trunk.
Agora, quem está se esforçando contribuindo com o Jython são as pessoas do Pylons. Há um esforço para executar o Pylons no Jython. O primeiro desafio foi fazer o setuptools rodar no Jython. Agora, eles estão trabalhando em cada componente do Pylons, trabalhando com o nose e diversos pacotes.
Se as coisas continuarem nesse pique, em breve a JVM será uma alternativa de fato viável para a execução de Python!
por Walter Cruz em Python, Programação, Java, Django
Lua entre as 20 mais do Tiobe
Como já era esperado desde o mês passado, Lua entrou na lista das 20 mais do ranking tiobe. E não apenas no 20º lugar, mas direto pro 18º, subindo 10 posições. A linguagem que saiu da lista foi Fortran (esse mês ficou em 21º lugar). Lua é uma linguagem minimalista, pequena e nem por isso menos poderosa ou versátil que outras linguagens populares atualmente como Python ou Ruby.
Lua foi desenvolvida por uma equipe de programadores do Lablua da PUC-Rio em 1993 para uso no projeto Tecgraf de computação gráfica, como uma linguagem de extensão. Por isso Lua possui uma API poderosíssima com a linguagem de programação C.
Apesar de leve e enxuto (a implementação de regex é maior que Lua inteira), é uma linguagem bastante completa e módulos complementares podem ser encontrados no LuaForge e no lua-users.
Meu uso de Lua atualmente envolve mais em fazer scripts para tornar o SciTE mais poderoso.Atualmente o framework mais bem acabado é Kepler, englobando módulos de suporte a banco de dados, XML, registro (logs), AJAX e um servidor web, Xavante. Meu amigo Rodrigo Cacilhas está desenvolvendo um projeto paralelo similar, chamado LuaWsgi, inspirado no padrão WSGI do Python. Dê uma olhada no blog do LuaWsgi!
por Walter Cruz em Lua, Ruby
