Filosofia Unix
Origem: Wikipédia, a enciclopédia livre.
A filosofia Unix é um conjunto de normas culturais e abordagens filosóficas para o desenvolvimento de software, criada com base na experiência de alguns dos principais desenvolvedores do sistema operacional Unix.
Índice |
[editar] McIlroy: Um quarto de século de Unix
Doug McIlroy, o inventor do pipe e um dos fundadores da tradição do Unix, resumiu a filosofia da seguinte maneira:
- "Esta é a filosofia Unix:
Usualmente, resumido simplemesmente em "Faça apenas uma coisa e faça bem."
Dos três princípios, apenas o terceiro é específico do Unix, embora os desenvolvedores Unix, frequentemente, enfatizem todos os três princípios mais que outros desenvolvedores.
[editar] Pike: Notas para programação na linguagem C
Rob Pike ofereceu as seguintes "regras" em Notas para programação em C como máximas da programação de computadores, embora elas possam ser facilmente vistas como pontos da filosofia Unix:
- Regra 1: Você não pode dizer onde um programa está gastando o seu tempo. Os gargalos ocorrem em locais que surpreendem, portanto, não tente supor e estabelecer um corte de velocidade de execução até que tenha determinado exatamente onde se encontra o gargalo.
- Regra 2: Meça. Não otimize o programa para melhorar o seu desempenho até que você tenha medido o seu tempo de execução, e mesmo depois de medido o tempo, não otimize a menos que uma parte do código esteja gastando muito mais tempo em relação ao restante do programa.
- Regra 3: Algoritmos extravagantes são lentos quando n é pequeno, e n é normalmente pequeno. Algoritmos extravagantes têm grandes constantes. Até que você saiba que n torna-se frequentemente grande, não seja extravagante. (Mesmo se n tornar-se grande, use a Regra 2 primeiro.)
- Regra 4: Algoritmos extravagantes contém mais bugs que algoritmos simples e são mais difíceis de implementar. Utilize algoritmos simples assim como estrutura de dados simples.
- Regra 5: O dado domina. Se você escolher a estrutura de dados certa e organizar as coisas bem, os algoritmos surgirão naturalmente. O elemento central da programação é a estrutura de dados, não o algoritmo.
- Regra 6: Não existe Regra 6.
As regras 1 e 2 de Pike, reforçam a famosa máxima de Tony Hoare: "A otimização prematura é a raiz de todo mal." Ken Thompson reescreveu as regras 3 e 4 da seguinte forma: "Quando em dúvida, use força bruta." As regras 3 e 4 são exemplos da filosofia de projeto KISS. A regra 5 foi colocada anteriormente por Fred Brooks no The Mythical Man-Month. A regra 5 é frequentemente resumida como: "escreva código estúpido que use dados espertos", e é um exemplo da norma "Se a sua estrutura de dados é boa o bastante, o algoritmo para manipulá-la deve ser trivial." A regra 6 vem de um quadro Bruces sketch do Monty Python's Flying Circus, ou pode ser um exemplo de ha ha only serious, limitando implicitamente o número de regras (ver Keep it Simple Stupid).
[editar] Mike Gancarz: A filosofia UNIX
Em 1995 Mike Gancarz combinou a sua experiência com o Unix (ele é um membro da equipe que projetou o X Window System) com discussões que ele teve com colegas programadores e com pessoas de outros campos que dependem do Unix, para produzir a A filosofia Unix. A "filosofia Unix" junta tudo isso em 9 princípios "superiores":
- O pequeno é belo.
- Faça cada programa fazer uma coisa bem feita.
- Faça um protótipo assim que possível.
- Escolha "portabilidade" ao invés de eficiência.
- Armazene dados em arquivos no formato texto.
- Tire vantagem das funcionalidades do software.
- Utilize scripts para incrementar a funcionalidade e portabilidade.
- Evite construir interfaces do usuário que sejam engessadas.
- Faça de cada programa um filtro.
Os 10 princípios "inferiores" não são aceitos universalmetne como parte da filosofia Unix, e em alguns casos, são tema de debates acalorados (Kernel monolítico vs. Micro-kernel):
- Permita ao usuário definir o ambiente.
- Faça o kernel do sistema operacional pequeno e leve.
- Utilize letras minúsculas e faça textos curtos.
- Salve as árvores.
- O silêncio é ouro.
- Pense paralelamente.
- A soma de todas as partes é maior que o todo.
- Preste atenção na lei do 90% da solução.
- O pior é melhor.
- Pense de forma hierárquica.
[editar] O pior é melhor
Richard P. Gabriel sugere que a vantagem chave do Unix está relacionada a uma filosofia de projeto que ele chamou de "o pior é melhor" (worse is better). No estilo de projeto "pior é melhor", a simplicidade da interface "e" da implementação é mais importante que qualquer outro atributo do sistema — incluindo correção, consistência e inteireza. Gabriel sustenta que este estilo de projeto contém vantagens evolucionárias chave, embora ele questione a qualidade de alguns resultados.
[editar] Raymond: A arte da programação Unix
Eric S. Raymond, no seu livro The Art of Unix Programming, resume a filosofia Unix como sendo a filosofia KISS. Ele descreve como a filosofia é aplicada na forma de uma norma cultural do Unix, apesar de, previsivelmente, não ser difícil encontrar violações severas nas práticas adotadas nos projetos Unix atuais:
- Regra da "modularidade": escreva partes simples conectadas por interfaces limpas.
- Regra da clareza: clareza é melhor que inteligência.
- Regra da composição: projete os programas para serem conectados com outros programas.
- Regra da separação: separe a configuração dos mecanismos; separe as interfaces da implementação de algoritmos.
- Regra da simplicidade: projete para simplicidade; adicione complexidade apenas onde é necessário.
- Regra da parcimônia: escreva um programa de tamanho grande somente quando fica claro, por demonstração, que de outra maneira não seria possível resolver o problema.
- Regra da transparência: projete para visibilidade para fazer do processo de debug e inspeção uma tarefa fácil.
- Regra da robustez: a robustez é a filha da transparência e simplicidade.
- Regra da representação: armazene o conhecimento na forma de dados, para que a lógica dos programas possa ser robusta e estúpida.
- Regra da menor surpresa: no projeto de interfaces, sempre faça aquilo que é o menos surpreendente.
- Regra do silêncio: quando um prograna não tem nada surpreendente para dizer, ele não deve dizer nada.
- Regra do reparo: quando é inevitável falhar, falhe em silêncio e o mais cedo possível.
- Regra da economia: o tempo do programador é caro; conserve este tempo em detrimento do tempo da máquina.
- Regra da geração de código: evite escrever código; escreva programas que gerem código quando é possível.
- Regra da otimização: faça protótipo antes do refinamento. Coloque em funcionamento antes de ser otimizado.
- Regra da diversidade: desconfie de todas as alegações sobre a existência de um "modo correto de fazer".
- Regra da extensibilidade: projete para o futuro, pois ele chegará antes do que você imagina.
Muitas destas normas foram aceitas fora da comunidade Unix, mesmo que isso não tenha ocorrido num primeiro momento. É preciso dizer também, que muitas delas não foram criadas pela comunidade Unix. Todavia, os adeptos da programação Unix tendem a aceitar uma combinação destas idéias como a fundação do estilo Unix.
[editar] Frases
- "Unix is simple. It just takes a genius to understand its simplicity." – Dennis Ritchie
- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
- "Unix never says 'please'." – Rob Pike
- "The UNIX philosophy basically involves giving you enough rope to hang yourself. And then a couple of feet more, just to be sure." - autoria desconhecida
[editar] Ver também
- Plan 9
- Pipe
- The Elements of Style – Um das fontes de inspiração para a filofia Unix.
- Engenharia de software
[editar] Referências
- The Unix Programming Environment por Brian Kernighan e Rob Pike, 1984
- Notes on Programming in C, Rob Pike, 21 de setembro de 1989
- A Quarter Century of Unix, Peter H. Salus, Addison-Wesley, 31 de maio de 1994 (ISBN 0201547775)
- Philosophy — da The Art of Unix Programming, Eric S. Raymond, Addison-Wesley, 17 de setembro de 2003 (ISBN 0131429019)
- Final Report of the Multics Kernel Design Project por M. D. Schroeder, D. D. Clark, J. H. Saltzer, e D. H. Wells, 1977.