Está rolando uma discussão no .Net Architects sobre o custo das exceções. Eu sempre soube que elas eram muito caras. O Philip Calçado colocava que não lançar exceções por questões de performance é otimização prematura. Bom, fui checar.

Fiz um código em que criava uma entidade inválida. Em um, a entidade era criada inválida e um valor de status de invalidação era configurado. No outro a entidade não foi criada, e uma exceção foi lançada no construtor.

Vejam as entidades:

class ComExcecao
{
    public ComExcecao(bool algumParam)
    {
        throw new Exception("erro");
    }
}

class SemExcecao
{
    public SemExcecao(bool algumParam)
    {
        EhValida = false;
    }
    public bool EhValida { get; set; }
}

Aqui está o código para testar isso:

static void Main(string[] args)
{
    var quantidadeDeVezes = 100000;
    Console.WriteLine("Quantas vezes você quer rodar? Padrão == {0}", quantidadeDeVezes);
    var vezesInputada = Console.ReadLine();
    
    EngolirErro(()=>quantidadeDeVezes = Convert.ToInt32(vezesInputada));

    Console.WriteLine("Rodando {0} iterações...", quantidadeDeVezes);

    var totalSemExcecao =
        Executar(() =>
                     {
                         for (int i = 0; i < quantidadeDeVezes; i++)
                         {
                             bool EhValida;
                             var classe = new SemExcecao(true);
                             EhValida = classe.EhValida;
                         }
                     });
    Console.WriteLine("Total sem exceção: {0} milisegundos", totalSemExcecao);

    var totalComExcecao =
        Executar(() =>
                     {
                         for (int i = 0; i < quantidadeDeVezes; i++)
                         {
                             bool EhValida;
                             try
                             {
                                 new ComExcecao(true);
                                 EhValida = true;
                             }
                             catch (Exception)
                             {
                                 EhValida = false;
                             }
                         }
                     });
    Console.WriteLine("Total com exceção: {0} milisegundos", totalComExcecao);

    var diferenca = Math.Abs(totalComExcecao - totalSemExcecao);
    var maisRapido = totalComExcecao > totalSemExcecao ? "sem exceção" : "com exceção";
    var percentualMaisRapido = ObterPercentualMaior(totalComExcecao, totalSemExcecao);
    
    Console.WriteLine("Código {0} é mais rápido em {1} milisegundos ({2}).", 
        maisRapido, 
        diferenca,
        percentualMaisRapido);

    Console.ReadLine();

}

Estou ocultando as funções de auxílio para não poluir (no final eu mostro).

Resultados (código compilado como release, cliquem nas figuras para ampliar):

• Dez milhões de iterações
  Total sem exceção: 112 milisegundos (um décimo de um segundo)
  Total com exceção: 256.310 milisegundos (256 segundos, ou quase 5 minutos)
  Código sem exceção é mais rápido em 256.198 milisegundos (2288.48%).
   
  
• Um milhão de iterações:
  Total sem exceção: 9 milisegundos
  Total com exceção: 25.286 milisegundos
  Código sem exceção é mais rápido em 25.277 milisegundos (2809.56%).
  
  
• Cem mil iterações:
  Total sem exceção: 2 milisegundos
  Total com exceção: 2.497 milisegundos
  Código sem exceção é mais rápido em 2.495 milisegundos (1248.50%).
  
  
• Dez mil iterações:
  Total sem exceção: 0 milisegundos
  Total com exceção: 252 milisegundos
  Código sem exceção é mais rápido em 252 milisegundos (Menor valor == 0).
   
  

Minha avaliação dos resultados é que não dá mesmo pra colocar exceções onde código de negócio devia estar ocorrendo. Como eu já havia dito aqui antes, exceções são coisas que não são esperadas (daí o nome “exceção”), como erros, quedas de conexão, etc. Se a magnitude da diferença fosse de 200% até conseguiria entender isso como otimização prematura. Mas uma diferença de quase 3 mil porcento significa que em vez de um servidor, vou ter que colocar 30 pra fazer a mesma coisa. Não faz o menor sentido em praticamente nenhum cenário.

Mais algumas fontes:

1. Exceptions and Performance e Exceptions and Performance Redux
2. The True Cost of .NET Exceptions e The True Cost of .NET Exceptions -- Solution

Pra quem ficou curioso, segue o código que faz a avaliação do tempo, ele usa uma classezinha pouco utilizada do Framework, a System.Diagnostics.StopWatch:

public static double Executar(Action acao)
{
    var stopwatch = new Stopwatch();
    stopwatch.Start();
    acao();
    stopwatch.Stop();
    return stopwatch.ElapsedMilliseconds;            
}

O código, para quem quiser refazer os testes, está aqui.

No post anterior eu comentei sobre o lançamento do tão esperado Silverlight 3, disse que achava que talvez estejamos indo longe demais com HTML + Javascript + CSS, e disse também que o HTML 5 já nascia morto. Algumas pessoas comentaram essa minha afirmação, o que me leva a escrever este post, já que diversas outras pessoas devem concordar com as que comentaram, mas não se deram ao trabalho de comentar. Esse post então é para trazermos a discussão para o local certo, e para que eu possa expor minhas idéias além de duas curtas frases.

Quando eu digo que o HTML 5 já nasce morto, não quero dizer que ele não vai ser usado. Eu acho muito difícil que, até o lançamento do HTML 5, o mundo pare de usar HTML e passe a usar qualquer outra coisa como base para suas aplicações web. O HTML 5 sucede o 4, e vai ser usado assim que for lançado. Isso, no entanto, não significa que as aplicações realmente ricas serão feitas com ele. E nesse sentido, sim, o HTML 5 nasce morto.

Para começar o HTML 5 vai estar pronto daqui a 13 anos (em 2022), segundo o seu próprio editor (confiram o calendário proposto pelo Ian Hickson). A primeira especificação em rascunho será liberada somente em 3 anos, em 2012, a segunda em 2015 (depois de 3 anos!), e a terceira em 2019 (daqui dez anos). Eu sei o que pretendo fazer nos próximos dois anos. Para daqui 5 anos, eu tenho planos. Não sei vocês, mas não tenho a menor idéia do que vou estar fazendo daqui a dez anos. Muita coisa pode mudar. Vai ver alguém aparece e inventa aquele monitor do filme "O pagamento" (Paycheck), que na verdade nem é um monitor, é só uma imagem em 3D flutuando sobre um pequeno aparelho (quem não viu o filme, recomendo). Na realidade, já inventaram tecnologias que deixam o HTML 5 obsoleto. Elas se chamam Silverlight, Flex, e JavaFx. E sabem quando é o lançamento destas tecnologias? Ontem, uns meses, uns anos atrás. Não é para daqui 13 anos, é para ontem.

