o programador humilde

A história de hoje é sobre um artigo de Edsger W. Dijkstra que leva o mesmo nome. Ele foi um dos caras mais relevantes da área de ciência da computação e tem muitos artigos escritos. Eu tentei interpretar e resumir mais do que traduzir, mas mantive o título. Eu cheguei nesse artigo quando estava pesquisando sobre um dogma que existe na nossa área que diz que é proibido usar instrução GOTO num programa. Outro dia escrevo sobre isso, hoje é mais curtinho.

Mas antes uma frase interessante para começar.

Devemos tomar muito cuidado quando damos algum conselho para o jovem, porque, às vezes, ele o segue.

Um dia, Dijkstra teve uma conversa com seu chefe no centro de matemática de Amsterdam numa época em que estava experimentando ser um programador. Isso foi em 1952, quando estudava física teórica na universidade de Leiden. Ele estava num dilema interessante: se programação seria uma profissão respeitável ou se deveria deixar isso de lado e seguir no caminho da física. Nessa época ele queria estar com seus colegas na área de hardware porque a área de software tinha menos relevância.

Depois de algumas horas de conversa e alguns conselhos, ele se convenceu que estava no caminho certo. Seu chefe disse que os "computadores automáticos tinham vindo pra ficar" e isso que ele estava fazendo era só o começo. O chefe o desafiou a ser uma das pessoas que iria pavimentar esse caminho. Ele se empolgou, terminou seu curso de física e resolveu que seria um programador.

Eu achei engraçado essa história por causa de uma coincidências com minha jornada profissional. Quando comecei na programação, lá por 1992, eu também estudava física na USP quando resolvi mudar de área e acho que consigo entender o dilema que ele tinha. Por um lado, a extraordinária experiência de aprender física e matemática numa das melhores universidades e ter uma profissão sólida e respeitável. Por outro lado a extraordinária experiência de aprender um das tecnologias que estava nascendo e revolucionando o mundo, com uma profissão pouco reconhecida no mercado.

Eu sei que são gerações completamente diferentes e contextos diferentes. Na época dele os computadores eram grandes máquinas que ocupavam salas inteiras e o programador era alguém que pouco se destacava porque as pessoas curiosas estavam interessadas em ver a máquina e seus componentes físicos. Era uma época distante da revolução dos computadores pessoais que trouxe um pouco mais de luz para a profissão do programador.

Naquela época a visão que se tinha de um programador: uma pessoa competente com a mente direcionada a resolver quebra-cabeças e a programação nada mais era do que otimizar o desempenho do processo computacional. Essa visão existia porque as máquinas eram muito lentas e limitadas e com a revolução que estava acontecendo no hardware, em breve as máquinas seriam mais rápidas e poderosas e então todos aqueles truques que haviam sido inventados para superar essas limitações, não seriam mais necessários.

Mal se sabiam que depois que da tal evolução, os problemas de softwares se multiplicariam por causa de novos componentes. No começo os processos eram mais sequenciais e determinísticos, depois vieram as interrupções de I/O e novos desafios mais complexos e praticamente esse ciclo ocorre até hoje.

No início da década de 1960 chegou a terceira geração de computadores e os fabricantes prometiam o melhor custo/desempenho que gerações anteriores e os programadores descobriram que essa evolução trouxe mais complexidade para a programação por causa de um design, segundo ele, mal feito. Muita gente ficou frustrada em ter que acreditar que houve alguma melhoria, mas ele compara isso a dizer que o cigarro fazia bem para a saúde por isso muita gente fumava.

Ele faz alguns considerações sobre importantes linguagens de programação que ajudaram no desenvolvimento como FORTRAN, LISP e ALGOL e menciona PL/1 com uma analogia de pilotar um avião com 7.000 botões de comando. Isso me lembra a imensa lista de objetos, comandos e propriedades que precisamos aprender hoje para programar com HTML, JavaScript e CSS.

Ele também faz algumas previsões para o final da década de 1970: a programação seria uma atividade totalmente diferente; em pouco tempo o esforço de programação seria uma fração do esforço atual; os sistemas seriam livres de bugs porque programadores perderiam menos tempo com depuração de código; o custo da programação seria compatível com o preço do hardware. Mas se o processo desenvolvimento de software continuasse desajeitado e custoso tudo poderia ficar imprevisível. Me parece que ele acertou a última. =D

Para essas mudanças acontecerem ele colocou três premissas:

Deveria haver um reconhecimento dessa necessidade

Na época existia muito desconfiança com os softwares de modo geral, então ele entende que esse ponto estaria superado facilmente.

Deveria haver necessidade econômica

Ele faz uma conta dizendo que o custo do programador era proporcional ao custo da máquina e como havia uma previsão do hardware ter um custo muito menor com o passar do tempo, a sociedade não aceitaria pagar um valor alto pelo software, por isso o desenvolvimento deveria ser mais eficiente.

Precisaria ser tecnicamente possível

Nesse terceiro ponto ele apresenta algumas preocupações relacionadas aos bugs daquela época. Ele dizia que os programas não deveriam permitir instruções de desvio incondicional, o famigerado GOTO, e não permitir procedimentos que tivessem mais que um parâmetro de saída. Essa primeira parte, segundo ele, poderia ser resolvida através de uma nova linguagem de programação. A outra seria resolvida através da disciplina do programador: não adicionar nenhum loop sem uma prova de saída ou que tivesse instruções que quebrassem a relação invariante que permite ficar no loop. Isso significa não ter loop infinito ou ter quebra inesperada de loop.

Ele também escreveu 6 argumentos que, seguidos, poderiam ajudar nesse desafio técnico. Esses argumentos se baseiam em programas intelectualmente gerenciáveis. Eu não sei exatamente o que ele quis dizer com isso, mas me parece algo como criar uma classe de programas que resolvem certos problemas e isso seria suficiente para eles pudessem ser ligados entre si para resolver os outros problemas.

Os seis argumentos, de forma resumida e interpretada por mim, eram os seguintes:

1. O programador precisa apenas considerar os programas intelectualmente gerenciáveis.
2. Uma vez seguida a primeira lição, o espaço de soluções a atacar seria reduzido drasticamente de forma a ser mais fácil de lidar.
3. Um programa deve surgir de uma prova de confiança que indique a ausência de erro. 
4. Um programa deve ser construído com base em um padrão de abstrações já identificadas em outros programas.
5. As ferramentas de programação e a linguagem devem evoluir para facilitar a tarefa de programação.
6. A programação deve evoluir de forma hierárquica.

Me parecem bons argumentos. Trazendo para os tempos de hoje, ele estaria falando de seguir padrões de projeto, de seguir técnicas de teste que validam o programa, de programação em camadas e de aumentar a produtividade com uso de IDEs e melhorias na linguagens de programação.

A minha conclusão depois de ler esse artigo é que não há um fim para os desafios da computação. A ideia de que alguém estudou muito e assim se tornou o mestre dos magos é um erro porque nossa área está em constante mudança. Atualmente existe muita gente que diz que a programação se tornará mais fácil e automática e finalmente os programadores não precisarão mais se debruçar sobre grandes problemas. É aquela visão "Jarvis" de que você vai abrir uma conversa com uma máquina super inteligente e ela vai fazer o seu trabalho. A história parece mostrar que a gente precisa ser mais humilde.

Espero que tenha gostado da leitura. Por hoje é isso. Até a próxima.

PS: Caso queira ler o artigo original e ter sua própria interpretação, se chama The Humble Programmer.