Resumo

  • Depois de voltar ao serviço na U.S. Navy em 1967, Grace Hopper ajudou a transformar objetivos de padronização de compiladores em uma equipe e um processo de teste. Na história oral de 1980, ela atribuiu a George Baird uma técnica importante para executar rotinas comuns de COBOL e FORTRAN em computadores diferentes.
  • Os testes da U.S. Navy tornavam observáveis determinados recursos da linguagem e os resultados produzidos. Eles não provavam que um compilador estava totalmente correto, que todas as combinações possíveis haviam sido testadas ou que qualquer aplicação migraria sem alterações.
  • Norma, evidência de que um compilador passou por casos nomeados e prova de que um programa específico funcionará em outro ambiente são afirmações relacionadas, mas distintas. Confundi-las transforma evidência delimitada em promessa irrestrita.

A norma era um alvo, não um resultado

Uma agência que comprava computadores de vários fabricantes tinha uma razão concreta para querer uma linguagem comum: evitar que todo programa ficasse preso para sempre ao equipamento de um único fornecedor. Mas encontrar COBOL em duas propostas comerciais não dizia se os compiladores aceitariam os mesmos recursos obrigatórios nem se produziriam as mesmas respostas.

A norma definia o comportamento esperado; não media automaticamente o produto entregue. O comprador precisava de uma verificação repetível: um programa que o compilador deveria aceitar, um resultado previsto, o resultado observado e um relatório capaz de apontar onde surgiu uma divergência. A promessa de compatibilidade passava, assim, a ser uma pergunta operacional.

Esse recorte situa um episódio menos conhecido da carreira de Hopper. Em vez de repetir a narrativa sobre a invenção do compilador ou tratar COBOL como obra de uma única pessoa, vale acompanhar o trabalho posterior de transformar a padronização em validação. A portabilidade dependia da sintaxe compartilhada, mas também do comportamento real do compilador e daquilo que os testes conseguiam demonstrar.

O esforço tinha antecedentes coletivos. Em seu artigo de 1972 sobre o sistema de validação de compiladores COBOL do Department of Defense, George N. Baird descreveu um grupo de trabalho iniciado em 1963. Seus programas verificavam se compiladores ofereciam recursos especificados pela norma. O objetivo não era depurar cada produto nem explorar todas as combinações possíveis: era selecionar funcionalidades, testá-las isoladamente e em combinações escolhidas, e registrar o que acontecia.

Fazer a falha aparecer

Baird descreveu as primeiras rotinas da U.S. Navy como uma continuação desse trabalho, com relatórios mais úteis. Elas podiam comparar a saída efetiva com a esperada e indicar o procedimento em que uma falha aparecia. A versão preliminar reunia 12 programas e cerca de 5.000 linhas de código-fonte.

Essa especificidade muda o sentido da palavra “compatível”. Em vez de uma afirmação ampla do fornecedor, o comprador podia perguntar se aquela versão do compilador aceitava aqueles recursos e produzia aquelas saídas sob determinadas condições. Outra equipe podia repetir o teste e comparar resultados. O processo não eliminava a necessidade de julgamento; tornava parte do julgamento verificável.

Hopper organizou uma capacidade, não um ato solitário

Na entrevista de história oral de 1980, Hopper contou que Norman Ream, responsável por processamento automático de dados na U.S. Navy, pediu que ela voltasse ao serviço ativo em 1967. Ela descreveu uma missão de desenvolver procedimentos de teste e validação que apoiassem normas de linguagem e ajudassem a tornar o software mais portátil. Para explicar a lacuna, comparou o trabalho à necessidade de testar um produto contra uma especificação.

Hopper disse que pediu programadores para realizar a tarefa. Entre as pessoas que citou estavam o civil Ed Ford, um tenente e dois marinheiros, incluindo Baird; Arnold Johnson se juntou ao grupo mais tarde. Uma reportagem da Datamation de 1971 descreveu a rotina de validação da U.S. Navy como desenvolvida por uma equipe chefiada pelo Captain Hopper. Isso sustenta seu papel de liderança, não a ideia de que ela escreveu sozinha o sistema.

A cronologia também pede precisão. Em janeiro de 1971, a Datamation noticiou que a U.S. Navy exigia validação de compiladores COBOL e que o Department of Defense e o National Bureau of Standards haviam concordado, em princípio, em desenvolver rotinas padronizadas contra a norma ANSI. Um acordo “em princípio” não equivale a um serviço governamental completo. A notícia registra a direção institucional naquele momento, não a conclusão posterior de todo o trabalho.