Alguns dirão que o HTML 5 já é suportado para alguns navegadores. O Firefox 3.5, por exemplo, já suporta algumas coisinhas. A Microsoft, por outro lado, provavelmente não vai suportar absolutamente nada até que a especificação esteja concluída (com razão). Lembrando que ela detém por volta de 70% do mercado de navegadores, isso coloca o HTML 5 com lançamento oficial só em 2022 mesmo, quando o IE passar a suportá-lo. Ainda que o FF suporte, nenhum grande site vai usar as novidades do HTML 5 se ela é suportada somente em um navegador (ou grupo de navegadores) que detém menos de 20% do mercado. E mesmo que fosse o contrário, e somente o IE suportasse, ainda assim os grandes sites não iriam aderir, porque ninguém pode cortar 30% da sua audiência só porque o pessoal do HTML 5 só quer lançar uma pré-versão a cada 3 anos mais ou menos pelos próximos 13 anos. E, vamos lá… vamos dizer que todos os navegadores suportassem, o que aconteceria? Teríamos o inferno da incompatibilidade novamente, já que cada navegador implementaria as lacunas da especificação do seu jeito, já que a especificação estaria incompleta. Estaríamos de volta ao problema da verificação do navegador.

Não bastasse o fato do HTML 5 chegar tarde no jogo, ele chega apresentando novidades que sequer chegam aos pés das propostas pelas tecnologias RIAs de verdade. Como vocês podem ver na página do HTML 5 na Wikipedia, as "novidades" do HTML 5 são novos elementos, mais semânticos que os anteriores, como "section" e "footer", novos controles de formulários, alguns novos atributos, atributos globais, tratamento de erro, e algumas novas APIs. Essas APIs seriam a grande novidade, já que trazem coisas como controle de tempo de playback, drag and drop, um banco de dados local, entre outros. A mais famosa entre estas, e a mais falada é o canvas, um elemento que permite desenhar bitmaps com scripts. Isso, foi isso mesmo que você leu. Bitmaps. Desenhados com scripts. É, eu também tive vontade de me matar quando eu li isso (na verdade matar os caras que estão especificando este absurdo). Enquanto o mundo inteiro caminha para o desenho vetorial, o HTML 5 caminha para o lado oposto, o bitmap. Em 2022 eles vão estar em 1980. Excepcional! E desenhando de forma imperativa, com Javascript, e não declarativa (com XML, por exemplo, como faz o Silverlight), o que deixa o negócio todo ainda pior. Eu não sei vocês, mas não vou pedir para nenhum designer desenhar com Javascript (pode ser perigoso). (Em tempo: vi algumas referências – não oficiais – que podem indicar suporte a desenho vetorial no HTML 5, mas nada conclusivo, indicando que o HTML 5 seria capaz de manipular vetores, e não só exibí-los. Se alguém souber de algo me corrija.) Algumas coisas que são extremamente simples de serem feitas também parecem bem complicadas no HTML 5. Mas tenho certeza que nos próximos 13 anos (!?!?!) eles vão arrumar isso. Só que daí as tecnologias também vão ter evoluído 13 anos, e o nível exigido vai ser muito maior do que o que eles especificaram em 2012, quando fecharam o primeiro rascunho (10 anos antes da versão final): vai nascer obsoleto.

Tem ainda o problema de quem está tocando esse negócio todo. Tem gente do Google, gente da Apple, gente da Nokia… ou seja, gente demais. E eles não parecem concordar em muita coisa, como vocês podem ver pela recente briga a respeito dos codecs de video que está acontecendo. Cada um quer empurrar o codec que acha mais bonito, e na prática não há codec escolhido. O HTML 5 vai sair sem codec? Vai ver eles vão empurrar o lançamento um ou dois aninhos pra frente, para, sei lá, 2025, até resolverem isso. Afinal, que diferença faz, 2022 ou 2025, não é verdade? Irrelevância por irrelevância, está tudo na mesma.

Gostaria que ficasse claro então o que estou dizendo: o HTML 5 chega tarde demais no jogo, quando ele vai estar totalmente mudado, e sem trazer grandes melhorias. Não vai se estabelecer nunca como uma plataforma RIA. Vai continuar sendo suporte para outras tecnologias, como o Silverlight e o Flex (se esse sobreviver até lá), e vai trazer algumas novidades, que talvez nós nem venhamos a utilizar, porque a web vai ter mudado demais. É viver para ver.

Nesta segunda-feira mostrei que o mapeamento objeto relacional de uma aplicação inteira pode ser feito em 60 linhas de código e deixei no ar a pergunta que dá nome a este post:

- O DBA morreu?

Vou respondê-la agora:

- Não. Não morreu. Nem vai morrer. Aliás, é o contrário.

Porque não? Porque ele não morreu se agora o banco virou um mero repositório de dados? Respondo: não morreu porque o banco não é um mero repositório de dados. Apesar de hoje termos ORMs capazes de fazer todo o mapeamento automaticamente (ou mesmo que tenhamos que fazê-lo manualmente para depois o ORM gerar um banco de dados) isso só significa que temos produtividade neste contato com o banco. É o DBA, o especialista em banco de dados, quem vai ajudar a preparar o banco para uma aplicação, o que vai muito além de gerar algumas tabelas.

O que isso significa? Devemos então ignorar o automapeamento? Ou o mapeamento fluente? Temos que abandonar os ORMs?

Não, claro que não. Na maioria da aplicações (na minha experiência – e isso varia), em torno de 50% das suas operações de entrada e saída de dados são simples CRUDs, sem muita complexidade. É comum também que estas mesmas operações sejam pouco usadas pelos usuários, já que as telas que trazem valor para o negócio não são simples CRUDs, ou o sistema sequer seria necessário. É nestas telas complexas que nosso esforço deve se concentrar. E é nas telas de CRUD simples que o automapeamento e os ORMs realmente ajudam. No resto podemos usar um mapeamento manual, ou até eliminar o ORM por completo. Se precisamos de performance, se temos que espremer cada milisegundo, por exemplo, talvez um ORM não seja a solução ideal. Nesse cenário podemos isolar as partes da aplicação que tem essas características, e não usar um ORM. No resto, usamos um ORM com mapeamento automático. Ganhamos tempo e dinheiro para quem está pagando pela aplicação.

Além disso, um DBA sempre é importante no final das iterações do projeto, já que é lá que você vai precisar testar e otimizar a performance da aplicação, além de verificar sua adequação aos diversos padrões do projeto. Então, no final da iteração, você examina o modelo gerado pelo seu ORM junto do DBA e confirma se ele quer mudar alguma coisa, acrescentar índices, mudar colunas, tabelas, etc. Depois de pegar esse feedback o banco é refatorado, junto com o mapeamento, tudo é revisado, e a iteração segue para sua conclusão. O DBA atua confirmando se os desenvolvedores, que em geral não especialistas em banco de dados, não estão cometendo nenhum absurdo. É bom que ele faça isso, já que é ele quem vai conviver com o banco de dados depois.

