quinta-feira, dezembro 08, 2005

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...

4 comentários:

Matheus disse...

Mesmo eu não tendo vivido nesta época(Tenho Apenas 14 Anos!) eu acredito que essa era uma boa época!
Pretendo fazer faculdade de Engenharia/Ciência da Computação. Mas até lá, me contento programando em C para PIC e Visual Basic para PC...

Matheus de Paula Medeiros
http://osistemacaiu.blogspot.com/

Anchises disse...

Agorei o post, DQ. Eu não peguei esta fase, mas tive a oportunidade de pegar uma mudança no compilador Turbo Pascal e Tubo C (se bem me lembro) quando surgiu uma versão que permitia debugar o programa linha-a-linha. Foi uma mudança revolucionária (para a época - bem início dos anos 90), pois em vez de compilar e rodar o programa para ver o resultado, conseguíamos rodar o programa linha-a-linha, e assim achar o erro.
Antes disso, éramos obrigados a colocar várias impressões de resultado no meio da execução, para debugar e entender o que acontecia quando rodávamos o programa. E depois analisar e pensar bastante para dercobrirmos as alterações que seriam necessárias. Com essa história de rodar o programa linha-a-linha, na hora mesmo eu percebi que era uma faca de 2 gumes: ficava muito mais fácil e rápido debugar, mas por outro lado permitia uma grande preguiça mental e facilitava a programação por tentativa e erro.

Anônimo disse...

Caramba, é bom saber que ainda existem outros dinossauros que sobreviveram aos meteoros da tecnologia. Uma época que não era fácil pra ninguém, a gente passava mais tempo em cimas daquelas malditas folhas de codificação do que em frente a um terminal. Eu peguei o finalzinho da época do uso das folhas de codificação e se debruçar sobre listagens para descobrir erros, mas mesmo assim a coisa era tinha que ser feita com muita consciência, porque quando se colocar um programa de 3000 linhas em COBOL pra compilar num COBRA 300, dava pra ir ao banheiro (2x), tomar um cafezinho (5x), bater papo com a recepcionista da empresa, só dai que você tinha o programa compilado e a listagem, 3000 linhas, levava pelo menos uns 30 minutos pra compilar/linkar um programa.

Subnet Martins disse...

Realmente bate a saudade . . . .
E a história de vc compilar algumas pequenas quantidades de códigos, ou subrotinas de cabeça; já chamavam de mágica, na minha época. Agora, imagine alguém que sabe o que o objeto reutilizado faz. E como eh processado.Isto já é além da imaginação. Surreal! :D :) :D :)