Em Os problemas do Perl: O futuro do Bugzilla, Max Kanat-Alexander* lamenta o estado da base de código do Bugzilla:
Era uma vez, Bugzilla era um aplicativo interno da Netscape, escrito em TCL. Quando o código foi aberto em 1998, Terry (o programador original) decidiu reescrever o Bugzilla em Perl. Pelo que sei, ele o reescreveu em Perl porque muitos administradores de sistemas conhecem Perl, o que facilitaria a obtenção de colaboradores.
Em 1998, havia poucas linguagens de script avançadas e orientadas a objetos para a Web. Na verdade, o Perl era praticamente tudo. O PHP estava na versão 3.0, o python estava na versão 1.5, o Java estava apenas começando a se tornar conhecido, o ruby era quase desconhecido e algumas pessoas ainda escreviam seus scripts CGI em C ou C++.
O Perl tem muitos recursos excelentes, principalmente o número de bibliotecas disponíveis e a extrema flexibilidade da linguagem. No entanto, o Perl não seria minha primeira opção para escrever ou manter um projeto grande como o Bugzilla. A mesma flexibilidade que torna o Perl tão poderoso dificulta muito a aplicação de padrões de qualidade de código ou a implementação de projetos modernos orientados a objetos.
Desde 1998, houve muitos avanços nas linguagens de programação. O PHP tem recursos decentes de orientação a objetos, o python tem muitas bibliotecas e excelente sintaxe, o Java amadureceu muito e o Ruby está surgindo rapidamente no mundo. Atualmente, quase todos os nossos concorrentes têm uma vantagem: eles não são escritos em Perl. Na verdade, eles podem desenvolver recursos mais rapidamente do que nós, não por causa do número de colaboradores que têm, mas porque a linguagem que estão usando permite isso. Há pelo menos dois rastreadores de bugs que me lembro de cabeça que nem existiam em 1998 e foram desenvolvidos rapidamente até o ponto em que puderam competir com o Bugzilla.
Em 1998, o Perl foi a escolha certa para reescrever o Bugzilla. Em 2007, porém, tendo trabalhado extensivamente com o Perl durante anos no projeto Bugzilla, eu diria que a linguagem em si é nosso maior obstáculo. Sem tomar alguma atitude, não tenho certeza de quantos anos mais o Bugzilla poderá permanecer vivo como produto. Atualmente, nossa popularidade é de aumentando, até onde posso ver. Portanto, não devemos abandonar o que estamos fazendo agora. Mas estou vendo cada vez mais produtos entrando na área de rastreamento de bugs, e não tenho certeza se conseguiremos nos manter competitivos por mais do que alguns anos se continuarmos com o Perl.
É um crédito para Max o fato de ele se preocupar o suficiente com o futuro de seu trabalho para trazer à tona essas questões importantes. Talvez faça sentido para o senhor reescrever o Bugzilla em uma linguagem mais amigável e moderna.
Nem o Perl nem a base de código do Bugzilla de 1998 envelheceram particularmente bem nos últimos 10 anos. Não acho que o Bugzilla seja o produto de rastreamento de bugs favorito de ninguém. Ele é utilitário e quase feio. Mas… e aqui está a parte importante… O Bugzilla funciona. Ele é usado ativamente hoje por alguns dos maiores e mais famosos projetos de código aberto do planeta, incluindo o Kernel do Linux, Mozilla, Apachee muitos outros.
Tenho um amigo que trabalha em uma empresa de banco de dados de código aberto extremamente popular e ele diz que o código deles é um dos piores que ele já viu. Esse meu amigo em particular não é estranho ao código ruim – ele esteve em posição de ver alguns horrivelmente bases de código ruins. A adoção desse banco de dados de código aberto não está diminuindo nem um pouco porque sua base de código é mal escrita e difícil de solucionar problemas e manter. Os usuários não estão nem aí se o código subjacente é bonito. Tudo o que importa para eles é se ele é ou não funciona. E deve funcionar… caso contrário, por que todas essas pessoas em todo o mundo estariam administrando seus negócios com ele?
Eu dei uma bronca em Joel Spolsky por seu O boondoggle da linguagem wasabi, mas agora estou reconsiderando essa posição. A Fog Creek Software não é financiada pela admiração de outros programadores. Ela é financiada pela venda de seu software aos clientes. E para o cliente, a interface do usuário é o aplicativo. Eu poderia apontar e rir de um aplicativo escrito em uma linguagem interna maluca. Mas a escolha da linguagem é completamente invisível para os clientes em potencial. Desde que os clientes estejam satisfeitos com o aplicativo entregue e as vendas sejam sólidas, quem se importa com a minha opinião ou a de qualquer outro programador?
Claro, nós, programadores, somos pagos para nos preocuparmos com a aparência do código. Nós nos preocupamos com a essência de nossos aplicativos. É nosso trabalho. Nós queremos escrever códigos em linguagens modernas e amigáveis que tornem nosso trabalho mais fácil e menos sujeito a erros. Gostaríamos de amor qualquer oportunidade de se divertir e reescrever tudo na linguagem mais nova e mais sexy possível. Tudo isso é perfeitamente natural.
Da próxima vez que o senhor estiver mergulhado até os joelhos em uma linguagem arcana, lembre-se disso: ninguém se importa com a aparência do seu código. Exceto para nós, programadores. Sim, um código bem elaborado, escrito em uma linguagem moderna, é uma meta louvável. Mas talvez devêssemos nos concentrar um pouco mais nas coisas que o cliente verá e com as quais se importará, e menos nas coisas que ele nunca irá.
* Quero desesperadamente fornecer a atribuição do nome completo aqui, mas não consegui encontrar o sobrenome de Max em nenhuma de suas páginas, o que me deixa absolutamente louco (veja # 3).