Depois que paramos para pensar, parece óbvio, não é? No mundo de hoje precisamos de pessoas cada vez mais especializadas. Precisamos de especialistas em algorítmos, de conhecedores de paradigmas de linguagens diferentes, de arquitetos, entre outros tipos de especialistas, e os especialistas de banco de dados claramente não poderiam ficar de fora. E eles vão ficar mais importantes ainda, conforme as tecnologias de armazenagem evoluem. O que pode acontecer é que talvez precisemos de menos DBAs para sustentar as aplicações (algo que tem acontecido), mas eu não arriscaria minha vida nisso.

O Lula, como todos sabem, esteve na última edição da Fisl, que aconteceu semana passada. E como sempre, discursou de improviso. O discurso está no site do planalto a disposição de quem quiser ouvi-lo.

Por volta dos 3 minutos e quinze segundos, ele solta esta pérola:

"Agora que o prato está feito, é muito fácil a gente comer. Mas fazer esse prato não foi brincadeira. Eu lembro da primeira reunião que nós tivemos na Granja do torto, porque eu não entendia absolutamente nada da linguagem que esse pessoal discutia, e houve uma tensão imensa entre aqueles que defendiam a adoção no Brasil do Software Livre e aqueles que achavam que nós deveríamos fazer a mesmice de sempre, de ficar no mesmo jeito, comprando e pagando a inteligência dos outros. E graças a Deus permaneceu no nosso país a questão e a decisão do software livre. (urros de alegria na platéia)

Porque nós tínhamos que escolher, ou nós íamos pra cozinha preparar o prato que nós queríamos comer, com esse tempero que nós queríamos colocar e dar um gosto brasileiro na comida, ou nós iríamos comer aquilo que a Microsoft queria vender pra gente. E prevaleceu simplesmente a idéia da liberdade."

Antes de continuar, temos que lembrar que o Lula não é bobo. Ele agracia a platéia com que fala. Se forem economistas fala de um jeito, se for o MST fala o oposto. Sempre fez isso, e não é agora que ia mudar. Além disso, já disse muita besteira de improviso. Essa não é a primeira vez que o freio não segura sua língua.

Diante disso, e apesar disso, acho inadmissível o presidente de um país se colocar de tal forma. Ele foi populista (como sempre), e, em vez de entrar no bom debate, preferiu descer para o nível mais baixo para agradar a horda que o ouvia.

Eu gostaria de saber qual era o "prato" que a Microsoft queria vender ao Lula. Porque eu vendo muitos pratos da Microsoft, e meus clientes estão todos muito satisfeitos. Não entendo porque o governo deve desconsiderar, nas palavras do presidente, qualquer "prato" que seja, simplesmente por questões ideológicas. E vejam bem, são ideológicas, e não morais. Não estamos discutindo aborto, eutanásia ou pena de morte, e sim qual a plataforma mais efetiva para a implantação de um sistema. Isso não se resume a uma receita de comida, como o presidente tentou reduzir o assunto. O debate é técnico e econômico, e não filosófico ou moral.

No começo ele menciona a mesmice de sempre, onde se compra propriedade intelectual. Oras, o próprio governo faz isso o tempo todo. Os remédios que o governo compra também são protegidos por propriedade intelectual, mas as poucas vezes em que investimos na quebra deste tipo de propriedade fomos duramente criticados. O modelo de desenvolvimento de remédios, muito parecido com o de software, precisa de investimentos. É o pagamento por um remédio que financia o desenvolvimento do próximo. Da mesma forma, é o pagamento por um software que financia o desenvolvimento do próximo.

Já senti vergonha deste governo atual muitas vezes. Quando dá guarida a um terrorista italiano, quando não critica a pseudo-democracia venezuelana, quando quase apóia as FARC, quando entrega pedaços da Petrobrás de graça para a Bolívia, quando apóia o regime iraniano, quando manda embaixadores para a Coréia do Norte… Na política nacional a última foi dizer que o Sarney não devia ser tratado como uma pessoa comum, jogando o artigo 5º da constituição no lixo. Não bastava ter criado o mensalão.
E agora mais um episódio.

Lamentável.

O Rob Conery, da Microsoft, e que tem atuado no ASP.Net MVC e advogado seu uso desde sempre, lançou essa, agora a pouco:

"WebForms is a lie. It’s abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand. Nothing you do with Webforms has anything to do with the web – you let it do the work for you.
(…) You’re working in a lie. The web is *not* stateful and works with this stuff called HTML sent across wires using another thing called HTTP (…)"

E segue explicando porque você deve usar ASP.Net MVC. (E queimar seus livros de WebForms – não brincadeira, ele não disse isso.)

O mais interessante é dizer que o Webforms é uma mentira, e fechar dizendo que quem trabalha com WF trabalha com uma mentira. Obviamente eu não concordo, mas que vai dar o que falar vai. Afinal, o cara trabalha na Microsoft… quero só ver.

O .Net Architects já debateu muito sobre ASP.Net MVC e Webforms, prós, contras, etc. Eu também já postei, uns 6 meses atrás, quando você deve usar WF ou MVC. Todo mundo já falou alguma coisa sobre isso. Mas parece que o assunto continua quente…

Se você se preocupa em desacoplar suas classes e camadas, com certeza já precisou descobrir uma maneira de passar um objeto construído, que vou chamar de objeto de serviço (OS), a um outro objeto que vai utilizá-lo, que vou chamar de objeto de aplicação (OA). Da mesma forma, se preocupou em gerar interfaces ou classes abstratas para o OS, gerando uma interface de serviço (IS) para permitir a inversão de controle, e facilitar tarefas como testes, além de facilitar o polimorfismo.

Essas preocupações trazem necessariamente a questão: como então passar um OS construído a um OA que depende de uma IS?

Falando em exemplos concretos. Você tem um controller de produtos (do ASP.Net MVC) que depende um repositório de produtos e de um repositório de categorias para obter e alterar os seus dados. Depende ainda de uma classe que faz o tratamento de erros. Como tratar as dependências do controlador com essas classes? Vejam o diagrama abaixo:

Poderia fazer assim, com alto acoplamento, ainda que eu tivesse as interfaces (código do controlador, nosso OA):

        public ActionResult Index()
        {
            try
            {
                IProductRepository productRepository = new Models.ProductRepository();
                ViewData["products"] = productRepository.GetProducts();
                ICategoryRepository categoryRepository = new Models.CategoryRepository();
                ViewData["categories"] = categoryRepository.GetCategories();
                return View();
            }
            catch (Exception ex)
            {
                IExceptionManager exceptionManager = new Models.ExceptionManager();
                exceptionManager.HandleError(ex);
                return View("Error");
            }
        }

