Como eu Aprendi a Programar e Como Isto Me Afetou

Meu primeiro contato sério com programação foi no primeiro ano da faculdade, em 1977. O curso de Introdução à Computação para os alunos de Engenharia utilizava a linguagem Fortran IV. Mais que a linguagem, a forma como era feitos os exercícios práticos teve uma influência forte na minha forma de desenvolver software.

A primeira dificuldade era editar o programa. O programa era escrito em formulários especiais (folhas de codificação), que eram entregues para a digitação. Após 2 ou 3 dias, recebia-se o deck de cartões perfurados. Existia para os alunos uma sala com cerca de duas dúzias de perfuradoras, porém normalmente somente 2 estavam totalmente funcionando e várias estavam totalmente inoperantes. É claro que esta sala precisava ser compartilhada pelos 600 alunos do primeiro ano.

A USP dispunha na época de um mainframe Burroughs B6700. A interação dos alunos de toda a USP com ele era através da sala de auto-serviço (cafeteria), onde ficavam uma leitora de cartões e uma impressora. Filas para usar a sala não eram incomum.

O uso do computador era controlado por um sistema de créditos. No início do curso o aluno recebia uma certa quantidade de créditos (algo entre 35 e 45) para serem usados em todos os exercícios do semestre (4 ou 5). Cada execução de programa (tanto o compilador como o seu) consumia um crédito. Existiam limites de tempo e de linhas impressas para o interromper programa em loop ou abusos (tem a famosa estória do poster da Mona Lisa, mas fica para outro dia).

Chegada a sua vez na fila, você colocava os cartões na leitora, apertava um botão, recolhia os cartões lidos e ia rezar na frente da impressora. Após alguns minutos, saia a sua impressão e você saia da sala para analisá-la.

Tratava-se, portanto de uma ambiente sem depuração interativa e com fortes restrições para o ciclo editar-compilar-executar. O resultado era pensar muito mais que codificadar. Na escola faziam-se coisas como o “teste de mesa”, simulando a execução do programa com papel e lápis. O deck de cartões era verificado à mão atrás de erros de sintaxe. Quando ocorria um erro, se procura entender direitinho as causas e verifica-se atentamente se o erro era repetido em outros pontos. Cada letra da impressão de saída era examinada atrás de pistas dos erros.

Embora o processo de desenvolvimento tenha melhorado muito com o passar dos anos nas minhas experiências fora da escola (estágio e posteriormente trabalho), restrições ainda estariam presentes por cerca de uma década. Por exemplo, em 1987 era comum usar um PC sem HD, usar um editor separado do compilador e depurar em assembler com o debug ou o symdeb.

Atualmente trabalhamos em ambientes integrados, que compilam programas em segundos (ou menos) e dispomos de depuradores altamente interativos. Se por um lado isto evita processos ineficientes (como a conferência manual de sintaxe), incentiva também um procedimento preguiçoso e a técnica de programação por tentativa e erro. Quantas vezes corrigimos apenas os primeiros erros de sintaxe indicados e mandamos recompilar ao invés de examinar os outros erros da lista? Quem nunca saiu testando alternativas ao invés de consultar uma documentação ou pensar um pouco? Quantos ainda rabiscam papel tentando conferir um algorítmo ao invés de ir andando passo a passo, corrigindo somente os erros com os quais topar?

Um pouco das técnicas passadas ainda me acompanham até hoje. Particularmente, tenho uma tendência a usar pouco depuradores. Entre outras coisas, é sempre divertido surpreender alguém apontando um erro no código somente olhando o fonte e o resultado. Alguns até acham isto mágica...