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…
10 static void Main(string[] args)
11 {
12 }//fim do main
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:
12 Private nomeDoCliente As String
13 Public Property Nome() As String
14 Get
15 Return Me.nomeDoCliente
16 End Get
17 Set(ByVal value As String)
18 Me.nomeDoCliente = value
19 End Set
20 End Property
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:
14 public string Nome { get; set; }
15 public int Id { get; set; }
16 public DateTime DataDoCadastro { get; set; }
17 public string Telefone { get; set; }
18 public string Endereco { get; set; }
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:
23 Dim pedidos1 = <?xml version="1.0" encoding="utf-8"?>
24 <pedidos>
25 <pedido id="1" descricao="uma desc"/>
26 <pedido id="2" descricao="outra desc"/>
27 <pedido id="3" descricao="mais uma desc"/>
28 </pedidos>
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:
29 Dim p1 = From p In pedidos1.<pedidos>.<pedido> _
30 Where CInt(p.@id) > 1
E esse então:
32 Dim produtosXML = From p In db.Products _
33 Select <produto>
34 <id><%= p.ProductID %></id>
35 <name><%= p.ProductName %></name>
36 <qtty><%= p.QuantityPerUnit %></qtty>
37 </produto>
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ó:
22 Action funcao = () => Console.WriteLine();
E essa então:
25 void Teste()
26 {
27 Escreve((texto) => Console.WriteLine(texto));
28 }
29 void Escreve(Action<string> acao)
30 {
31 acao("Hello world");
32 }
É 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.