PROGRAMAÇÃO BOTTOM-UP

Janeiro de 1993

(Este ensaio é da introdução de On Lisp .)

É um princípio antigo do estilo de programação que os elementos funcionais de um programa não devem ser muito grandes. Se algum componente de um programa cresce além do estágio em que é facilmente compreensível, ele se torna uma massa de complexidade que esconde erros tão facilmente quanto uma cidade grande esconde fugitivos. Esse software será difícil de ler, difícil de testar e difícil de depurar.

De acordo com esse princípio, um programa grande deve ser dividido em partes, e quanto maior o programa, mais ele deve ser dividido. Como você divide um programa? A abordagem tradicional é chamada de design de cima para baixo: você diz "o propósito do programa é fazer essas sete coisas, então eu o divido em sete sub-rotinas principais. A primeira sub-rotina tem que fazer essas quatro coisas, então ela por sua vez terá quatro de suas próprias sub-rotinas", e assim por diante. Esse processo continua até que todo o programa tenha o nível certo de granularidade - cada parte grande o suficiente para fazer algo substancial, mas pequena o suficiente para ser entendida como uma única unidade.

Programadores experientes em Lisp dividem seus programas de forma diferente. Assim como o design de cima para baixo, eles seguem um princípio que poderia ser chamado de design de baixo para cima — mudando a linguagem para se adequar ao problema. Em Lisp, você não apenas escreve seu programa em direção à linguagem, você também constrói a linguagem em direção ao seu programa. Enquanto você está escrevendo um programa, você pode pensar "Eu queria que o Lisp tivesse tal e tal operador." Então você vai e o escreve. Depois você percebe que usar o operador new simplificaria o design de outra parte do programa, e assim por diante. Linguagem e programa evoluem juntos. Como a fronteira entre dois estados em guerra, a fronteira entre linguagem e programa é desenhada e redesenhada, até que eventualmente ela se deite ao longo das montanhas e rios, as fronteiras naturais do seu problema. No final, seu programa parecerá como se a linguagem tivesse sido projetada para ele. E quando linguagem e programa se encaixam bem, você acaba com um código que é claro, pequeno e eficiente.

Vale ressaltar que design bottom-up não significa apenas escrever o mesmo programa em uma ordem diferente. Quando você trabalha bottom-up, geralmente acaba com um programa diferente. Em vez de um programa único e monolítico, você terá uma linguagem maior com operadores mais abstratos e um programa menor escrito nela. Em vez de um lintel, você terá um arco.

Em código típico, uma vez que você abstrai as partes que são meramente contábeis, o que resta é muito mais curto; quanto mais alto você constrói a linguagem, menor distância você terá que percorrer do topo até ela. Isso traz várias vantagens:

Ao fazer a linguagem fazer mais trabalho, o design bottom-up produz programas que são menores e mais ágeis. Um programa mais curto não precisa ser dividido em tantos componentes, e menos componentes significa programas que são mais fáceis de ler ou modificar. Menos componentes também significam menos conexões entre componentes e, portanto, menos chance de erros. Enquanto designers industriais se esforçam para reduzir o número de peças móveis em uma máquina, programadores Lisp experientes usam o design bottom-up para reduzir o tamanho e a complexidade de seus programas.

O design bottom-up promove a reutilização de código. Quando você escreve dois ou mais programas, muitos dos utilitários que você escreveu para o primeiro programa também serão úteis nos seguintes. Uma vez que você adquiriu um grande substrato de utilitários, escrever um novo programa pode levar apenas uma fração do esforço que exigiria se você tivesse que começar com Lisp cru.

O design de baixo para cima torna os programas mais fáceis de ler.

Uma instância desse tipo de abstração pede ao leitor que entenda um operador de propósito geral; uma instância de abstração funcional pede ao leitor que entenda uma sub-rotina de propósito especial. [1]

Como faz com que você esteja sempre atento a padrões em seu código, trabalhar de baixo para cima ajuda a esclarecer suas ideias sobre o design do seu programa. Se dois componentes distantes de um programa são semelhantes em forma, você será levado a notar a similaridade e talvez a redesenhar o programa de uma forma mais simples.

O design bottom-up é possível até certo ponto em linguagens diferentes de Lisp. Sempre que você vê funções de biblioteca, o design bottom-up está acontecendo. No entanto, Lisp lhe dá poderes muito mais amplos neste departamento, e aumentar a linguagem desempenha um papel proporcionalmente maior no estilo Lisp-- tanto que Lisp não é apenas uma linguagem diferente, mas uma maneira totalmente diferente de programar.

É verdade que esse estilo de desenvolvimento é mais adequado para programas que podem ser escritos por pequenos grupos. No entanto, ao mesmo tempo, ele estende os limites do que pode ser feito por um pequeno grupo. Em The Mythical Man-Month , Frederick Brooks propôs que a produtividade de um grupo de programadores não cresce linearmente com seu tamanho. À medida que o tamanho do grupo aumenta, a produtividade dos programadores individuais diminui. A experiência da programação Lisp sugere uma maneira mais alegre de expressar essa lei: à medida que o tamanho do grupo diminui, a produtividade dos programadores individuais aumenta. Um pequeno grupo vence, relativamente falando, simplesmente porque é menor. Quando um pequeno grupo também aproveita as técnicas que o Lisp torna possíveis, ele pode vencer completamente .

Novo: Baixe o On Lisp gratuitamente .

[1] "Mas ninguém pode ler o programa sem entender todos os seus novos utilitários." Para ver por que tais declarações são geralmente equivocadas, consulte a Seção 4.8.