Programando com ferramentas livres

Desde 1981, estive envolvido com programação de computadores. Tive oportunidade de desenvolver trabalhos em áreas distintas, desde software básico até aplicações comerciais, e trabalhar com várias linguagens. Porém, nos últimos dois anos, estive afastado da área técnica, trabalhando com outros tipos de coisa. Continuei acompanhando o desenvolvimento de várias tecnologias, apenas por curiosidade. Desde março, estou voltando para a minha área de origem, que é a programação pura (não análise de sistemas, apesar de ser uma necessidade; mas não há mal nenhum em ser um bom programador). Recentemente, comecei a escrever alguns programas comerciais novamente. Decidi optar por ferramentas livres, devido a algumas questões éticas que considero importantes. Ainda estou engatinhando na escolha do meu kit de ferramentas, mas já pude observar alguns fatores interessantes.

Pela sua própria natureza, há setores da área de desenvolvimento de sistemas que são muito bem servidos de ferramentas livres. Por exemplo, há inúmeras linguagens interessantes, com suporte para múltiplas plataformas. Python e Perl são as mais conhecidas e populares da lista. Ruby e Lua são outras opções que tem ganhado bastante espaço (a propósito, Lua é uma linguagem brasileira, desenvolvida na PUC/RJ mas que já é utilizada em projetos no mundo todo). Todas estas linguagens tem em comum o fato de se afastar bastante do modelo de programação ditado por outras linguagens tradicionais como C, C++ e Java. Elas são interpretadas, permitem a prototipação rápida, são dinâmicas e na sua maioria, muito flexíveis no que diz respeito a tipagem dos objetos. Nem por isso estas linguagens tem desempenho ruim. Primeiramente, o tipo de construção que elas permitem favorece a busca da eficiência no design. O programador fica livre de cuidar de detalhes como administração de memória para se concentrar no funcionamento do programa, e por isso, o desempenho é favorecido. Outro fator importante é a qualidade das bibliotecas de suporte, que são altamente otimizadas, e rodam muito mais rápido que o código equivalente de um programador mediano em C, por exemplo.

Escolhida a linguagem, é preciso montar um bom ambiente de desenvolvimento. E é aí que os problemas se tornam mais evidentes. As alternativas comerciais estão fora de questão -- lembre-se, estamos falando de basear o desenvolvimento todo em ferramentas livres. Apesar de haver inúmeras bibliotecas de excelente qualidade para praticamente qualquer coisa (incluindo suporte a banco de dados e arquiteturas Web avançadas) falta uma coisa básica: um IDE bom, eficiente e estável. Há projetos interessantes em andamento. O Eclipse se propõe a ser um framework extensível para IDEs de múltiplas linguagens. E no caso do Python, o Boa Constructor é um projeto que tem muito potencial, apesar de faltar (na minha opinião) uma maior atenção para detalhe.

Acredito que o problema pode ser parcialmente explicado pelo fato de boa parte dos programadores já terem seus próprios ambientes de desenvolvimento. Os que usam Windows possivelmente já tem o IDEs do compilador C; aqueles que usam Linux tem uma quantidade grande de ferramentas de console, muito produtivas para desenvolvimento de bibliotecas, mas que não oferecem o mesmo grau de facilidade para desenvolvimento de aplicações comerciais. Mesmo assim, é um problema curioso. Parece que este tipo de projeto não funciona bem em termos de open source. O mesmo problema ocorre com as ferramentas de escritório. O que estes projetos tem em comum? São projetos grandes, complexos, geralmente com uma arquitetura monolítica. Ao contrário, os melhores projetos de código livre são altamente modulares. Isso pode ser explicado. Devido à sua amplitude, a visão conceitual necessária para um projeto de maior porte exige um grau de dedicação que a maioria dos desenvolvedores de código livre não pode garantir. Projetos modulares são mais fáceis de coordenar e exigem um tempo menor para sua administração.

Acredito que no final, os projetos de código livre conseguem cobrir estas deficiências com o desenvolvimento gradual dos módulos, até chegar ao produto final. Apenas o tempo necessário é mais longo, mas a qualidade não precisa necessariamente ser inferior. Para quem deseja usar as ferramentas no ponto em que estão agora, é preciso ter em mente estas limitações, e estar disposto a trabalhar junto e colaborar para que o ambiente se torne melhor.