Relaxed Programming

Não que seja “do meu tempo”, mas sempre que penso em performance lembro-me de histórias sobre os antigos cartões perfurados.

Antes de qualquer coisa, este artigo não é saudosista e nem ecológico, eu apenas tento usar os exemplos do passado para comparar e fazer refletir sobre o modo como desenvolvemos software hoje em dia.
Bem, nos tempos do cartão perfurado havia máquinas grandes, porém com limitações severas de recursos como memória, periféricos e poder de processamento, e que perderiam feio frente a qualquer celular atual. Dentre outros vários recursos indispensáveis hoje em dia, essas máquinas não possuíam teclado. Uma forma de fazer o computador entender o que você queria que ele fizesse era através da programação via cartão (nada a ver com os cartões da programação XP).
Grosso modo, imagine-se escrevendo um programa bit a bit furando um cartão com um palitinho de dentes. Imagine que um cartão comporta apenas uma dezena de linhas de programação, e que na verdade para escrever um programa, você leva umas três semanas furando uns cento e vinte cartões, cuja ordenação obviamente é fundamental. Ao terminar de digitar, você leva os cartões para dar entrada um a um no computador. Se no meio do caminho, por infelicidade, o elástico que prendia os cartões arrebenta, todos os cartões se espalham no chão. Não há mais nada a fazer senão voltar para casa e arrumar tudo de novo.

Por causa de toda essa dificuldade, havia um cuidado muito maior na confecção dos programas, não havia muitas chances para erro, as soluções tinham que ser simples rápidas e econômicas. Acho que era mais ou menos como a palmatória, você sabia o quanto doía se errasse e por isso tinha que fazer certo da primeira vez. Os programas tinham que compilar e funcionar no cérebro antes de serem submetidos às máquinas.

Aposto que você não desenvolve assim. Você escreve qualquer coisa e aperta uma tecla para rodar, se der erro, você corrige e compila novamente, e repete esse ciclo até que o programa rode ou até que os testes sejam satisfeitos. Algumas pessoas ainda se incomodam com mensagens de advertência ou dicas do compilador, tipo “Ei, você esqueceu uma variavelzinha aqui…”. Então, resolvem o assunto dizendo “Não me incomode com isso”, comentando a linha ou desligando as mensagens.
Você também pode achar que o desempenho do seu programa é suficientemente bom se um processamento levar apenas uma piscada de olhos, ou seja, 50ms. Você já parou para pensar em quantas coisas o computador é capaz de fazer hoje em 50ms, e quantas ele era capaz de fazer a dez anos atrás?
As máquinas obedecem à lei de Moore, dobrando a sua capacidade a cada dois anos, e nós provavelmente nos tornamos programadores duas vezes mais relaxados nesse mesmo período.

Outro dia, rodei um aplicativo feito para MS-DOS que desenvolvi já faz um bom tempo. Fora a beleza e outras firulas das modernas aplicações gráficas, o velho sistema era capaz de fazer tudo os que a nova versão fazia só que com um desempenho impressionante. É que o velho sistema havia sido desenvolvido sob a “palmatória” das limitações de outra época, e encontrou abundância de recursos no novo ambiente. Por que não conseguimos desenvolver sistemas mais rápidos hoje em dia se temos máquinas mais rápidas?

Você pode sentir algo parecido observando a evolução das redes, desde as antigas BBS, por onde trafegavam documentos de texto puro a taxas de alguns Kbps, até aos estonteantes 30 Mbps das linhas de Internet atuais. Hoje é quase inconcebível que um sistema possa rodar dentro de uma rede com velocidade tão baixa quanto a das BBS, mas eles existiram. Certamente, havia muita preocupação quanto ao uso da banda, uso de compressores, protocolos simplificados, maior latência e maior autonomia das partes para diminuir o uso da rede. Hoje, transferimos arquivos imensos como imagens, músicas e filmes, instalamos aplicativos, falamos com pessoas e as vemos através da Internet, e ainda reclamamos da lentidão da rede. Imagine só o que as aplicações BBS fariam com tantos recursos.

Certa vez, lendo a descrição de um projeto, encontrei uma frase memorável, que dizia mais ou menos assim: “… não será necessário utilizar índices para as tabelas, pois a performance do sistema é satisfatória”. Pois é, quanto mais recursos temos mais desperdiçamos.
Consultas SQL são bem cômodas, seu propósito é conduzir o usuário a dizer o que quer, e deixar os detalhes da busca por conta do mecanismo do banco que, em tese, é mais eficiente. Freqüentemente nós sabemos como a consulta deveria ser feita e não entendemos por que o banco demora tanto para realizá-la.

De maneira nenhuma estou dizendo que seja ruim utilizar paradigmas de abstração, como SQL, OOP, AOP, Multi camadas, DSL, VMs etc., se isso nos deixar mais produtivos. Mas acho que todos deveriam conhecer um pouco do que se passa nos bastidores, conhecer um pouco de ASM ou outras linguagens mais próximas da máquina como C (não C++) e Pascal, estruturas de dados, protocolos de rede, implementação de bancos de dados etc. de modo a tecer uma visão crítica sobre as tecnologias que nos são apresentadas e a melhor forma de utilizá-las.

Vez por outra somos convidados a nos submeter a ambientes mais restritivos, como programação para pequenos dispositivos, processamento distribuído. Nesse momento é importante conhecermos as limitações, o que podemos e não podemos fazer, e saber aonde estão os nossos relaxamentos.