[104437] Acho que tem algo errado!!

Minha inspiração para a coluna dessa semana foi o brilhante texto do Piropo sobre a “Lei de Moore-até quando”. Resolvi analisar este assunto, mas na perspectiva do desenvolvedor e dos usuários de informática e cheguei a conclusões surpreendentes.

Meu ingresso no mundo da informática se deu pelas calculadoras programáveis HP 25. Estas nem armazenavam os programas, ao ser desligada o programa digitado era perdido. A sua sucessora, a HP 25 C (C de contínua) armazenava o programa de até 50 instruções quando desligada. Que avanço não?!! Mas isso não podia ser chamado de computador pessoal.

HP 25C calculadora programável

Meu primeiro contato com um microcomputador foi por um TK-82C, uma prodigiosa máquina que continha linguagem Basic, era ligada a uma TV como monitor e um gravador cassete para armazenar os programas. Esta maquininha foi responsável por seu criador, Clive Sinclair, ter sido agraciado Cavaleiro da Coroa Britânica. “Sir” Clive Sinclair concebera em 1980/1981 uma máquina barata e realmente útil, pois sendo programada em Basic, uma incipiente, mas promissora linguagem permitia fazer programas bem interessantes a despeito de ter somente 2K bytes de memória. Sim você leu certo, são dois quilobytes de memória apenas. A minha eu expandi para “monstruosos” 16 Kbytes de memória e municiado com este computador fiz meu curso de engenharia. Fiz programas complexos em Basic para cálculos estruturais, análise de fadiga por Círculo de Mohr, desenvolvi rotinas em assembler de Z80 (8 bits). Foi uma super escola.

Saudosismo à parte eu confronto esta diminuta máquina, o TK82, com o meu notebook atual, que está longe de ser a última palavra (um P4 2.8 HT com 1 Gb de Ram). Eu nem me lembro de sua freqüência de operação, mas levando em conta que até hoje, 25 anos depois o Z80 ainda é fabricado e usado para controladores programáveis operando a 980 Khz posso deduzir que meu notebook tem um processador cerca de 3000 vezes mais rápido e tem pelo menos 60000 vezes mais memória. Ok você está achando essa comparação injusta então vamos avançar alguns anos no tempo.

Em 1991/1992 eu implantei o meu primeiro sistema desenvolvido para ambiente Windows. Rodava em centro médico de exames ultrassonográficos, sob Windows 3.11, em uma máquina com 4 Mbytes de RAM, um 386 de 16 Mhz. Estamos agora falando de uma máquina com 250 vezes menos memória que o meu pobre notebook e 175 vezes mais lenta. Essa comparação é muito boa, pois este sistema esteve em operação até 2004 e por isso é uma excelente base de comparação. Eu garanto que apesar da plataforma de hardware, software e sistema operacional ter sido atualizada até o ano passado, o benefício percebido no uso do sistema não chegou nem perto desta evolução de hardware e memória. Jamais eu poderia dizer que o sistema ficou 140 vezes melhor de ser utilizado. Ok eu devo entender que os benefícios não crescem na mesma proporção que o avanço da plataforma. Mas eu me arrisco a dizer que não houve ganho real de mais de 6 a 8 vezes, isso medido pela percepção de melhor serviço prestado pelo sistema.

O exemplo acima é uma ilustração, talvez não tão precisa quanto deveria mas ilustra que existe de fato a propalada disparidade entre a evolução do hardware e do software. Vou dar outro exemplo mais próximo a todos. Há muitos anos quando surge uma nova plataforma (processador, chipset, placa mãe e memórias) eu ouço a mesma afirmação : “Agora com a inovações trazidas por toda esta tecnologia viabilizaremos reconhecimento de voz, comandos de voz e ditado em linguagem natural para serem usados nos computadores pessoais”. Eu perdi a conta das vezes que eu ouvi isso sem que se concretizasse de fato. Algumas tentativas e até alguns softwares interessantes surgiram nessa área, mas não podemos dizer que isso seja lugar comum nos dias de hoje.

Ahhhhh mas então o benefício deve ter aparecido para os desenvolvedores, certo? Sim, de certa forma. Mas em minha opinião boa parte da culpa da propagação de ineficiência é culpa de quem desenvolve e falo isso sem vergonha ou remorsos, pois eu também vivo disso. Os ambientes integrados de desenvolvimento (IDE) são fantásticos, cheios de recursos, atalhos etc., mas não conduzem o desenvolvedor a buscar alternativas de otimização para o código gerado. Não quero dizer com isso que se deve voltar no tempo em que programadores armazenavam datas com dois bytes a menos para economizar espaço (que explodiu no episódio do Bug do Milênio), mas falta emprego de energia na busca de programas realmente melhores. Atribuo boa parte do sucesso do Linux ao fato de ter entrado no mercado com uma relação de qualidade especifica por linha de código escrita melhor que os tradicionais programas Windows.

Eu me lembro quando eu desenvolvi há muitos anos atrás um software para comunicação micro-mainframe (1987-1990), este tinha sido todo feito em Turbo Pascal. Depois as rotinas críticas foram identificadas e passadas para “C”. Mais tarde como ainda havia alguns fatores críticos de performance, algumas destas rotinas foram refeitas em Assembler de x86 (386) e somente nessa hora o desempenho esperado foi atingido.

Eu gosto de ilustrar as coisas por “extremos”, fica mais fácil de enxergar. Não quero dizer que essa escovação de bits toda seja necessária para quem desenvolve um mero sistema de cadastros. Mas muitas vezes a maravilha que é a linguagem SQL, a oitava maravilha do mundo para vasculhar tabelas, consultas, sub-consultas, etc. mal utilizada pode ser responsável por um fator de 10 (para baixo) no desempenho de uma aplicação. É comum ouvir algo assim “se está lento não se preocupe, pois com a nova CPU que estão lançando isso ficará rápido o bastante”. A produtividade do desenvolvimento foi muito melhorada, mas em detrimento da qualidade ou eficiência real dos softwares desenvolvidos. Claro que existem profissionais que trabalham bem o lado da eficiência, mas sou forçado a garantir que representam a exceção que confirma a regra. Pressões pelo cumprimento de prazos e metas levam-nos (eu me incluo nisso) a agir assim.

Somente uma nova guinada tecnológica vai abrir espaço para uma mudança desse paradigma de desenvolvimento de software.Se é que ela vai acontecer um dia. Talvez sejamos eternos escravos da produtividade contra a eficiência dos programas delegando ao avanço do hardware a missão de corrigir isso.