Qual o problema deste código? Ainda que eu utilize ISs, é o OA que está criando os OSs, ele os conhece fortemente. O controlador conhece o repositório concreto de produtos, o repositório concreto de categorias, e o tratador de erros concreto, além de suas interfaces. Com isso estou com acoplamento alto, além de coesão baixa, já que o método Index quebra o princípio da responsabilidade única (SRP) porque tem mais de um motivo para mudar (sabe obter produtos e categorias e sabe criar repositórios – nem vou entrar no mérito de saber tratar erro, apesar de ele existir).

Há duas opções que quero discutir: crio um service locator (SL), ou trabalho com injeção de dependência (Dependency Injection – DI).

Com SL fica assim:

        public ActionResult Index()
        {
            try
            {
                var registry = new Registry();
                IProductRepository productRepository = registry.Resolve<IProductRepository>();
                ViewData["products"] = productRepository.GetProducts();
                ICategoryRepository categoryRepository = registry.Resolve<ICategoryRepository>();
                ViewData["categories"] = categoryRepository.GetCategories();
                return View();
            }
            catch (Exception ex)
            {
                IExceptionManager exceptionManager = registry.Resolve<IExceptionManager>();
                exceptionManager.HandleError(ex);
                return View("Error");
            }
        }

O que mudou? Bom, o objeto Registry (que é aplicação do padrão Registry com alguns anabolizantes) é responsável por resolver as dependências. É ele quem faz o trabalho de obter uma instância dos meus objetos e me devolvê-la. Como ele faz isso é você quem decide, mas provavelmente um contêiner de DI, como o Unity, ou o Windsor, mas pode até ser hardcoded, no punho.

Nesse modelo, meu controlador está acoplado apenas ao meu registry, e às interfaces de serviço. Posso substituir tudo por mocks e testar com facilidade. É só substituir o registry com alguma herança, algo bem simples de fazer, e acabou. Este código teria que evoluir um pouco, porque da maneira com que está não é testável porque o controlador cria o registry. Um acesso via uma propriedade estática resolveria o problema.

A outra opção, trabalhando com DI:

    public class ProductsController : Controller
    {
        private IProductRepository _productRepository;
        private readonly ICategoryRepository _categoryRepository;
        private readonly IExceptionManager _exceptionManager;

        //construtor
        public ProductsController(
            IProductRepository productRepository, 
            ICategoryRepository categoryRepository, 
            IExceptionManager exceptionManager)
        {
            _productRepository = productRepository;
            _categoryRepository = categoryRepository;
            _exceptionManager = exceptionManager;
        }

        //Dependency injection
        public ActionResult Index()
        {
            try
            {
                ViewData["products"] = _productRepository.GetProducts();
                ViewData["categories"] = _categoryRepository.GetCategories();
                return View();
            }
            catch (Exception ex)
            {
                _exceptionManager.HandleError(ex);
                return View("Error");
            }
        }
    }

Nesse caso, as dependências (os três OS) são passados via construtor para a classe de controlador. Ela não sabe como criá-los. Isso fica melhor alinhado com o SRP e torna o OA efetivamente um cliente das ISs, sem ter o menor conhecimento dos OA concretos.

Esse é o modelo que eu prefiro. Trabalho com DI na maioria dos casos, usando SL só onde não é possível. É bem mais fácil de testar, porque não preciso mockar o registry, e com um bom contêiner de injeção de dependência, como o Unity, fica ridículo de trabalhar as dependências, que, depois de pouco código, se resolvem sozinhas. (Nota mental: postar um exemplo de autoresolução de dependência com Unity. Nota para vocês, leitores: se eu não postar me cobrem!)

Esse cenário é plenamente suportado no ASP.Net MVC, que trabalha com uma Factory para controladores (depois eu mostro isso aqui também, mas tem um exemplo no código da palestra de MVC em N camadas se quiserem ver). Já no ASP.Net Webforms isso não existe, quando um WF é criado pela infraestrutura do ASP.Net ele já foi criado e nenhuma dependência foi injetada. Isso significa que você está preso ao SL, mas isso não chega a ser um problema. Aplicações Windows Forms são triviais também no uso de DI, porque controlamos o lifeline dos objetos do começo ao fim.

Por fim, quero deixar aqui uma recomendação minha: nunca exponha o conteiner de injeção de dependência, como o UnityContainer, diretamente, como se ele fosse o SL. Abstraia-o, porque você pode precisar trocar a tecnologia, além de ter dificuldades nos testes. Uma classe Registry com um método "Resolve" é geralmente suficiente e resolve o problema.

Sugiro também a leitura das considerações do Martin Fowler, que fala no site dele que prefere SL com Registries, mas em seu livro PoEAA, ele diz que só usa Registries em última opção.

E você, o que usa para desacoplar suas classes? Como resolve o problema de testabilidade e substituição de dependências? Prefere DI ou SL?

Mais um post da série de polêmicas, que andava meio parada, ainda mais depois da acalorada discussão sobre software livre X software proprietário que teve aqui.

Esse é um assunto que está guardado para eu falar faz tempo, e que não tem dado tempo. É uma discussão semi-religiosa… Tem gente que adora Website, tem gente que odeia. A mesma coisa com web application. Eu? Eu não gosto de Websites, acho-os menos profissionais, confusos, e vou mostrar porque.

Para quem quiser, a Microsoft faz uma comparação entre os dois tipos de projeto no seu artigo sobre introdução a projetos de web application.

Ao que tudo indica, minha opinião segue o que a Microsoft está fazendo, já que os projetos de website estão sendo escondidos e morrendo devagar. Vejam por exemplo, a página inicial do Visual Studio 2005:

Agora vejam a do Visual Studio 2008:

E a do Visual Studio 2010:

Notaram que não há mais Create Web Site já a partir do Visual Studio 2008? Você tem que ir no File > New > Website para criar um website. Ao clicar no ícone de "New Project" do Visual Studio 2010 uma janela de criação de projetos aparece, não a de websites. Para criar websites o procedimento é o mesmo do Visual Studio 2008: File > New > Website.

Isso significa que o template de Website morreu? Claro que não, afinal muito código foi escrito com ele, mas sem dúvida ele está em segundo plano, virou o patinho feio. O ASP.Net MVC, por exemplo, nem possui o template de website, só o de web application. E como ele está em beta, isso significa que está feature complete, e não deve ter mesmo.

E porque eu gosto mais de web application? Primeiro porque o resultado é uma DLL. Eu faço o trabalho e ele vira um executável. Nada de "sob demanda". Para atualizar é só subir um arquivo, e ele tem sempre o mesmo nome. Já se você usa website, cada hora que você publica são geradas várias DLLs, e elas têm nomes diferentes.

A idéia de criar uma dll por diretório, que é o que acontece no website também é muito ruim. Você pode acabar tendo problemas de referência circular em um mesmo website, só porque dois diretórios se referenciam, e, com isso, as DLLs não podem ser geradas. É um problema simples de resolver, mas é chato e desnecessário.

