Programadores como OOPers, se orgulham da sua enorme quantidade de código, acreditando que mais LOC indicam progresso e habilidade. Mas isso é ilusão. A maioria dos programadores não se preocupa com a qualidade do código. Se algo funciona e parece resolver o problema, eles mantêm. Se esse método de desenvolvimento for aplicado ao mesmo código-fonte durante todo o seu ciclo de vida, resultará em código volumoso, estrutura desorganizada e design falho. Isso ocorre por falta de clareza e integridade conceitual no processo de desenvolvimento. A complexidade do código é a raiz do software bloated, deixando ele inconsistente e difícil de usar. Com um código complexo, problemas são resolvidos de maneira subótima, recursos valiosos são desperdiçados, o desempenho cai e vulnerabilidades ficam comuns. A única solução é descartar todo o seu projeto e reescrevê-lo do zero. Bom, a má notícia é que reescritas de qualidade são raras, pois os OOPers se orgulham do seu código bloated. Eles acreditam que compreendem o seu código e não vêem necessidade de reescrevê-lo. Se consideram mestres, como se entendessem o que outros não entendem. Para eles, um software complexo é o ideal. A verdadeira genialidade está na simplicidade. O princípio fundamental da filosofia UNIX é que menos é mais e pior é melhor. Quanto mais LOC você remove, mais progresso faz. À medida que o número de linhas de código diminui, mais habilidoso você torna e menos defeituoso é o seu software. Atualmente vivemos rodeados por softwares complexos, que recebem novas versões e atualizações continuamente. O consumo de RAM e CPU só aumenta, embora o software ofereça os mesmos recursos de anos atrás, apenas com uma aparência nova. Este fenômeno é denominado de avanço, o que para nós é um retrocesso na terminologia do desenvolvimento de software proprietário. Isso precisa mudar.
O consumismo refere-se à perda da capacidade de pensar de forma autônoma e de produzir, substituindo o raciocínio lógico e prático por mentalidade passiva de consumo. Essa praga do consumismo também afeta os dispositivos e computadores que criamos, limitando seu potencial. Os computadores possuem capacidades que ultrapassam a imaginação e as necessidades imediatas dos consumidores. A economia de mercado, baseada na oferta e demanda, não se aplica adequadamente nesse contexto.
Os princípios do UNIX† estabeleceram a criação de software reutilizável de maneira que os desenvolvedores originais não haviam previsto. Pequenos utilitários são projetados para se combinar por meio de pipes simples, comunicando-se entre si e realizando cada um uma tarefa específica de maneira eficiente.
Infelizmente, a POO tornou-se muito popular, e criticar ela era como falar palavrão na igreja. O OOPeísmo se tornou algo que toda linguagem séria e respeitável simplesmente tinha que ter. Eles enfatizam a abstração através de objetos e classes, que se tornaram, infelizmente, o padrão da programação contemporânea. No engano, essa abstração não é gratuita. Ela cria camadas adicionais e desnecessárias de complexidade. A arte de programação, que deveria ser a construção de soluções eficientes e elegantes, é diluída por uma sobrecarga conceitual. Em vez de lidar com o algoritmos e dados, você lida com redes de objetos e suas interações. Isso tem que mudar.
É criada então a denominada POÓ - Programação Orientada a Ódio - criada por Mr. Unix e pela Lady C. Nosso intuito é criticar e desconstruir essa camada insaciável de abstração, uma vez que a POO revelou-se mais destrutiva do que foi suposto.
O software, em sua essência, deve ser concebido para servir aos próprios programadores, o que implica que o código-fonte deve atuar como documentação. A legibilidade do código deve ser primordial, com a utilização reduzida de camadas abstratas, logo, a POO é insuficiente e prejudicial, a presença de um simples Makefile, capaz de orquestrar a construção do sistema, é imprescindível.
Todos softwares são prejudiciais. Estão em todos os lugares, desde a IDE lenta e problemática que usa, até sites sobrecarregados de JavaScript, linguagens que tem C em seu nome, mas não é C. Esses softwares são complexos, desnecessários e excessivamente volumosos. Por isso, evite.
Adicione uma interface de linha de comando ao seu software. Interfaces gráficas são para fracos. Pipes são bem-vindos.
Rastreadores de bugs são obsoletos. Sempre que encontrar um bug, corrija. Os outros princípios possibilitam que você envie um patch em vez de um relatório.
Existem ferramentas como javadoc, gnu texinfo e info. Que dificultam a maneira de encontrar informações úteis. Todo software deve fornecer manpages. Se você precisa de mais recursos do que as manpages exigem, repense o que está tentando documentar. As manpages têm estrutura definida que torna a localização e extração das informações necessárias mais fácil e uniforme.
As corporações odeiam seus usuários, vendem seus dados e reduzem recursos a fim de obter lucro.
O manifesto está suscetível a mudanças com o consentimento da elite Unixtopia.
Impulsionado por nada. Todo conteúdo é disponível sob CC0 1.0 domínio público. Envie comentários e correções para Mr. Unix em victor_hermian@disroot.org.