Compromisso com a compatibilidade reversa

Como eu comentei no post inicial desse blog (Mais um framework para Python?) uma das vantagens que eu vejo no web2py é ter acesso a quem o desenvolve.

Como desenvolvedor, eu me preocupo muito com a durabilidade do investimento que faço para aprender alguma tecnologia nova. É ruim e contra-producente ter que reaprender ou adaptar as coisas que já funcionavam, a cada nova release de software.

Por isso, resolvi postar uma pergunta na lista mundial do web2py sobre esse assunto. Existe a preocupação com compatibilidade reversa no web2py? Ou seja, há alguma garantia de que o que eu desenvolvo hoje não vai parar de funcionar quando vier uma versão nova do framework?

A resposta não poderia ter vindo de uma fonte melhor: Massimo di Pierro, autor do produto.

Eis minha pergunta (traduzida):

Oi pessoal.
Essa mensagem é mais sobre política de funcionamento do que sobre tecnologia, ok?

Eu sou novo no web2py e ainda não desenvolvi nada com ele.
Só li alguma documentação e vi alguns slides e tutoriais em vídeo.

Como um novato em Django também, pude ver que algumas coisas mudaram de funcionamento antes da versão 1.0. E quem pode me garantir que não vai acontecer novamente? Ninguém. Eu não vejo muita preocupação com compatibilidade reversa no Django.

Qual é o compromisso do web2py com a compatibilidade reversa?

Se eu desenvolvo código, ele passa a ser "código legado" no mesmo momento que é jogado em produção, certo?

E uma das piores coisas ao trabalhar com clientes, é responder algo do tipo: "Tudo bem, eu vou mexer no que você me pediu. Mas terei que cobrar um extra por causa da 'atualização tecnológica'". Meu cliente não quer saber disso. E, na verdade, ele não precisa mesmo saber. Essa é a minha profissão, e não a dele, certo?

Consequentemente, como um profissional, eu me preocupo em como maximizar o investimento do meu próprio tempo em aprender e usar linguagens e frameworks.

Sendo um profissional de mainframe por 21 anos, eu consigo rodar, ainda hoje, meus programas que fiz quando estava começando, no sistema operacional MVS da IBM (isso foi em 1988!). Sem mudar nada neles. Esse tipo de ambiente é muito estável, mesmo com as inovações nas linguagens. Sim, as linguagens também mudam, lá. Mas sempre são compatíveis com as versões anteriores. Isso tem a ver com maximizar tempo e dinheiro.

Existe alguma coisa escrita sobre isso na documentação ou no site do web2py? Eu não encontrei ainda.

Minha opinião é que esse é um dos maiores problemas que algumas empresas enfrentam ao escolher uma tecnologia nova.

Eu não estou falando sobre compatiblidade entre as versões do Python. Eu sei que esse é um problema do Python, e não do web2py. Estou falando sobre a compatibilidade entre versões do web2py mesmo.

--
[ ]s
Vinicius Assef.

Eis a resposta (também traduzida):

Nós somos totalmente comprometidos com a compatibilidade reversa. Nós nunca a quebramos em 2 anos. E não aceitamos patches que quebrem-na. Essa é uma das razões pelas quais chamamos o web2py de um "framework corporativo".

E aí, o que você acha? Vale ou não vale a pena tentar usá-lo?

Para ver todas as respostas, aqui está o link para essa thread na lista oficial: What about backward compatibility?

Mais um framework para python?

Sim, web2py é mais um framework para a linguagem python.

Só que com uma proposta diferente, pois ele herda conceitos do Ruby on Rails e do Django. Ele tenta obter o melhor dos 2 mundos e também faz opções particulares.

Ou seja, ele procura ser produtivo, rápido e seguro.

E por que eu escolhi esse framework que não é tão conhecido ainda?

Por alguns motivos. Alguns de ordem técnica, outros de ordem administrativa e outros ainda de ordem funcional.


Motivos administrativos

1. Ele é auto-contido e não precisa de configurações especiais. Ou seja, roda em qualquer hospedagem compartilhada.
2. Há compromisso com compatiblidade reversa. Em 2 anos de projeto, nunca a compatibilidade foi quebrada e o plano é continuar assim.
3. Eu consigo tirar dúvidas direto com o criador dele e com desenvolvedores brasileiros (sim, nós também contribuímos).
4. Tem suporte simples para internacionalização.
5. Funciona sem complicação em Windows, Linux, Mac OS e até no Nokia N810!
6. A comunidade responde rápido suas dúvidas.

Motivos funcionais

1. Ele já tem embutida a geração automática de tickets para apontar erros em ambiente de produção. Nunca uma linha de código é mostrada ao usuário!
2. A interface de administração da aplicação gerada é via web, mas você também pode trabalhar na linha de comando, se preferir. Bem melhor do que no rails, que tudo acontece só na linha de comando.
3. Essa inteface web já conta com editor no próprio browser.
4. Ele conversa com vários bancos de dados. Além dos batidos MySQL e PostgreSQL, tem também bancos "sérios" como IBM DB2, ORACLE, MS SQL Server e Informix. E para desenvolvimento, o prático SQLite.
   
5. Proteje automaticamente sua aplicação contra cross-site scripting, injections, etc.
6. Trata upload de arquivos grandes automaticamente.
7. Trata formulários de forma simples e objetiva, inclusive com validações complexas junto ao BD.

Motivos técnicos

1. Ao invés de ORM (Object-Relational Mapping) ele usa DAL (Database Abstraction Layer), o que proporciona maior poder e controle na manipulação dos acessos ao BD. Por exemplo, fica fácil fazer INNER JOIN e OUTER JOIN e os operadores ==, <=, >=, <> podem ser usados naturalmente.
   
2. Ele roda no Google App Engine sem precisar de modificação em sua aplicação: http://googleappengine.blogspot.com/2009/05/web2py-support-new-datastore-backend.html
3. Roda no Jython.
4. Já vem com sistema de caching.
5. Sua aplicação pode ser distribuída em byte-code (closed source).
6. Tem MVC real, com os nomes corretos, ao contrário do Django.
7. Eu consigo entrar no ambiente de produção usando o shell dele e gerar relatórios ad-hoc, sem necessidade de implantar rotinas. Isso ajuda MUITO, principalmente na fase de implantação do aplicativo.
8. Eu posso programar em Python.
9. Ao contrário do Django, não preciso ficar inserindo imports para usar as funcionalidades do framework.
   

Claro que o web2py não é perfeito.

Um ponto que ainda deixa a desejar é a documentação.
E esse é o principal objetivo desse blog: ajudar quem está começando a desenvolver com web2py.

[update em 20/outubro/2010]: A documentação melhorou muito desde que esse artigo foi escrito. O livro oficial do web2py está na 3a edição e disponível gratuitamente online.