Adicionar referências em websites também é complicado. Websites usam o web.config para manter a lista de referência, mas se você coloca uma DLL no diretório bin ela vira uma referência automaticamente. Isso é meio irritante também. Eu gosto da minha pastinha virtual de "References".

Também não gosto da idéia de que qualquer arquivo que está no diretório faz parte do website. Isso é muito incômodo, principalmente se você trabalha com controle de versão. Aliás, controle de versão com website dá trabalho. Com web application não dá, é um projeto como qualquer outro.

E aquele diretório App_Code? É o fim! Não gosto de ter que colocar minhas classes em um lugar específico.

E vocês sabiam que não dá para adicionar build steps antes ou depois da compilação de um website? Sabem porque? Porque não tem um arquivo vbproj ou csproj, e é lá que esse tipo de coisa fica. Aliás, configurar tudo via web.config é também uma dor de cabeça desnecessária. A falta da aba de propriedades de projeto é muito grande.

Migração de aplicações ASP.Net 1.x para website também são infernais. Para web application é tão simples quanto alguns cliques.

Há uma vantagem no website: uma só. É a capacidade de alterar o code behind e ele imediatamente refletir na aplicação, sem precisar recompilar. Basta salvar o arquivo cs ou vb e acabou. Mas sinceramente, ela não vale a dor de cabeça do resto.

Enfim, estes são meus motivos. Quando chego para uma consultoria e vejo um website eu já sei que a chance de ter problemas é bem maior. Não gosto nem de editar artigos da .Net Magazine com websites. E vocês, compartilham da minha opinião, ou gostam de websites? Se gostam, porque?

<aviso>SE VOCÊ NÃO CONSEGUE LIDAR COM O ASSUNTO, É MELHOR NÃO LER. RESPEITE A EDUCAÇÃO QUE SUA FAMILIA LHE DEU. O OBJETIVO DO POST NÃO É OFENDER, É DISCUTIR.</aviso>

Continuando a série "polêmicas" quero falar de um tema espinhudo: software livre vs. software proprietário, ou ainda: patentes sobre software ajudam ou atrapalham?

Nesse assunto eu tenho uma posição muito clara, e vocês já a conhecem, certo?

Tive uma acalorada discussão sobre este assunto com um dos palestrantes do evento de lançamento do InfoQ, do qual também participei palestrando. Apesar de acalorada, a discussão foi de altíssimo nível, com uma pessoa muito inteligente. Gosto muito de discutir com pessoas inteligentes, de preferência mais do que eu, porque geralmente me trazem um ponto de vista diferente sobre algo que penso.

Enfim, já havíamos falado de política, economia, e descambou para o assunto patentes de software e software livre. Quando citei patentes meu interlocutor já disparou que patentes de software eram coisas sem sentido.

Será?

Ao dizer que as patentes podiam ser de remédios, ou máquinas, fica tudo certo; a maioria aceita patentes desse tipo de produto. Porque não de software, então? Oras, remédios tem o mesmo modelo de negócios que software: investimento em P&D a custos altos, para posterior revenda a custos baixos (e muitas vezes preços altos) que financiará o investimento em novos remédios. O comprimido em si geralmente é barato: caro é desenvolver o comprimido. Sem o pagamento pelo comprimido não há como financiar o próximo medicamento.

Com software não é a mesma coisa? O desenvolvimento é caro, a mídia de distribuição, seja ela um CD ou DVD, ou a web, são baratas. Mas os softwares não são baratos. Qualquer programinha por aí custa pelo menos uns vinte dólares. Um Windows, um Photoshop, um Autocad custam bem mais que isso. Obviamente não estamos pagando pelo DVD ou pela banda que estamos utilizando quando baixamos o software. Pagamos pelo desenvolvimento e pela pesquisa, assim como quando compramos um remédio.

E porque é tão errada então a patente de software, se é ela mesma quem financia a inovação?

Muitos dirão que se não houvesse patente a cooperação poderia ser maior, ou vão ainda levantar a questão da liberdade. Abordando um a um:

Aos primeiros digo o seguinte: o mesmo vale para qualquer indústria. Um banco não "compartilha" suas estratégias financeiras. Uma montadora não "compartilha" o design de seus carros ou de seus motores. Um laboratório não "compartilha" as fórmulas de seus remédios. Um músico não "compartilha" sua música. Uma escuderia não "compartilha" os projetos de seus carros, ou os ajustes aerodinâmicos que produziu. E os que o fazem cobram caro por isso, licenciando seu trabalho, para que possam continuar vivos e trabalhando amanhã. A música, especificamente, está buscando novas formas de licenciar esse conteúdo, onde experiências onde você licencia música de maneira ilimitada por um período de tempo estão começando a aparecer (você aluga todas as músicas por um ano, por exemplo). Mas em geral ninguém entrega conhecimento de graça. Seja por cooperação ou por qualquer outro motivo.

Como então entregar software de graça? Os que vejo trabalhando em software 100% gratuito sempre tem uma motivação externa. Raramente é algo totalmente altruista, e mesmo que existam os 100% altruistas alguém os está bancando. Ou a família, ou uma herança, ou um bando de seguidores idealistas, ou sei lá. E isso é uma situação que não atinge as massas, é pontual. O resto de nós tem que pagar as contas no fim do mês, o que permite, no máximo, uma atuação pequena de vez em quando, e não é disso que os grandes projetos de OSS são feitos. E como vamos fazer isso se o software que construimos não pode ser vendido?

As motivações externas variam. Alguns simplesmente querem destruir todo o software proprietário porque querem e acabou. Até o Linus Torvalds, por exemplo, critica o Stallman, com relação a alguns de seus comportamentos xiitas. E o argumento de Stallman, baseado na liberdade, desconsidera totalmente a natureza humana e suas motivações, algo que qualquer bom psicólogo, antropólogo, ou economista pode explicar, porque ignora a meritocracia e a busca de uma situação melhor. Mais sobre isso em instantes.

Se todo o software fosse gratuito e livre, as empresas também não teriam mais diferencial competitivo com TI. Não teriam sequer motivo para investir, senão coletivamente, já que todo desenvolvimento seria de todos, então esperariam o concorrente fazer e utilizariam o dele. Na verdade, neste modelo, empresas farmaceuticas cessariam de existir por completo, recaindo então sobre o governo a responsabilidade de fazer a pesquisa e a produção. E todos sabemos como governos são bons empresários e prestadores de serviço, certo? (atenção para a ironia)

