Programando com um Violão

Hoje, se um programador quiser adicionar música a uma aplicação, o processo é trivial. Ele importa uma biblioteca, aponta para um ficheiro MP3 ou WAV e, com uma única linha de código, o som toca. A abundância de ferramentas e recursos tornou a multimidia uma tarefa simples. Mas o que farias se quisesses compor uma melodia inteira e a tua única ferramenta de som fosse a capacidade do computador de emitir um único "bipe"?

Em 1992, na faculdade, deparei-me exatamente com este problema, e a solução ensinou-me duas das lições mais duradouras da minha carreira: a primeira sobre como a escassez força a verdadeira criatividade, e a segunda sobre a relação invisível, mas brutal, entre o software e o hardware que o executa.

O desafio era um trabalho em grupo para a disciplina de programação, usando Borland C. Decidimos fazer um jogo da memória em modo gráfico, algo que já era um desafio por si só. Mas para dar um toque especial, uma "feature" que nos diferenciasse, decidimos que o nosso jogo teria música. Como éramos Colorados fanáticos, a escolha foi óbvia: as cartas teriam o símbolo do Sport Club Internacional e, enquanto a pessoa jogava, o computador tocaria o hino do Inter.

A ideia era fantástica, mas a realidade técnica era desoladora. Não havia MP3, WAV ou qualquer formato de áudio. A única ferramenta que a linguagem C nos oferecia para produzir som era um comando chamado sound. Este comando fazia apenas uma coisa: emitia um bipe contínuo numa frequência específica que nós definíamos. Como poderíamos transformar uma sequência de "bipes" monótonos no hino do nosso clube?

A solução não veio de um livro de programação. Veio da criatividade nascida da limitação. A solução foi analógica. No grupo para o trabalho, tinha eu, Eduardo Magalhaes e o Eraldo Junior. O meu colega, o Eduardo Magalhães, sentou-se ao meu lado, na sala onde programávamos, com o seu violão. O processo que se seguiu foi uma fusão bizarra entre música e código, um dueto entre um violão e um PC.

Funcionava assim: o meu colega tocava a primeira nota do hino no violão. Eu, no computador, ficava a testar valores numéricos no comando sound do C, compilando e executando repetidamente. "Mais agudo... não, mais grave... aí, quase!". Continuávamos até que o bipe emitido pelo PC soasse exatamente como a nota que saía do violão. Anotávamos aquele número. Depois, passávamos para a segunda nota do hino e repetíamos o processo. Fizemos isto para cada nota, para o hino inteiro, numa maratona de paciência acústica e digital.

Depois de dias, conseguimos. O nosso jogo da memória não só funcionava como tocava uma versão reconhecível, ainda que robótica, do hino do Internacional. Estávamos orgulhosos. Desenvolvemos e testamos tudo no computador que ele tinha em casa, um 286 com um monitor EGA. O nosso melhor tempo para resolver o jogo era de 30 segundos. Achávamos que era um tempo excelente.

Então, veio o dia da apresentação na faculdade e a segunda grande lição. O laboratório já tinha sido atualizado. Em vez do nosso 286, lá estava um 386 SX, uma máquina muito, mas muito mais rápida. O professor, curioso, pediu para testar o jogo. Ele começou a jogar e, para o nosso espanto, aniquilou o nosso recorde. Ele cravou 10 segundos.

A nossa reação inicial foi de frustração. Como é que ele era tão mais rápido do que nós, os criadores do jogo? Demorou um pouco para a ficha cair e entendermos o óbvio: não era o professor que era mais rápido, era a máquina. Toda a lógica do nosso jogo, o tempo de resposta, as animações, os loops, corria a uma velocidade brutalmente superior naquele processador mais potente. Foi a primeira vez que vi, na prática, o impacto direto e inegável da velocidade do hardware no desempenho do software (leia também o artigo "O Despertar dos Múltiplos Núcleos - A Teoria da Concorrência" que discute a evolução da performance do hardware).

Aquelas duas lições ficaram comigo para sempre. A primeira é que a criatividade não floresce na abundância de ferramentas, mas na escassez delas. A limitação de ter apenas um "bipe" forçou-nos a encontrar uma solução híbrida e engenhosa que nunca teríamos considerado num mundo de MP3s fáceis. A segunda é que o nosso código nunca vive num vácuo. Ele é um parceiro numa dança constante com o hardware que o executa, e entender essa relação é fundamental para compreender a verdadeira performance de qualquer sistema.

Este artigo é baseado numa história de "Dos 5 Minutos de uma Fita Cassete a 40 Anos de Código", as memórias do autor.
Leia a história completa aqui.