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.

Comentários (23)   Visitas (17202)

danylee

Pois é.
Atualmente, para todas as empresas que trabalham com desenvolvimento de software, tempo é dinheiro.
Para poder cumprir os prazos prometidos dos seus produtos, que aliás são vendidos por pessoas cujo único envolvimento nas fases de análise e programação é colocar pressão para o cumprimento de cronogramas apertados e surreais, utiliza-se a famosa máxima da cavalaria da programação: "rápido e mal feito".
Compromisso com a qualidade ? Isso é raridade.
O importante para os tecnocratas é que o programa/sistema funcione conforme a especificação. Para isto existe o teste de software, que raramente é realizado da maneira correta. A preocupação com a performance neste cenário fica sempre em último plano.
E por falar em desempenho, alguém já viu alguma aplicação feita em Java que seja rápida ?

danylee - Porto Alegre - 20/02/2005 - 18:00 - Responder no fórum

m0r53

nao sei se o java eh um bom exemplo pra isso..
toda aplicacao que roda sobre maquina virtual tende a ter uma performance menor do q as nao rodam multiplataforma..
agora, acho pouco provavel q um dia esse paradigma de fazer rapido e mal feito seja colocado de lado..
soh vejo algo assim c derrepente chegasse-mos ao limite fisico de hardware e entao a otimizacao seria obrigatoria, mas acho q nunca chegaremos a esse ponto.. a evolucao eh sempre continua nesse sentido.. pelo menos c focar-mos no presente (agora e nos proximos 100 anos pelo menos) nao vejo um movimento de limitacao fisica para o hardware.. qdo chegar ao limite do silicio (lei do moore) acredito q outros materiais e tecnologias o substituirao, dando um salto ainda maior nesse segmento..
falow ae pra todos
ate mais

m0r53 - Luis Eduardo Magalhães - 20/02/2005 - 21:33 - Responder no fórum

T-Rodman

Lendo isso, algumas palavras-chave me vem à cabeça: bibliotecas, DLL's, DirectX, módulos em Delphi ou VB (...) - isso facilita muito quem programa (ou acha que sabe programar?!?) mas acaba limitando às vezes os horizontes da programação, e tambem deixa o programa final muito maior do que o esperado.
De outro lado, quem tem de rodar fino - são as plataformas desenvolvidas para celulares. Outra pena... hoje em dia tudo está se voltando para Symbian ou WindowsCE, ou seja, os processadores para 'mobile' estão ficando mais rápidos, porém estão utilizando mais uma vez processos e programas mais lentos...
Ah, Java deve rodar legal e rápido nos servidores Sun. Eles não precisam de máquina virtual. Já os PC's, celulares e afins... a histórinha a gente já conhece. Será que vamos ter paciência em esperar nossos celulares rebootarem?
Amplexos

T-Rodman - Jau/SP - 21/02/2005 - 11:39 - Responder no fórum

Paulo Couto

é aquela velha questao de que tempo é dinheiro:
as interfaces de programalção (IDE) das principais ferramentas são mais apropriadas para o rapido desenvolvimento do que para a otimizaçao. para quem vende o software, tempo de desenvolvimento é custo.
para quem compra, o custo de processamento nao é importante (muitas vezes nem avaliado) se estiver dentro da capacidade da instalação existente. só começa a preocupar quando motivar um upgrade, ou se a aquisição daquele software requerer uma atualizaçao no hardware.
e mesmo em teoria, o custo do processamento tem baixado com o tempo, equanto o custo de mão de obra especializada tem subido. embora pouco logico para quem é purista (como eu e tantos outros aqui), a tendencia é os softwares engordarem cada vez mais...
isso ajuda a mover a industria do hardware...

Paulo Couto - Rio de Janeiro - 21/02/2005 - 14:42 - Responder no fórum

B.Piropo

Mestre Xandó:
Só agora entendi seu comentário desta manhã (eu ainda não havia lido a coluna), obrigado pela citação.
No mais: que saudades da minha HP 51...
Foi nela que aprendi a programar em assembly...
Pena que, quando aprendi, não tinha a menor idéia que AQUILO era assembly. Só descobri muitos anos depois, quando aprendi assembly para Z80 e, depois, para 8086.
Bons tempos, que não voltam mais...
Abraço
BP

B.Piropo - Rio de Janeiro - 21/02/2005 - 19:26 - Responder no fórum

Flavio Xandó

Mestre, quantas lembranças né? Eu tinha um amigo cujo pai tinha uma HP67 (acho que era esse o modelo) que gravava em uma tarja magnética, um tipo de cartão, era meu sonho de consumo...
Ainda não li a sua coluna de hoje, estou guardando para uma hora possa saboreá-la toda de uma vez
um grande abraço

Flavio Xandó - 21/02/2005 - 19:33 - Responder no fórum

B.Piropo

Isso mesmo, era a minha, acabo de verificar (ainda tenho o manual e os cartões magnéticos). O modelo era SR-52. Entrava-se o programa "na munheca" e gravava-se em uma porcariazinha de uns cartões magnéticos. Para ler, era uma desgraça, havia que se tentar umas tantas vezes, nem sempre se conseguia. Mas ainda tenho aqui comigo um monte desses cartões com programas, tipo regressão linear e coisas que tais...
Rapaz, eu tinha esquecido completamente dela...
Se eu procurar, acabo achando a máquina... Deve estar jogada pelai...
Mas já lá se vão mais de trinta anos, cara...
{}BP

B.Piropo - Rio de Janeiro - 21/02/2005 - 20:05 - Responder no fórum

Epoc

Eu já programei um dia... foi na época dos CP´s, da Prológica. Eu tinha um CP400 - Color e um TK80x. Fazia joguinhos em Basic (eu tinha 5 anos, hehehe).
Mas hoje, mesmo com as IDE eu não tenho mais saco de programar... desde que comecei a mexer com hardware eu deixei a programação em 10º plano. Meus amigos dizem para eu voltar a programar, e dizem também que eu nunca deveria ter parado... afinal, com 5 anos de idade, programar em Basic não era algo normal. Mas eu nem ligo. Prefiro minhas placas-mãe e outras peças do que a programação.
Mas ano que vem (ou esse, talvez) eu começo a faculdade de Ciências da Computação. Então terei que mexer novamente com programação. Espero que eu consiga ter cabeça para isso dessa vez
Melhor integração Software/Hardware possível... isso é o máximo!
´s

Epoc - São Paulo/SP - 22/02/2005 - 10:02 - Responder no fórum

Mais comentários Acessar o fórum Responder no fórum