Grandes empresas, como Oracle, Microsoft, SUN, Apple, também deixariam de existir. Quem iria substitui-las? Sinceramente, eu uso alguns produtos open source, mas nenhum que me entregue tanto valor quanto essas empresas entregam. E não é com o caso de Firefox que vão me convencer que o OSS é uma boa. Muito menos com o Linux. Pelo menos não até minha mãe conseguir usar. Enquanto minha mãe não for capaz de usar o Linux sem precisar que eu fique instalando tudo pra ela, compilando coisas, etc, o Linux é um caso de fracasso no ambiente doméstico. E olha que minha mãe é esperta pra caramba, usa Messenger, Orkut, baixa jogos, Outlook, Torrent, Skype, etc, etc.

Falando agora da questão da liberdade. Os que levantam esta questão geralmente o fazem sob o argumento de que devem ser capazes de acessar seu hardware como bem preferirem. Ok, é um argumento com sentido. Mas na boa, quem liga? Eu não quero saber como funciona a injeção eletrônica do meu carro, não quero saber o que há no motor da minha geladeira, e muito menos o que acontece dentro do meu relógio. Da mesma forma, as pessoas não querem saber o que acontece dentro dessa caixa estranha que é o computador. Para elas tudo é meio mágico, elas interfaceiam com o teclado, o mouse, o monitor e as caixas de som. Isso é o computador para elas. Elas não ligam para o que acontece por trás das cortinas. Mesmo quem trabalha com isso precisa no máximo de APIs, e isso todos os sistemas proprietários decentes trazem, para que você possa interfacear com eles. Pronto, problema resolvido, você pode acessar seu software como precisar. E se o software não atende, troque, use outro. Você sempre tem a liberdade de trocar. Está aí o poder dos mercados.

O que eu acho que me incomoda mais nessa agenda toda é a questão da meritocracia, e do desejo humano, tão absurdamente ignorados nesse tipo de defesa. Eu, liberal até o último fio de cabelo, sinto até arrepio deste ar comunista dado ao software livre, até porque a democracia sempre foi liberal, como diz Reinaldo Azevedo, e as tentativas de trazer liberdade e igualdade à força sempre deram errado. Está aí Cuba, último e cambaleante vermelho em pé, e os falidos regimes comunistas russos e chineses para contar as histórias de atrocidades e extermínio em massa e da total falta de sucesso em "forçar a liberdade". Foi só dar ao espírito humano espaço para competir, e os melhores produtos e invenções do mundo começaram a aparecer. Isso aconteceu com carros (se você não concorda, vende seu carro americano, japonês ou francês, e compre um belo Lada russo e vermelho de dez anos atrás). Com software foi a mesma coisa.

E como ainda estamos no capitalismo, e o que vale é a lei do mercado (a escolha do melhor), pergunto: porque o OSS não ganha do software proprietário, se é tão superior? Oras, o Firefox atingiu 20% de uso esse mês, demonstração de que é possível alcançar um pedaço do mercado. Agora perde só por uns setenta e pouco por cento do IE, ou quase quatro vezes mais (isso até sair o IE 8…). Isso prova que o mercado é dinâmico, e permite a entrada de novos concorrentes. Veja também o caso da Microsoft no mercado de jogos com o XBOX, se colocando junto a Nintendo e Sony entre as maiores do mundo em pouquissimo tempo. Enquanto isso o Linux sua muito pra conseguir um pedaço do mercado, e a Apple, com uma boa propaganda, conseguiu muito mais do que o Linux em tanto tempo, e renasceu das cinzas. O problema é o modelo do OSS: ele prova, a cada dia, ser inferior, e, portanto, produz produtos que as pessoas não querem usar.

E sabe porque as pessoas não querem usar? Agora a grande resposta:

Porque software livre é construido sem motivações financeiras. É o dinheiro que motiva as empresas a criar software mais adaptadao ao mercado. Quem demanda mais é mais atendido. Vocês querem touch screen? Entregamos. Vocês querem RIA no browser? Entregamos. Vocês querem sistemas distribuidos? Entregamos. Enquanto isso, a galera do software livre faz o software para si mesma, não para o mercado. E ninguém usa.
Não falei que era diretamente antagônico à alma humana e ao mercado? Quando projetos OS tiverem que se preocupar com seus usuários, com quem paga a conta de luz, então vão passar a fazer produtos melhores. Mas aí, já não são mais projetos abertos, são?

E não que eu seja radicalmente contra projetos abertos. O próprio grupo de arquitetura está planejando realizar projetos de exemplo de boa arquitetura para diversos domínios. Livre e aberto. Colaborativo. Mas, acima de tudo, despretencioso. Ah, e se uma grande empresa vier e fizer melhor que o nosso? Vou achar ótimo, menos trabalho. O objetivo não é ganhar, é ver o resultado. E isso só aconteceria se uma demanda de mercado existisse por tal produto, o que quer dizer que a sociedade, em números expressivos, o demandaria, e aceitaria, inclusive, pagar por ele. No fim, o dinheiro é o que desnuda o desejo humano, já dizem os economistas. Ele vai para onde as pessoas mais querem (por isso tanto dinheiro em futebol e televisão, lamentavelmente).

…

No caso desta discussão, minha opinião se manteve. Não foi tudo isso que discuti neste sábado, mas este é meu pensamento. E você, o que acrescenta à discussão?
(Já adianto que eventuais comentários de ódio serão desconsiderados e possivelmente apagados. Tente discutir amigavelmente e com educação e inteligência, e retribuirei na mesma moeda. Xiitas, xoo!)

Não fui em quem falou, foi o Ed Bott, blogger profissional da ZDNet, com dados reais da MSI. Sugiro a leitura.

Segundo ele e a MSI, o usuário simplesmente não se dá com toda essa complicação e toda a mudança de estilo de trabalho que a mudança de S.O. demandaria. Para suportar a mudança a pessoa deveria ser tecnologicamente proficiente, e não deve se importar de estar longe (para não dizer “esquecida”) do mainstream.

Minha contribuição à linha de pensamento de Mr. Bott: não são só os usuários. As empresas também não querem se dar ao trabalho de ter que treinar cada novo funcionário, seja ele do administrativo, financeiro, balção, ou de onde for, só para o cidadão poder começar a trabalhar. Para isso, só com Windows.

Nem vou entrar em remuneração e oportunidade. O mercado demanda Windows, e quanto maior a demanda, maior o salário. É claro que a oferta também é maior, e que o mercado se ajusta de acordo com as oportunidades, mas um mercado maior garante maior economia, maior sinergia, e maior solidez.

Com essa crise financeira atual, você gostaria de estar trabalhando em um projeto Open Source para viver?

Meus amigos, meus amigos, que tempos são esses? Já faz quase dois anos que o Windows Vista foi lançado, e ainda vejo alguns desenvolvedores preocupados com a estabilidade, usabilidade ou algum outro possível problema que o Vista pode lhes causar. Já é difícil conceber isso em um usuário comum, mas desenvolvedores são pessoas de TI! Eles devem ser inovadores, olhar para a frente. Se os desenvolvedores não estiverem olhando para as novidades, olhando para o futuro, o futuro nunca vai chegar. E tem desenvolvedor vivendo ainda em 2001, que foi quando o Windows XP foi lançado. Sete anos atrás. Vocês são o primeiro canal de entrada das inovações no mercado!

