Introdução

Programação pode ser considerada um trabalho majoritariamente artesanal. Mas uma consideração como essa não é adotada de forma predominante; longe disso, torna-se algo digno de debate, e deixa uma margem para uma interessante troca de opiniões divergentes. Há aqueles que pensem no ato de escrever um programa de computador como algo mecânico em princípio: existiria um quê de criatividade, já que o programador precisa tomar as melhores decisões do ponto de vista do projeto de software; Mas, para tal, enumera-se ferramentas e processos que o auxiliam com planejamento e que, muitas vezes, acabam apontando, sem auxílio de ``intuição'', o melhor caminho a ser seguido nesse processo criativo.

Apesar de ver a pertinência do uso desses processos (como nos apresenta a disciplina de Engenharia de Software, por exemplo), ainda acredito na programação de computadores como uma arte, algo que envolve muito mais que apenas seguir práticas consolidadas.

Verna (2018, p. 4) endossa o aspecto artístico na programação – que, por alguns, é considerado mera luxúria –, inclusive citando antigos apoiadores dessas ideias (como Knuth, Dijkstra e Ershov). Esses pensadores ilustres também buscavam clarificar que a descrição de um programa de computador envolve noções intrínsecas de estética, beleza, estilo, prazer e emoção, que tendem a pender muito mais para o lado artístico que o científico.

Penso na escrita de um código de programação como sendo um processo muito similar à boa escrita em prosa de qualquer outro tipo de texto. O objetivo do autor é fazer-se entender através do que escreve; para tanto, é imperativo que palavras, orações e demais expressões gramaticais sejam ordenadas de forma inteligível, e o melhor recurso para garantir que o leitor compreenda o texto escrito é a própria leitura do mesmo, especialmente quando é feita por parte do autor.

Ao escrevermos um programa de computador, realizamos um processo muito similar à composição ou redação. A escrita do código acaba, no fim das contas, por envolver três leitores: o próprio autor, um eventual futuro leitor do código e a máquina em si (leia-se, o compilador ou interpretador, que fica efetivamente responsável por ``compreender'' o código em questão e transformá-lo em linguagem de máquina).

O ``leitor'' mais fácil de agradar neste trio é a máquina, que não reclamará de aspectos como a estética do código, salvo quando programas como linters forçarem um certo estilo de escrita no processo de programação. Porém, a máquina ainda está suscetível a erros gramaticais ou de interpretação, provenientes de deficiências na escrita do código: estes poderão ocasionar tanto erros que antecedem a execução (quando tratarem-se de código sintaticamente inválido), quanto a execução de algo não-pretendido pelo programador (sendo este o caso do erro de semântica).

Aqui entra em ação outro potencial leitor do código: o próprio autor, o programador daquele segmento de código em si. O programador precisa verificar o código por erros, e também precisa criar correções. Se a forma como o código foi escrito não facilita o próprio trabalho daquele que o escreveu, então é sinal de que é necessário revisar a forma como o mesmo foi escrito. Escrever código sem preocupar-se com estética ou beleza é um erro comum de muitos programadores, que costumam ignorá-lo por não representar um problema em curto prazo. Mas, se aquele código precisar ser revisitado após algum tempo, o programador será o primeiro a sofrer com as consequências da ilegibilidade e/ou desorganização do próprio trabalho.

Por fim, temos o último tipo de leitor: o futuro leitor do código, que normalmente seria um terceiro; mas poderíamos pensar até mesmo no programador original, passado um bom tempo desde a última vez que viu o código: aos seus olhos, o programa ter-se-á tornado algo completamente desconhecido… um alienígena.

Precisamos pensar no código como uma ferramenta didática. O código precisa ser dotado de uma simplicidade autoexplicativa. O futuro leitor precisará consertar algo no mesmo ou adicionar uma nova funcionalidade; para tanto, a forma de escrever o código será o melhor guia para deixá-lo a par dos passos a serem tomados, ou dos processos a serem seguidos para adicionar, remover ou modificar certas operações.

No espírito deste aspecto didático do código, que requer certa elegância e senso de beleza, é que escrevo este pequeno software em formato de livro. Escrever o interpretador de uma linguagem de programação e definir a especificação da mesma não é uma tarefa trivial, mas é uma tarefa tangível. Para provar esse argumento e também para encorajar outros programadores a utilizarem-se dessas ideias, detalho passo-a-passo todo o raciocínio por trás do planejamento para que se conceba uma linguagem de programação – como um caso especial, uma linguagem que seja um dialeto de Lisp.

A intenção não é apresentar um produto que seja extremamente polido e que não possa ser modificado posteriormente; antes, o software, assim como qualquer outro texto, é algo vivo, e pode inclusive ser modificado, melhorado ou até mesmo ``traduzido'' para outras linguagens. Por isso, trabalho sob alguns pressupostos, que mais tarde enumerarei, e que segui como regras informais de estilo para esse processo de desenvolvimento.