Sem dúvida que é um marco para o mundo open source. Publicada por Eric S. Raymond e traduzida para o português por Erik Kohler, A Catedral e o Bazar conta toda a história e os primeiros passos do movimento Open Source.
Antes de voltarmos ao assunto de engenharia de software em geral, existem algumas lições a mais da experiência do fetchmail para ponderar.
A sintaxe do arquivo rc inclui palavra-chaves 'ruidosas' opcionais que são inteiramente ignoradas pelo analisador. A sintaxe parecida com o Inglês que elas permitem é consideravelmente mais inteligível que os concisos pares tradicionais palavra-chave-valor que você obtém quando as retira.
Estas começaram como um experimento posterior quando eu percebi como as declarações do arquivo rc estava começando a lembrar uma minilinguagem imperativa. (É por isto também que eu mudei a palavra-chave original 'server' do popclient para 'poll').
Parecia para mim que tentar fazer esta minilinguagem imperativa parecer mais como o Inglês poderia torná-la mais fácil de ser usada. Agora, embora eu seja um convencido adepto da escola de projeto "faça isso uma linguagem" como exemplificado pelo Emacs e HTML e muitos sistemas de banco de dados, eu normalmente não sou um grande fã das sintaxes "English-like".
Programadores tradicionais tendem a serem a favor de sintaxes de controle que são muito precisas e compactas e não contém redundância alguma. Isto é um legado cultural de quando os recursos computacionais eram caros, então os estágios de análise tinham que ser tão baratos e simples quanto possíveis. O Inglês, com redundância de aproximadamente 50%, parecia ser um modelo muito impróprio.
Esta não é minha razão para normalmente evitar sintaxes no estilo do Inglês; eu menciono isto aqui somente para arrasá-la. Com ciclos e núcleos baratos, concisão não deve ser ela mesma um fim. Hoje em dia é mais importante para uma linguagem ser conveniente para humanos do que ser barata para o computador.
Há, entretanto, boas razões para ser cauteloso. Uma é o custo da complexidade do estágio de análise - você não quer aumentá-lo ao ponto onde é uma fonte significativa de erros e confusão de usuários. Outra é que tentar fazer a sintaxe de uma linguagem English-like freqüentemente demanda que o "Inglês" que é falado seja seriamente propenso a ser fora de forma, tanto como a semelhança superficial com a linguagem natural é tão confusa como a sintaxe tradicional seria. (Você vê isso em várias linguagens chamadas de "quarta geração" e em linguagens de consulta de banco de dados comerciais.)
A sintaxe de controle do fetchmail parece evitar estes problemas porque o domínio da linguagem é extremamente restrito. Não é perto de uma linguagem de uso geral; as coisas que ela diz simplesmente não são muito complicadas, então há pouco potencial para confusão em mover mentalmente entre um pequeno conjunto do Inglês e a real linguagem de controle. Eu acho que há uma lição mais abrangente aqui:
16. Quando sua linguagem não está perto de um Turing completo, açúcar sintático pode ser seu amigo.
Outra lição é sobre segurança por obscuridade. Alguns usuários do fetchmail me pediram para mudar o software para guardar as senhas encriptadas no arquivo rc, de maneira que bisbilhoteiros não poderiam casualmente vê-las.
Eu não fiz isso, porque isto não adiciona realmente proteção. Qualquer pessoa que adquira permissões para ler seu arquivo rc poderá executar o fetchmail como você de qualquer maneira - e se é a sua senha o que eles procuram, poderiam retirar o decodificador do próprio fetchmail para consegui-la.
Tudo o que a encriptação de senha do arquivo .fetchmailrc faria seria dar a falsa impressão de segurança para pessoas que não pensaram bem sobre este assunto. Aqui a regra geral é:
17. Um sistema de segurança é tão seguro quanto é secreto. Esteja atento a pseudo-segredos.
[8] Comentário enviado por fabio em 10/11/2006 - 12:03h
Fala GNU, neste caso apóio a publicação aqui no VOL. Motivo: a tradução está publicada no Geocities.
Possíveis problemas:
1. Geocities é beeeem mais lento que o VOL;
2. Vai que um dia a conta deixa de existir ou o artigo sai do ar.
Defendo que um texto, principalmente os úteis, estejam sempre espelhados em mais de 1 site, pois tudo nessa vida tem princípio, meio e fim e isso também vale para sites. É mais ou menos o conceito de mirrors de pacotes de distros, se só houvesse um, quando o servidor cair fica todo mundo na mão :)
[9] Comentário enviado por User-kuruma em 10/11/2006 - 14:23h
Excelente, esse texto tem aplicação não só na área de software, mas também traz lições para criação e desenvolvimento de projetos de outras áreas. As lições que se pode extrair do texto tem aplicação nas mais diversas áreas de produção e desenvolvimento de serviços para a sociedade em geral.
[11] Comentário enviado por yetlinux em 12/11/2006 - 23:36h
E como alguns já escreveram por aí, não aqui, que o site Domínio Público estaria com o pé na cova, nada melhor que relembrar o que ele pode ter de útil.