Fechando o Circuito
É 1955. Você é cientista no laboratório de computação da Universidade de Michigan. O laboratório abre às seis da manhã, mas você chega às cinco e meia. Não por obrigação, não porque alguém mandou, mas porque você não consegue dormir por estar entusiasmado com o trabalho.
Três semanas. Três semanas é o tempo que você tem passado lendo o manual ténico do computador do laboratório. Um documento de 240 páginas escrito em "linguagem de engenharia", denso e cheio de termos ténicos como um contrato jurídico, cheio de diagramas de circuitos e tabelas de sinais elétricos que você precisa ler, reler e reler de novo até que você entenda como fazer um código funcionar nela, de acordo com as necessidades do seu laboratório. Você passa três semanas escrevendo código, testando, corrigindo, testando de novo. Três semanas nessa sala, desde manhã até à noite, com o mesmo barulho constante das máquinas ao fundo, um zumbido mecânico que você nem repara mais de tanto que já se acostumou ao ambiente.
Na sexta-feira anterior, às onze da noite, o programa que você estava escrevendo finalmente tinha funcionado. Você viu os primeiros caracteres saindo pela impressora, os resultados do cálculo aparecendo exatamente como deviam aparecer. Você ficou olhando para aquele papel por um tempo que provavelmente era longo demais para alguém observando você. Mas três semanas de trabalho estavam ali, naquelas linhas impressas. Você tinha o direito de olhar.
Na manhã de segunda feira, você entra no laboratório com um maço de cartões perfurados debaixo do braço - os computadores da época trabalhavam com cartões perfurados - eram o programa que você passou as três semanas anteriores construindo, e encontra dois técnicos desparafusando o computador do laboratório e o levando embora.
No lugar dele, ainda embalado parcialmente em plástico, há um computador novo. Mais moderno. Mais rápido. De outro fabricante.
Ninguém te avisou.
Você fica parado por um momento olhando para a máquina nova, e já sabe o que aquilo significa antes mesmo de alguém falar com você. Conhece esse sentimento. É o sentimento de que o chão sumiu. De que todo trabalho foi em vão.
Trocaram o computador porque esse novo é capaz de fazer os mesmos cálculos na metade do tempo. Mas isso significa que você teria que escrever um código novo do zero para esse computador.
Não importa que o código anterior estivesse correto. Não importa que os cálculos estavam certos. O computador novo não entende uma única instrução que você havia escrito. Ele é de um fabricante diferente, tem uma lógica diferente, espera sinais diferentes, numa ordem diferente. Tudo que você aprendeu sobre o computador antigo não serve para nada agora. O manual novo tem 280 páginas. Você vai ter que recomeçar do zero.
Você coloca os cartões em cima da mesa, puxa a cadeira, senta e fica olhando para o computador novo por um tempo que, desta vez, definitivamente é longo demais.
70 anos depois, numa tarde de terça-feira, um homem chamado Tomás está no Aeroporto Internacional de São Paulo esperando o embarque do seu voo. Ele viaja a trabalho três vezes por mês, e aprendeu faz tempo que depois de passar pela segurança e chegar no portão de embarque, os aeroportos são lugares para não pensar: você encontra uma cadeira, tira o celular do bolso, e deixa o tempo passar até a hora de embarcar.
O celular toca. É uma notificação da esposa.
Ele abre o Whatsapp e vê que é um vídeo de 2 minutos. O filho de 1 ano e 2 meses está de pé, no meio da sala, segurando o sofá com uma das mãos, e claramente prestes a soltar. A esposa filma em silêncio, sem se mexer, sem falar, para não assustar. E então o menino solta o sofá. Fica de pé sozinho por talvez dois segundos, com aquela expressão de absoluta concentração que crianças pequenas têm quando estão fazendo algo que exige todo o esforço que têm. E então dá um passo. E outro. E cai sentado no tapete com um baque macio, e olha para a câmera com uma cara de quem não tem certeza se deve rir ou chorar, e a esposa explode em gargalhadas atrás da câmera, e o menino decide que vai rir também.
Tomás assiste três vezes seguidas ali na cadeira do aeroporto, com a mala entre as pernas e o barulho de anúncios ao fundo, e na terceira vez, sai uma lágrima de seus olhos de um jeito que ele não estava esperando.
Em outro canto do país, no Rio de Janeiro, uma médica chamada Isabela abre no computador do consultório o resultado de um exame de ressonância magnética. A imagem carrega na tela, cinza e detalhada, e ela aproxima o rosto do monitor. Fica em silêncio por quase um minuto. O resultado é o que ela esperava. Não é o que esperava para o paciente.
É 00:43. Neo tem vinte e dois anos, mora sozinho num apartamento pequeno, e está deitado na cama com um fonte de ouvido velho que já perdeu metade do amortecimento da espuma. Ele coloca uma música que não houvia faz quatro anos. Os primeiros segundos tocam, e alguma coisa no peito aperta de um jeito que ele não saberia explicar se tentasse. É uma música que ele houvia numa época específica da vida, com pessoas específicas, num lugar que não existe mais exatamente como naquela época. A música não mudou, é a mesma. Ele que mudou. E os dois, a música e ele, estão se encontrando do outro lado de quatro anos como duas pessoas que se conheceram num lugar e se reencontram em outro, e precisam de um momento para se reconhecer.
Numa sala de aula de uma universidade federal, Mariana aperta Ctrl+S no documento onde está o terceiro capítulo da sua dissertação de mestrado. Oito meses de trabalho. Ela aperta quase por reflexo a cada frase que digita, como todo mundo que já perdeu alguma coisa importante uma vez e nunca mais esqueceu que precisa salvar. Dois segundos depois a energia do prédio cai. A tela escurece. Mariana fica olhando para o monitor apagado no escuro, e então sorri sozinha, aliviada de um jeito que só faz sentido para quem já perdeu algum trabalho e sabe exatamente de que tamanho é o alívio de saber que seu trabalho está a salvo.
O que você não viu acontecendo
Você deve ter percebido que essa seção começou de forma diferente das anteriores. Sem tabelas, sem conversões matemáticas. Só histórias. Isso foi intencional.
Estamos na última seção do capitulo, e eu queria que você chegasse até aqui com a mesma leveza de quem chegou à última página de um livro muito bom: não com a sensação que ainda tem muito pela frente, mas com curiosidade de quem quer saber como a história termina.
E tem algo escondido em todas essas histórias que contei. Um pai recebendo o vídeo dos primeiros passos do filho, uma médica abrindo um exame que vai mudar a vida de um paciente, um rapaz sendo levado de volta por uma música a uma época que não volta mais, uma estudante que salva o arquivo dois segundos antes da energia acabar...
São situações que qualquer pessoa reconhece. E o que permitiu que todas elas fossem possíveis, é justamente o que estudamos no capitulo inteiro. Está acontecendo por baixo de tudo, invisível e silencioso sem as pessoas nem notarem: bytes sendo movidos de um lugar para o outro, bytes sendo lido e interpretados, bytes sendo transformados em imagem, em som, em texto guardado permanentemente num disco.
Mas quem move esses bytes? Quem decide o que cada sequência de bytes significa? Quem garante que o vídeo do filho chega como vídeo, e não como zeros e uns? Quem faz com que a música toque em vez de exibir uma tela de erro? Quem garante que o documento da Mariana esteja intacto quando ela religar o computador?
Essa pergunta ficou sem resposta no final da seção anterior.
E a resposta começa exatamente onde começamos no começo desta seção: naquela sala de 1955, onde você estava olhando para um computador novo que não entendia uma palavra do código que você já havia escrito. Porque o que você viveu naquela manhã não era um problema pessoal, nem um azar isolado. Era um problema que toda a computação vivia ao mesmo tempo, e cuja solução mudaria para sempre a forma como software (código que roda no computador) e hardware (as partes físicas do computador) se relacionam.
É hora de respondê-la.
Como os computadores funcionavam no começo
Os computadores de 1950 não tinham teclado. Não tinham mouse. Não tinham tela. Como você já viu na seção anterior, eram máquinas enormes que ocupavam salas inteiras, cheias de cabos, válvulas e componentes eletrônicos, e que se comunicavam com os programadores de uma forma diferente de tudo que você conhece hoje: por meio de cartões perfurados.
Cartões perfurados e operadores
Um cartão perfurado era exatamente o que o nome sugere: um retângulo de papelão rígido, mais ou menos do tamanho de uma nota de dinheiro, coberto de pequenos furos em posições específicas. Cada posição no cartão podia ou não ter um furo, e essa combinação de furos e ausência de furos representava informação - exatamente como zeros e uns representam informação dentro do computador, só que de forma física, que você podia segurar nas mãos. Um programa completo era um maço de cartões, às vezes dezenas deles, às vezes centenas, cada um representando uma linha de instruções para o computador. Você carregava o seu programa literalmente debaixo do braço.
Para executar um programa, você não simplesmente "abria" ele como faz hoje. Você entregava o seu maço de cartões para uma pessoa específica cujo trabalho era operar o computador. Essa pessoa se chamava operador.
O operador era o intermediário entre os pesquisadores e a máquina. Ele recebia os programas em forma de cartões, os carregava fisicamente no computador na ordem correta, iniciava a execução, aguardava o resultado ser impresso em papel, e então entregava o papel de volta ao pesquisador que tinha solicitado. Ninguém mais tocava no computador. Você entregava os cartões, esperava, e recebia um papel com o resultado.
Esse processo tinha um problema óbvio: você esperava muito. Se havia dez pesquisadores querendo executar programas naquele dia, o operador precisava processar cada um dos dez por vez. Enquanto seu programa não chegasse à frente da fila, você não tinha nada para fazer além de aguardar. Às vezes horas. E se o seu programa desse erro no meio da execução, você recebia de volta uma folha com uma mensagem de erro, precisava encontrar o problema, perfurar cartões novos com a correção, e voltar para o fim da fila.
Isso que era ser um programador naquela época.
Mas a espera do pesquisador, por mais frustrante que fosse, não era o maior problema. O maior problema estava no próprio computador.
O problema que ninguém conseguia ignorar
Entre a execução de um programa e o seguinte, o computador ficava completamente parado. O operador precisava descarregar os cartões do programa anterior, organizar o maço, pegar o próximo maço de cartões da fila, carregá-los na máquina, verificar se estavam na ordem certa, e só então iniciar a próxima execução. Durante esse tempo todo a máquina não fazia nada. O processador, o compoenente mais caro e mais poderoso do sistema, ficava parado esperando um ser humano terminar de manusear papelão.
E também não era só nas trocas entre programas. Mesmo que o computador tivesse em execução, o processador passava muito tempo sem trabalhar. Para entender por quê, pense no que acontecia quando um programa precisava imprimir um resultado.
A impressora era um dispositivo mecânico. Ela tinha partes físicas que se moviam: uma cabeça de impressão que percorria o papel, um mecanismo que avançava no papel linha por linha. Comparada ao processador, que operava em frações de segundo, a impressora era absurdamente lenta. Quando o programa enviada dados para ela, o processador precisava esperar a impressora terminar antes de continuar. E enquanto esperava, ele não fazia nada. Nenhum cálculo, nenhuma instrução útil. Ficava parado, aguardando um mecanismo mecânico terminar o seu trabalho em velocidade de mecanismo mecânico.
O mesmo acontecia com a leitura dos próprios cartões perfurados. O leitor de cartões era um dispositivo físico que precisava passar cada cartão por um sensor. Comparado ao processador, era lento da mesma forma que a impressora. O processador enviava um comando para ler o próximo cartão, e então esperava. E esperava. E esperava.
Num equipamento que custava o equivalente a vários milhões de reais de hoje, essa era a realidade: a parte mais cara e mais poderosa do sistema passava boa parte do seu tempo fazendo absolutamente nada, esperando por coisas mais lentas terminarem.
Como você já deve imaginar, inevitavelmente as instituições começaram a pensar: precisa existir uma forma melhor de organizar tudo isso.
O programa que gerenciava outros programas
O primeiro passo concreto veio em 1956, de uma parceria improvável. A General Motors, uma das maiores montadores de automóveis dos Estados Unidos, e a North American Aviation, fabricante de aviões e equipamentos aeroespaciais, eram clientes do mesmo computador: o IBM 704, um dos mais poderosos da época. As duas empresas enfrentavam o mesmo desperdício todos os dias, e decidiram tentar resolver o problema juntas.
O que elas criaram foi um programa para o computador. Não só mais um programa, foi um programa especial. Não era um programa que fazia cálculos ou que processava dados de negócio. Era um programa cujo objetivo era gerenciar outros programas. Ele se chamou GM-NAA I/O, nome formado pelas iniciais das duas empresas mais a sigla de Input e Output, que em inglês é Entrada e Saída.
O funcionamento dele até que era simples, mas revolucionário: em vez de o operador carregar um programa por vez e esperar cada um terminar antes de carregar o próximo, O GA-NAA I/O permitia que todos os programas do dia fossem carregados de uma vez só, num único grande lote de cartões. A partir daí, o próprio sistema executava um programa, passava automaticamente para o seguinte quando terminava, e assim por diante, sem parar, sem esperar o operador, sem pausa entre um e outro.
Pela primeira vez na história, um computador estava gerenciando a si mesmo.
Dica de nomenclatura
O GM-NAA I/O inaugurou uma forma completamente nova de trabalhar com computadores, que ganhou um nome que existe até hoje: processamento em lote, do inglês batch processing.
Se você alguma vez ver esse termo por aí, já sabe de onde vem. O nome vem exatamente da ideia central: em vez de o operador carregar um programa por vez, ele agrupava todos os outros do dia num único lote de cartões, carregava tudo de uma vez só, e o sistema se encarregava de executar cada um em sequência, sem precisar de mais nenhuma intervenção humana até o final.
O tempo que antes era desperdiçado nas trocas manuais entre programas desapareceu. A IBM (a fabricante do computador) percebeu imediatamente o potencial e, ao longo dos anos seguintes, foi desenvolvendo e distribuindo seus próprios programas semelhantes para os seus clientes, tanto para computadores que já estavam em uso quanto para os novos que saíam de fábrica. As outras fabricantes seguiram o mesmo caminho. Em poucos anos, o processamento em lote deixou de ser uma solução criativa de duas empresas e se tornou o padrão esperado de qualquer computador vendido para uso institucional.
Vale notar
Naquela época, nenhum fabricante vendia software separadamente: o modelo de negócio era vender o hardware, e qualquer software vinha junto, sem custo adicional, como parte do pacote. Quem já tinha um computador recebia do fabricante os novos sistemas por meio de fitas magnéticas ou cartões perfurados enviados pelo próprio fabricante, carregava no computador, e passava a tê-lo disponível. Quem comprava um computador novo recebia tudo junto desde o início.
Havia ainda um outro caminho para que esses sistemas chegassem aos laboratórios: comunidades de usuários organizadas por fabricante, onde compartilhavam entre si os programas que desenvolviam.
Em 1955, alguns usuários de computadores da IBM fundaram um grupo chamado SHARE, com o objetivo de compartilhar programas e sistemas entre as instituições. Os usuários de computadores da Unicav tinham o USE, de Univac Scientific Exchange. Existiam várias comunidades diferentes.
O próprio GM-NAA I/O foi distribuido pelo SHARE antes mesmo de a IBM desenvolver suas próprias versões equivalentes. Era uma espécie de comunidade de troca, onde quem resolvia um problema compartilhava a solução com todos os outros que tinham o mesmo computador.
Foi um avanço enorme. Mas à medida que os laboratórios e empresas em todo mundo começaram a trabalhar dessa forma, ainda tinha um outro problema que o processamento em lote não resolvia.
Mesmo com o GA-NAA I/O gerenciando a fila, quando um programa começava a rodar, ele ainda tomava o computador inteiro para si. Todos os outros programas do lote ainda ficavam esperando. Todos os outros pesquisadores ficavam esperando. Se o seu programa levava quatro horas para terminar, quatro horas era o tempo que todo o resto ficava na fila, sem poder fazer nada.
O fato de boa parte do tempo o processador não estar realmente trabalhando começou a se tornar frustrante para os pesquisadores. Como você já sabe, ele ficava grande parte do tempo esperando outras coisas como a impressora e o leitor de cartões. O programa mais lento do sistema não era o programa em si, era o hardware físico ao redor dele. E enquanto esse hardware trabalhava em velocidade de hardware físico, o processador ficava parado.
A pergunta que começou a incomodar cada vez mais pesquisadores era simples: se o processador ficava parado enquanto um programa espera pela impressora, por que não aproveitar esse tempo para adiantar outro programa?