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

1 McIlroy: Um quarto de século de Unix
2 Pike: Notas para programação na linguagem C
3 Mike Gancarz: A filosofia UNIX
4 O pior é melhor
5 Raymond: A arte da programação Unix
6 Frases
7 Ver também
8 Referências
9 Ligações externas

[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:

Escreva programas que realizam apenas uma tarefa e que a façam bem feita.

Escreva programas que trabalhem juntos.

Escreva programa para manipular streams de texto, pois esta é uma interface universal."

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