Boa noite amigos!
Vimos a décima quinta parte da tradução de “The Cathedral and the Bazaar” no último versículo. No de hoje veremos a décima sexta.
Mais Algumas Lições do Fetchmail
Antes de voltarmos aos problemas gerais de engenharia de software, há algumas lições mais específicas da experiência do fetchmail para ponderar. Os leitores não técnicos podem pular esta seção com segurança.
Compre seu Ingresso Agora
A sintaxe do arquivo rc (controle) inclui palavras-chave ‘ruído’ opcionais que são inteiramente ignoradas pelo analisador (parser). A sintaxe parecida com o inglês que eles permitem, é consideravelmente mais legível do que os tradicionais pares de palavras-chave concisas que você obtém quando remove elas todas.
Isso começou como um experimento de fim de noite, quando percebi o quanto as declarações de arquivo rc estavam começando a se assemelhar a uma mini-linguagem imperativa. (É também por isso que mudei a palavra-chave “servidor” do popclient original para “poll”).
Pareceu-me que tentar tornar a mini-linguagem imperativa mais parecida com o inglês poderia facilitar o uso. Agora, embora eu seja um partidário convicto da escola de design “faça disso uma linguagem”, como exemplificado pelo Emacs e HTML e muitos mecanismos de banco de dados, eu normalmente não sou um grande fã de sintaxes “parecidas com o inglês”
Tradicionalmente, os programadores tendem a favorecer sintaxes de controle que são muito precisas e compactas e não têm redundância alguma. Esse é um legado cultural de quando os recursos de computação eram caros, então os estágios de análise tinham que ser o mais barato e simples possível. O inglês, com cerca de 50% de redundância, parecia um modelo muito inapropriado.
Este não é o meu motivo para normalmente evitar as sintaxes parecidas com o inglês; Eu menciono aqui apenas para demoli-la. Com ciclos e núcleos baratos, a concisão não deve ser um fim em si mesmo. Hoje em dia é mais importante que uma linguagem seja conveniente para os humanos do que ser barata para o computador.
Há, no entanto, boas razões para ser cauteloso. Uma é o custo da complexidade do estágio de análise – você não quer elevar até o ponto em que seja em si mesmo uma fonte significativa de bugs e confusão para usuário. Outra é que tentar fazer uma sintaxe da linguagem como o inglês muitas vezes exige que o “inglês” que ela fale seja seriamente dobrado fora de forma, tanto que a semelhança superficial com a linguagem natural é tão confusa quanto uma sintaxe tradicional teria sido. (Você vê esse efeito ruim em muitas das chamadas linguagens de consulta de banco de dados de “quarta geração” e comercial).
A sintaxe de controle do fetchmail parece evitar esses problemas porque o domínio da linguagem é extremamente restrito. Não está nem perto de uma linguagem de propósito geral; as coisas que diz simplesmente não são muito complicadas, então há pouco potencial para confusão em mover-se mentalmente entre um pequeno subconjunto de inglês e a linguagem de controle real. Eu acho que pode haver uma lição mais ampla aqui:
- Quando a sua linguagem não está nem perto de ser Turing completa , o açúcar sintático pode ser seu amigo.
Outra lição é sobre segurança pela obscuridade. Alguns usuários do fetchmail me pediram para alterar o software para armazenar as senhas criptografadas no arquivo rc, para que os bisbilhoteiros não pudessem vê-los casualmente.
Eu não fiz, porque isso não adiciona proteção. Qualquer pessoa que tenha adquirido permissões para ler seu arquivo rc poderá executar o fetchmail como você de qualquer maneira – e se for a sua senha, eles poderão extrair o decodificador necessário do próprio código do fetchmail para obtê-la
Tudo o que a criptografia de senha do .fetchmailrc teria feito seria dar uma falsa sensação de segurança às pessoas que não pensam muito. A regra geral aqui é:
- Um sistema de segurança é tão seguro quanto seu segredo. Cuidado com os pseudo-segredos.
Terminada a parte dezesseis, amanhã volto com a dezessete. Ricas bençãos!
