Quando o compilador faz a diferença?

Freqüentemente, fazemos a nós mesmo perguntas como estas: “O Visual Studio 2005 é melhor que o Delphi 2005?” “Porque devo escolher o Visual Studio e não a ferramenta X?” Conheça a opinião do autor sobre a escolha do compilador.

por Fabio Camara

Freqüentemente, fazemos a nós mesmo perguntas como estas: "O Visual Studio 2005 é melhor que o Delphi 2005?" "Porque devo escolher o Visual Studio e não a ferramenta X?" Do ponto de vista "não técnico", conhecendo o modo de pensar dos programadores, sabemos que a resposta será fundamentada em: Tendência de mercado, oportunismo de demonstrar especialização e base de conhecimento.

• Tendência de mercado: É impossível deixar passar desapercebido os modismos que cercam nossa área profissional. Acompanhamos desde 1999, como ilustração a afirmativa anterior, um gosto exagerado pelos contratantes de projetos por soluções baseadas em plataforma Web. Em muitos casos, sabemos que a Web não é a melhor escolha, como por exemplo aplicativos de Tele-marketing ou PDV, mas o mercado questiona tudo que não seja Web. Da mesma forma percebemos hoje em dia que qualquer nova implementação, ou é .NET ou é Java. Dificilmente os CIOs posicionam-se contra esta escolha.

• Oportunismo de demonstrar especialização: Há pouco tempo estava palestrando no evento .NET Developers 2.0 em São Paulo e em virtude de uma discussão questionei aos espectadores se existe algo mais rápido para uma solução stand alone que Clipper com Dbase. Logicamente ninguém respondeu negativamente. Em seguida perguntei se alguém tem coragem de construir uma implementação nova com esta tecnologia. Ninguém posicionou-se, também.

  Este é o ponto, em muitos momentos soluções como um simples arquivo .BAT ou Clipper resolveriam de forma satisfatória nossos problemas, mas os líderes de IT freqüentemente escolhem outros caminhos. Na minha leitura é uma questão de orientação: Poucos tem o foco no problema (direcionados a entrega) e muitos tem o foco na solução (direcionados a impressionar com propostas avançadas).

• Base de conhecimento: Quando você vai implantar uma metodologia ou alguma certificação como CMM, seu primeiro desafio é vencer a seguinte lei mental predominante nas pessoas: "Não fazemos os processos da melhor maneira, fazemos da maneira que sabemos fazer bem". O desafio é transformar o que as pessoas fazem bem no que é a melhor maneira de fazer. Esta dinâmica inconsciente orienta todas as conjeturas tecnológicas. Traduzindo, por mais que seja fácil fazer um arquivo .BAT, se isso é novo para você, certamente você optará por fazer na linguagem que você domina.

Do ponto de vista técnico, a resposta campeã na minha leitura seria: "Utilizo esta ferramenta porque ela é bastante produtiva ou sou muito produtivo utilizando esta ferramenta". Tão simples quanto isso, precisamos de alguma outra justificativa? Contudo sabemos que discussões técnicas "calorosas" não ficariam satisfeitas com esta resposta somente. Desta forma vamos estudar um conceito que aprendi nos meus tempos de programador Delphi com os mestres Steve Teixeira e Xavier Pacheco (1), o pentágono de atributos de uma solução para desenvolvimento. Estes são os cinco importantes atributos:

• A qualidade do ambiente de desenvolvimento visual;
• A velocidade do compilador contra a eficiência do código compilado;
• A potência da linguagem de programação contra sua complexidade;
• A flexibilidade e a capacidade de redimensionar a arquitetura de banco de dados;
• O projeto e os padrões de uso impostos pela estrutura.

Nota 1: Steve Teixeira e Xavier Pacheco são premiados escritores que criaram a série "Delphi X - Guia do Desenvolvedor" publicados pela editora Sams. Algumas destas obras foram traduzidas para português e publicadas pela editora Campus.

Embora poderíamos incluir outros fatores envolvidos, como distribuição, documentação e suporte ao desenvolvedor, optamos por um modelo mais homogêneo as ferramentas de mercado existentes.