Até entendo um pouco de receio no início do lançamento. Não estou dizendo que todos deviam instalar assim que foi lançado (eu fiz isso), mas dois anos… Eu só não instalo na minha máquina principal quando é beta, alfa, CTP. Para isso, todo mundo que me conhece ou acompanha o blog sabe, uso máquina virtuais. Tenho mais de 10 (e bastante espaço em disco, é verdade, mas vale a pena).

Ainda vejo desenvolvedores ansiosos por novidades, por ver o que melhorou, ver o que há de novo. Mas muitos andam receosos, com medo das novidades. Será que é porque há tantas? Já vi medo, além do Vista, também do .Net 3.5, do Office 2007, do ASP.Net MVC…

Estão todos caindo nas lorotas da Apple, que estereotipou, como bem diz a nova propaganda da Microsoft, o Windows e seus usuários.

Aí vejo coisas deste tipo:

Dá uma olhada como era no Windows 95:

O negócio tem 13 anos! E tem desenvolvedor usando assim, vivendo 13 anos no passado.

E os ribbons do Office:

Eu adoro! Melhorou muito a minha produtividade. Ok, levou alguns dias para acostumar. Mas foi isso: depois que esse pequeno período de adaptação passou, você não quer voltar ao velho menu File, Edit… E como tem desenvolvedor reclamando. Gente, usem o Lotus 123 ou Wordstar então, que tinha que fazer contorcionismo para colocar um acento.
(Mostrei o menu de Review do Word de propósito. É o que eu mais uso na edição da .Net Magazine, ajuda muito, todas as funcionalidades necessárias no mesmo lugar.)

Ano que vem o Windows 7 vai ser lançado, ao que tudo indica. E ainda vai ter desenvolvedor usando o XP. E o XP não é mais confiável, não é mais fácil de achar as coisas, não é mais bonito que o Vista. Ele perde em tudo para o Vista. Ok, é mais leve, mas a minha máquina aguenta. O Wal Mart está vendendo na sua recém lançada loja online PCs com Vista a partir de 599 reais, em 12 vezes de 49,92. Não tem o monitor e é um processador simples, mas é Windows Vista (SE, é verdade). E por R$ 999 você leva monitor, um dual core, e Vista Premium. Você não vai querer desenvolver com máquina sucateada, vai? PC é ferramenta de trabalho, se você não valorizar seu trabalho, ninguém vai. É igual táxi. O carro é ferramenta de trabalho, e todos que conheço preferem andar com um táxi Vectra do que um Corsa.

Tenho contato com muitos desenvolvedores diferentes nas consultorias que realizo. Não tenho como deixar de notar como a pessoa organiza sua área de trabalho. Um menu clássico no Vista (ou XP) diz muito sobre você. Diz que você não gosta de mudanças, ou não se adapta fácil. Não tenho como não pensar isso quando vejo esse tipo de coisa.

E reinstalações? Me lembro que depois de um tempo o Windows, até o XP, costumava começar a ficar mais lento. Registro sujo, fragmentação do registro, do HD, sei lá. Só sei que meu Vista tem quase dois anos e nunca precisei reinstalar. E a velocidade está igual. Já passei pelo service pack, upgrades de hardware, inúmeras atualizações de segurança, instalações e desinstalações de jogos, ferramentas de desenvolvimento, etc... Só para vocês terem uma idéia, meu diretório “Program Files” tem mais de 30 GB de software instalado.

E a máquina é rápida, muito rápida. Esse índice é o mesmo desde a instalação:

Já vi desenvolvedores que tiveram um pau no XP, e tiveram que reinstalar.

Falei:
- Já coloca o Vista!
Ele:
- Não, não, dá muito pau.

Dá mais seis meses o cidadão está fazendo outra instalação. E põe XP de novo. Não aprende. Não coloca o Vista por medo, mesmo com um monte de especialistas garantindo que é melhor. (Está certo que não é igual ao Linux, que, se você quer a versão nova do Firefox ou quer rodar o Flash com som tem que reinstalar todo o SO, recompilar o kernel, etc…)

Até à orientação à objetos tem gente resistente, e olha que o conceito é velho, hem. A pessoa programa procedural à tanto tempo e nunca aprendeu a programar com OO de verdade, que quando eu apresento fica inflexível. Fala que não precisa disso tudo, que é exagero fazer um modelo UML. A mesma coisa acontece com testes. Resistência, resistência, resistência. E inflexibilidade. Está aí uma ótima receita para não progredir na carreira.

Meus amigos, não sejam resistentes às novidades. Sejam criteriosos, mas olhem, experimentem, entendam. E se permitam um período de adaptação. Ou isso ou você vai viver em 1995.

E você, usa menu clássico ou o novo?

Nada melhor para começar a série de polêmicas do que a maior polêmica do ambiente .Net: C# ou VB?

Antes de mais nada, quero contar para vocês que eu comecei no .Net com o VB. Espero que isso não influencie o post, mas se você achar que estou puxando a sardinha para o VB, já sabe: comente, reclame. Eu gosto muito das duas linguagens, e minhas certificações foram tiradas com as duas. Vou fazer um pouco o papel de advogado do diabo: vou dizer que VB é o máximo e que o C# fica para trás, e depois vou fazer o inverso, e vamos assim. E vou tocar tanto em aspectos de linguagem, quando na IDE, que na verdade, reflete muito a linguagem. Vamos lá:

O VB possui a maior base de programadores do mundo. Por esse motivo, a linguagem sempre vai receber muita atenção. O VB é feito para permitir que uma pessoa entusiasta por programação, mas não profissional, possa programar, sem ficar se preocupando com um monte de detalhes. Por exemplo, no VB, os métodos são sempre públicos por padrão e por isso um amador não teria que se preocupar com a visibilidade do método. Além disso, o VB se aproxima muito de linguagens dinâmicas, por permitir late binding, parâmetros opcionais, variáveis não tipadas (ou quase), etc… Tudo isso permite que você escreva o código muito mais rápido. E como a Microsoft sabe que muitos amadores usam VB, ela parece fazer uma experiência mais completa no Visual Studio primeiro no VB. É por isso, por exemplo, que o VB tem a compilação em background no VB desde 2002, e o C# só ganhou isso agora, 6 anos depois, o que obrigava o desenvolvedor a ficar compilando tudo, a cada mudança de 2 ou 3 linhas, se quisesse ter certeza de que tudo compilava direitinho.