O mecanismo que Hopper atribuiu a Baird

O trecho mais revelador do depoimento de Hopper é um crédito explícito. Ela disse que Baird criou uma técnica para separar os nomes especiais e detalhes de cartões de controle próprios de cada máquina dos testes comuns. Um arquivo pequeno de configuração fornecia as diferenças necessárias para cada computador; as rotinas compartilhadas permaneciam em COBOL padrão.

Assim, o próprio conjunto de testes precisava ser portátil. Se cada verificação tivesse de ser reescrita para cada compilador, manter comparações consistentes ficaria mais caro e mais sujeito a diferenças acidentais. Separar a lógica comum da configuração específica permitia reutilizar os testes sem fingir que todas as máquinas tinham convenções idênticas.

A lembrança de Hopper é retrospectiva e deve ser lida como seu relato sobre o desenho e a divisão de trabalho da equipe. O artigo de Baird, publicado em 1972, confirma de forma independente o sistema de validação e sua estrutura técnica. Em conjunto, as fontes sustentam uma atribuição equilibrada: Hopper ajudou a estabelecer a missão e a equipe; Baird forneceu um mecanismo importante entre máquinas; e a história da padronização e dos testes incluiu outros participantes e predecessores.

O que um teste aprovado não demonstrava

Um resultado positivo mostrava que o compilador tratou corretamente os recursos selecionados e produziu as saídas esperadas nas condições do teste. Não mostrava que a suíte cobria toda combinação permitida, todo defeito possível ou cada programa que uma agência viesse a escrever.

Essa limitação não era exclusiva do COBOL. A história do NIST sobre uma iniciativa separada de testes de FORTRAN, conduzida por Betty Holberton e Elizabeth Parker, explica por que um conjunto finito de testes não pode provar a correção completa de um compilador. Era um projeto paralelo do National Bureau of Standards, não a suíte COBOL da U.S. Navy associada a Hopper. A distinção é importante: diferentes equipes e linguagens estavam tornando a conformidade uma prática institucional.

Conformidade do compilador e portabilidade de uma aplicação também ocupam níveis diferentes. Um compilador pode passar por testes selecionados enquanto um programa depende de uma extensão do fornecedor, de um serviço do sistema operacional, de um formato de arquivo ou de um comportamento do ambiente de execução. Essa conclusão decorre do escopo limitado dos testes; não significa que a suíte da U.S. Navy tenha examinado cada dependência desse tipo. Migrar uma aplicação exige testes no nível da própria aplicação e uma descrição do ambiente em que ela foi executada.

A lição prática não é desconfiar de normas ou de testes. É nomear a evidência com exatidão: a norma define o comportamento esperado; a suíte de conformidade verifica uma amostra delimitada da implementação; o teste de migração examina o sistema que o comprador pretende mover. Chamar as três coisas simplesmente de “portabilidade” esconde onde o risco continua.

Uma contribuição mais duradoura que um mito

O papel de Hopper nesta história fica mais interessante quando não é exagerado. Ela ajudou a converter uma ambição ampla de interoperabilidade em uma capacidade de validação com equipe e procedimentos. Também descreveu uma prática de gestão que costuma desaparecer nas histórias de inventores solitários: formar uma equipe e atribuir publicamente o crédito a quem concebeu um mecanismo técnico essencial.

A contribuição de Baird mostra por que essa atribuição importa. A portabilidade não dependia apenas do que um comitê prometia no texto de uma linguagem. Dependia do desenho dos testes, da configuração por máquina, da comparação de saídas e da possibilidade de repetir a execução. Sem testes observáveis, uma norma deixava o comprador com uma declaração. Sem limites explícitos, um resultado aprovado podia virar uma promessa maior do que a evidência. Sem crédito adequado, a explicação técnica também ficava incompleta.

Para software de longa duração, o comprovante deve acompanhar a afirmação: qual revisão da norma, qual versão do compilador, quais testes, qual configuração por máquina e quais resultados? O trabalho da U.S. Navy não eliminou diferenças entre fornecedores. Tornou algumas delas visíveis para que instituições pudessem comparar implementações e decidir compras com evidência melhor delimitada.

Fontes