Controlando complexidade
As engenharias e a ciência da computação (e o hacking) compartilham uma característica muito interessante... todas elas têm como preocupação e necessidade fundamental o controle da complexidade.
Acho que pouca gente já parou pra pensar que por trás de um simplícimo programa de exibir imagens há complexos algorítimos de decodificação do formato da imagem que está sendo exibida, de dimensionamento dessa figura para caber numa janela, de uma adaptação de coloração para exibição em tela e outra para impressão (sabia que a impressora consegue produzir muito menos cores que a tela?).
Nem mesmo o programador desse software se preocupa com esses detalhes, normalmente, porque eles estão esconcidos atrás de funções simples como, por exemplo, gtk_image_new_from_file, e outras. Reduzir uma imagem normalmente se resume à tarefa simples de pedir à biblioteca que me dê dois inteiros com os tamanhos horizontal e vertical atualmente, calcular a partir desses outros dois inteiros que representam o tamanho desejado e dizer à biblioteca "dimensione a imagem img para esse tamanho". Nem mesmo nos preocupamos em saber que algorítimo a função vai usar para reduzir a perda de qualidade da imagem.
E será que eu devia me preocupar com isso, anyway?
As engenharias chamam isso de 'abstração da caixa preta'; você tem uma caixa preta e você sabe que dando determinada entrada você tem determinada saída.
Esse tipo de coisa é necessária para que você consiga fazer coisas cada vez mais complexas, literalmente embalando complexidade em módulos reusáveis facilmente. É interessante ter isso, também, para que você consiga escolher o que te interessa aprender; eu não tenho interesse por aprender os algorítimos de redimensionamento de imagens; para mim basta que eles funcionem de modo que meu ícone se adapte ao tamanho do painel do GNOME que o usuário escolher.
Mas com isso não quero dizer que eu deva ser um completo alienado a tudo que não diz respeito à minha tarefa mais específica. É preciso ter conhecimentos periféricos à sua área principal de interesse até mesmo para que você saiba como aplicar seu conhecimento nas mais diversas situações e conseguir ser genérico e flexível o suficiente para que sua solução seja robusta e não falhe no primeiro cantinho não aparado da forma esperada que você encontrar.
Então onde é que desenhamos a linha do que é necessário saber e do que se pode se dar o luxo de simplesmente confiar na caixa preta? Eu não sei... acho que só a prática do dia-a-dia vai conseguir dizer... por exemplo, alguém que seja administrador de sistemas provavelmente vai começar achando que não precisa saber muito de como funciona a produção e os mecanismos que estão por trás de bibliotecas compartilhadas.
Isso até ter de rodar um binário de terceiros que precisa de uma biblioteca com soversion (aquele número que vem logo depois do .so no nome das bibliotecas) específico. Se ele não for atrás de entender se pode ou não fazer um link simbólico da que está lá e por quê, ele provavelmente vai ter problemas.
Daí ele vai perceber que um administrador provavelmente não precisa saber como funciona o linker dinâmico, ou como usar libtool, mas é muito bom que ele saiba um básico de como funcionam as bibliotecas compartilhadas, o que é a interface binária e como mudanças nela afetam seu sistema.
E assim a gente vai vivendo a vida, escolhendo as caixas-pretas que queremos abrir e ver por dentro de acordo com necessidade ou curiosidade. Pelo menos nossas caixas pretas do mundo do software livre sempre são passíveis de abertura, modificação, redistribuição =D.
© 2005, Gustavo Noronha Silva
Esse é um texto de opinião e pode ser distribuído não-modificado livremente desde que citada a fonte. Modificações são permitidas desde que uma nota anteceda o texto atestando que modificações foram feitas e identificando o autor das modificações, além de citar a fonte da versão original.