A mesma vantagem que o VB traz, por ser mais flexível, é também uma desvantagem, afinal, é mais fácil errar com VB. Late binding pode ser algo muito perigoso. Em um ambiente profissional, eu geralmente recomendo que projetos em VB sempre estejam com Option Strict ON, aproximando do comportamento que é no C# é padrão. O C# tráz por default um ambiente mais profissional, menos sujeito a erros amadores. Mas com VB você pode resolver esse problema, como eu disse, ligando o Option Strict. E com isso, a linguagem passa a ter todo o profissionalismo que o C# tem. Ok, ponto para o VB, que permite trabalhar como amador, ou como profissional.

Por outro lado, esse estilo mais profissional do C# me agrada muito. É só um estilo, é verdade, mas, por exemplo, o fato de o “references” estar lá, fácil, no C#, e não estar no VB, é muito legal. Os amadores iam ficar confusos com esse tal de “references”, mas e os profissionais, como ficam?

De repente poderíamos ter a opção do VB amador, e o VB profissional. Eu, por exemplo, não consigo trabalhar com os estilos de VB do Visual Studio:

A interface fica amadora demais, tudo fica escondido… Vou com a “General Development Settings” sempre.

Mas adoro o estilo declarativo de endereçar eventos do VB, com o Handles no final dos métodos. Eu não sei vocês, mas eu gosto muito de poder ligar eventos assim. Além do mais, se eu quiser remover o endereçador do evento depois, é só apagar o método, não preciso apagar também a declaração que liga o evento ao seu endereçador.

Mas o VB não tem refactor. Quer dizer, não por padrão, já que você pode baixar o VB Refactor, da Devexpress, que é de graça e é, na verdade, melhor que o Refactor do C#. Mas isso não faz muito diferença, já que a maioria nem usa refactoring pela ferramenta, ou usa quase nada (quando não usa só o Rename). Empatou.

E o C# é mais sucinto. Você escreve menos, e isso é muito legal. Só fica ruim de ler, às vezes, com aquele monte de chaves fechadas. Gera aquela dúvida… “Essa chave é do for, ou é do if?”. Aí os caras colocam aqueles comentários…

Poxa, sé é para escrever “fim do main”, usa logo o VB… pelo menos ele termina com “End Sub”…

O VB tem uma outra vantagem: ele não é case sensitive. Isso te libera da preocupação do case da variável. Mas essa só é uma vantagem quando você começa a programar. Depois de uns anos, atrapalha muito, porque você tem uma bruta restrição nos nomes das variáveis, principalmente nas propriedades. Aí tem que ficar inventando nome para as variáveis e aparece cada absurdo:

Putz… “nomeDoCliente”? Que coisa horrorosa…

Ah, e por falar em propriedades, e as propriedades automáticas do C#? Eu adoro, é praticamente código auto-documentado. Se você coloca alguma identação ainda… fala se não fica bonito:

Muito bom! Limpo, organizado, fácil de ler. Essa não tem comparação.

Quer dizer, quase, não é… já viram XML literals, que só tem no VB? Dêem uma olhada em um exemplo que usei na .Net Magazine, no artigo de VB 9:

Meus amigos, isso é lindo. pedidos1 é uma variável do tipo System.Xml.Linq.XDocument. Sensacional! E é perfeita para usar no LINQ to XML, é claro. Tem todo o suporte de Intelisense, e permite essa sintaxe, que é de chorar de alegria:

E esse então:

Gera outro XDocument. Com C# isso dá um trabalho…

Uma coisa que gosto muito no C# é poder pular linhas, dar espaços, colocar o código onde eu quiser. No fim, coloco um ponto e vírgula e fica tudo certo. Já no VB preciso colocar aquele “_”. Na boa, não gosto. Não é “natural”.

E no C# as Lambdas ficam mais bonitas. Aquela sintaxe de “=>” (“goes to”, ou “vai para”) é o máximo. No VB fica tudo meio estranho. Nas duas demora um pouco para entender a primeira vez que você olha, e depois você acostuma com a sintaxe. Mas no C# é muito mais elegante. De longe. Vejam só:

E essa então:

É um exemplo simples, mas mostra a elegância do C#. Fala se é linha 27 não é uma coisa de louco? Muito legal.

Também gosto muito de poder, no C#, criar código inseguro e que chama direto as APIs de baixo nível. Sem precedentes no VB, até pela estrutura da linguagem, e sem dúvida algo muito poderoso. Ainda que pouquíssimo utilizado pela maioria, é uma possibilidade que gosto de ter à disposição se eu precisar.

Bom, se você leu até aqui, quero fazer uma conclusão, que acho que você já percebeu:

Não importa que linguagem você usa. C# é o máximo, e VB também é o máximo. E sabe porque? Porque as duas trabalham (e foram criadas para trabalhar) em conjunto com o .Net, que é o que as deixa poderosíssimas. Tem casos em que C# é melhor. Tem casos em que VB é melhor. Dêem uma olhada em um exemplo em que o Scott Hanselman mostra o impacto de escolher C# na hora errada. Já vi vários exemplos que mostram o oposto também, mas não me recordo agora de um link fácil. O que importa é escolher a melhor ferramenta para o trabalho. Sempre recomendo: aprenda as duas. Saiba usar as duas. E use cada uma com o que tem de melhor.

Finalizando, se você trabalha com C#, este post da MVP Kathleen Dollard é bem legal para quem está iniciando no VB. O interessante é que o primeiro item que ela coloca é “Passe por cima do seu problema com respeito (ao VB), ou desista antes de começar. O VB é uma ótima linguagem”. E se você trabalha com VB, dê uma boa olhada no C# (e ligue seu Option Strict). VB pode parecer mais fácil, mas acredite: VB e C# são dialetos de uma mesma lingua.

E você, o que acha? Prefere C# ou VB? Porque? Já parou para pensar no motivo? Já vi muitos desenvolvedores que querem dar ao C# um ar elitista, como se o VB fosse uma linguagem menor, e com certeza você também já viu (daí a Kathleen Dollard mencionar o respeito). O que acha disso?

E para fechar, colocando um pouco de pimenta: já viram o F#? Saiu uma nova versão de preview esse mês. Esse aí não é irmão, como o C# e o VB. É primo. E vai ter suporte, ao que tudo indica, no mesmo nível do VB e do C# (vamos poder criar aplicações web, console, etc). E lá vamos nós aprender uma nova tecnologia, quase do zero (já conhecemos o resto do .Net, certo?). TI é isso. Aprendizado constante.

Estou iniciando uma série que vou chamar de “polêmicas”. Quem me conhece sabe que adoro uma boa troca de idéias, uma boa discussão. O objetivo é dar uma opinião, e, nesse caso, a minha. Mas como opinião todo mundo tem, e você pode não concordar comigo, os comentários estão aí para isso. E se concordar também pode acrescentar.

Estou aberto para sugestões dos temas. Já tenho uns 3 ou 4 em mente. Não há limites, então fiquem à vontade para sugerir. O seu feedback é muito bem vindo.

O primeiro post sai daqui a pouco.