Figura 1. Demonstração visual do Pentágono.

IDE Visual

Primeiramente vamos dividir o ambiente de desenvolvimento visual em 3 partes: o editor, o depurador e o Form Designer. Acreditando que a maioria das modernas ferramentas RAD (Rapid Application Development) (2) possuem esses 3 componentes funcionando em harmonia enquanto você projeta uma aplicação, vamos entender o que devemos esperar desses componentes.

Nota 2: Se você deseja se aprofundar no assunto RAD, recomendo o sensacional livro com o mesmo título do Steve McConnell. Este livro "RAD" e o outro do mesmo autor com o título "Code Complete" são minhas bíblias de cabeceira da cama.

Paralelamente ao seu trabalho no Form Design, uma ferramenta adequada deve estar gerando código nos bastidores para os componentes que você manipula nos formulários. Você pode até ter a opção de incluir manualmente e deve ter a permissão de incluir dinamicamente, contudo se sua ferramenta não gerar este código automático, você deve rapidamente trocar sua escolha. O editor deve permitir você depurar sua aplicação definindo pontos de interrupção e inspeção no mesmo editor. Os editores modernos possuem mecanismos de preenchimento de código automático a partir de alguns caracteres pré-digitados, no Delphi este mecanismo chama-se "Code Insight" e no Visual Studio chama-se "Intelisense". Estes códigos podem ser comandos, bibliotecas de tipos e classes, e assinaturas de funções e métodos que você mesmo escreveu.

Recursos avançados como depuração remota, anexação de processo, inspeções locais automáticas e janelas de CPU são desejáveis e podem ser encontrados nas ferramentas mais famosas disponíveis. Por último, se é possível finalizar este assunto, a ferramenta deve suportar VFI (Visual Form Inheritance). O VFI lhe permite descender ativamente de qualquer outro formulário em seu projeto ou de modelos pré-existentes.

Compilador e código compilado

Neste quesito temos uma separação de opções nos dias de hoje: Os códigos nativos também conhecidos como 32 bits e os códigos interpretados que necessitam de máquinas virtuais. Podemos agrupar Delphi, Visual Basic e C++ como código nativo e C#, Delphi.NET, Java e Visual Basic.NET como código interpretado.

Um compilador rápido, independente de nativo ou interpretado, permite que você desenvolva softwares de modo incremental e dessa forma possa fazer freqüentes mudanças no seu código fonte, recompilando, testando, alterando, recompilando, testando novamente e assim por diante. Isto lhe proporciona um ciclo de desenvolvimento muito eficiente e é o que predomina na maioria das ferramentas de mercado.

Quando a velocidade do compilador é lenta ou é complexo para compilar, os desenvolvedores acabam adotando estratégias de implementar vários lotes de código e compilar somente no final de todas implementações necessárias. Além de improdutivo, este artifício obviamente é passível a um maior número de problemas com erros de sintaxe e lógica.

Na última pesquisa séria que tomei conhecimento, os códigos nativos eram mais rápidos que os interpretados e o campeão de velocidade foi o Visual C++.

Linguagem e sua complexidade

Potência e complexidade são assuntos extremamente polêmicos, pois ultrapassam razões técnicas e adentram por opiniões pessoais e / ou resultados baseados em problemas específicos. Assembly é o que existe de mais avançado em linguagem poderosa. Não lembro, pelo menos neste momento, o que não seja possível fazer com ela (talvez páginas Web?). Entretanto, escrever qualquer programa simples em Assembly é uma experiência exageradamente desafiadora. Além disso, é quase impossível manter qualquer código Assembly básico em um ambiente com um time de desenvolvimento.

Baseado na minha opinião, apresento a tabela abaixo com uma relação das linguagens que conheço e suas respectivas classificações:

Linguagem	Potência	Complexidade
C++	Alta	Alta
Delphi (Object Pascal)	Alta	Média
Visual Basic	Média	Baixa
Java	Média	Alta
C#	Alta	Média
Visual Basic.NET	Alta	Baixa

Hoje em dia, a linguagem que mais me identifico é o C# apesar de parecer pela tabela que a melhor opção seria o Visual Basic.NET. Como citado anteriormente, estamos no campo da opinião. Conheço poucos "Fábios" que amam C++, muitos "Fábios" que adoram Delphi, outros veneram Java. Cada um de nós tem uma verdade própria para justificar nossa escolha.

Banco de Dados

Também no campo da opinião, antigamente existia um engine de acesso a dados fornecida pela Borland chamada BDE (Borland Database Engine) que era centenas de vezes melhor que o ODBC. O tempo foi passando, e a Microsoft e o mercado em geral evoluiu para um conceito de drivers especialistas de acesso a dados. Hoje considero que não existe nada melhor que o ADO.NET para acesso a dados, principalmente acesso ao SQL Server. Não considero-me capacitado para estender este tema, pois em minha vida profissional praticamente só trabalhei com SQL Server, Interbase e Oracle, e conheci superficialmente o Progress e o Sybase.

Estrutura (o projeto e os padrões)

Eis aí o ponto na minha visão pessoal. Meu amigo Mauro Sant"Anna (3) chamaria de "Silver Bullets". Durante muito tempo o Delphi foi imbatível por causa de sua VCL (Visual Component Library). Se por acaso você precisasse de algum componente que não existisse no Delphi, era só entrar na Internet e escolher entre inúmeras opções de componentes, desde VCL de graça com código fonte até pacotes pagos. É uma orientação forte a produtividade necessária para construir projetos.

Nota 3: Mauro Sant"Anna é um famoso autor de artigos e palestrante que acreditou antecipadamente no .NET e evangelizou-me para trilhar por este caminho. Além de um exemplo de amigo e ser humano, ele possui inúmeras certificações nas maiorias das ferramentas de mercado e é Microsoft Regional Director.

Parece-me que o Anders Hejlsberg (4) quando foi para a Microsoft incorporou este espírito produtivo ao Visual Studio.NET. Hoje encontramos milhares de pacotes de componentes e diversos componentes freeware facilmente pela Internet. Como percebe-se na empolgação de minhas palavras, sou adepto a utilização de, digamos, um "framework" de componentes para simplificar e até reduzir seu código fonte, e maximizar a relação da interface com o usuário. Porém muito cuidado, estes diversos "sabores" de componentes em seus projetos podem mudar de status se utilizados aleatoriamente. Em outras palavras, os facilitadores podem virar "dificultadores".

Nota 4: Anders Hejlsberg é o criador de inúmeros compiladores Pascal, Delphi e é considerado o "pai" da linguagem C# e do .NET Framework. Ultimamente dedicou-se a escrever o livro "The C# Programming Language".

Meu conselho é escolher previamente os componentes que poderão ser utilizados para um projeto e só utilizar estes, com pouquíssimas exceções para permitir outros componentes. Lembre-se também antes de escolher que é importante verificar a "maturidade" do funcionamento do componente (testes pilotos são fortemente recomendados) e na possibilidade de migrar a versão do compilador (por exemplo, inicia-se o projeto com Visual Studio 2003 e no meio do mesmo adota-se como ferramenta o Visual Studio 2005). Pessoalmente só utilizo componentes de mercado adquiridos com fontes. Não que eu deseje alterar os fontes, isso certamente está fora do escopo do projeto, é apenas por segurança para utilizá-los em casos de bugs descobertos tarde demais e migração de compilador, na ausência de posicionamento adequado do fornecedor do mesmo. Conselho final, dê preferência sempre que possível aos componentes nativos do compilador sempre que os conselhos anteriores não estiverem satisfeitos plenamente.

Posição final

Na minha leitura e espero que tenha ficado transparente neste artigo, escolho meus compiladores conforme o pentágono apresentado considerando que a linguagem e a estrutura exercem um "peso" maior sobre os demais itens.

Este artigo foi inspirado numa discussão ocorrida por e-mail na lista CSharpBR, no texto de Steve Teixeira e Xavier Pacheco intitulado "Delphi: o que é e por quê?" e no livro RAD do Steve McConnell.