Debate VB.Net vs C # [fechado]

Eu estive em locais de trabalho em que, no início de um projeto, a pergunta "Devemos usar o VB.Net ou C #" foi levantada.

Concedido, provavelmente é menos comum ter que tomar essa decisão agora do que nos primeiros dias do .Net, principalmente devido à tendência de convergência de idiomas, mas ainda pode ser um debate acalorado.

Então, entre VB.Net e C #, qual idioma você prefere e por quê?

Eu prefiro C # sobre VB.NET porque

• é mais fácil encontrar programadores / trabalhos:

• é mais fácil encontrar ajuda:

^{(do stackoverflow)}

Eu odeio o VB.NET. Os dias que ainda uso são os que me arrependo. Dito isto, meus gostos fazem parte da minha situação e experiência e não têm necessariamente nenhuma relevância para o que você está fazendo ...

Eu acho que é importante, ao comparar linguagens em constante evolução como C # e VB.NET, olhar para trás na história deles e ver como eles chegaram ao estado atual:

As vantagens originais do BASIC em microcomputadores incluíam tamanho e simplicidade (sintaxe pequena e fácil de analisar, criada para intérpretes pequenos e razoavelmente rápidos e espaço deixado na memória para o programa e dados reais), um ambiente interativo que permitia a experimentação e uma sintaxe que evitavam símbolos e estruturas concisas para uma sintaxe razoavelmente clara, semelhante ao inglês. No entanto, era pouco adequado para programas grandes e estruturados e tendia a incentivar o código do espaguete. Ainda assim, sua disponibilidade e simplicidade o tornaram uma excelente opção para uma introdução à programação.

O QuickBasic atualizou a sintaxe para permitir grandes programas mais estruturados e adicionou compilação para uma execução mais rápida.

O VisualBasic forneceu um construtor de formulários poderoso e fácil de usar para permitir a construção rápida de aplicativos da GUI, adotando a sintaxe QB para uso no script dessas UIs. Funcionou melhor quando usado para criar interfaces de usuário para lógica de baixo nível fornecida como componentes pré-criados (geralmente escritos em outro idioma). Com o tempo, a sintaxe tornou-se cada vez maior e inconsistente à medida que novos recursos foram implementados. O foco na elaboração de uma interface do usuário primeiro e depois no preenchimento de bits de script funcionou bem para aplicativos pequenos centrados na interface do usuário, mas tendia a incentivar a programação de copiar e colar e uma variação no código de espaguete, além de desencorajar a reutilização, estruturas de dados complexas e separação de preocupações. Na mente de muitos, "código VB" tornou-se sinônimo de "grande bola de barro"; "Programador VB" com "hack inexperiente".

O VB.NET é uma linguagem semelhante à do VB na plataforma .NET, uma tentativa (não totalmente bem-sucedida) de limpar e modernizar a sintaxe do VB, que está superlotada. Não era perfeitamente compatível com o código VB existente e não fazia nenhum esforço para fornecer compatibilidade com os formulários VB (possivelmente a parte mais importante do VB). Isso deixou muitos proprietários de produtos VB com a opção desagradável de reescrever efetivamente seus aplicativos no VB.NET (lidando com incompatibilidades sutis em todas as rotinas que não foram cuidadosamente examinadas) ou realmente reescrevendo seus aplicativos em C # (lidando com um problema desconhecido) sintaxe , além dea nova biblioteca de tempo de execução e designer de formulários). A maioria dos usuários do VB.NET eram usuários do VB que aderiram apenas à sintaxe, muitos usando-o como muleta enquanto aprendiam C #. Como resultado, imediatamente adquiriu a reputação de refúgio para programadores que ficaram presos em seus caminhos, indispostos ou incapazes de expandir ou melhorar suas habilidades.

Neste momento, o VB.NET continua a evoluir, perdendo lentamente a bagagem e adquirindo uma nova e interessante sintaxe (LINQ, literais XML). Ainda assim, ele mantém quase nenhuma das vantagens originais do BASIC: é uma linguagem grande e complexa, com uma curva de aprendizado bastante íngreme e oportunidade limitada para experimentação interativa.

• Para programadores antigos que o mantiveram nos últimos 30 anos, não é uma má escolha, desde que não se limitem a isso.
• Para os novos programadores, a semelhança cada vez mais vaga dos programas VB com o inglês dificilmente vale os acenos bizarros de compatibilidade com versões anteriores e estigma social.
• Para novos projetos , o VB.NET é uma escolha estranha, a menos que o projeto esteja fortemente envolvido em uma das poucas tarefas para as quais a linguagem é otimizada: integração com componentes COM com tipos ruins (Office ...) (embora o C # 4.0 reduza consideravelmente essa vantagem ) ou geração XML embutida.

Eu estou familiarizado com os dois, mas fiz muito do meu trabalho inicial de programação em VB4, VB5 e VB6. Agora que os dois idiomas do .NET passaram por algumas iterações e convergiram bastante em seus recursos, acho que o debate é absolutamente tolo, muito parecido com "qual é a sua cor favorita".

Pessoalmente, gosto dos dois por diferentes razões.

VB.NET
Muitas pessoas falam sobre como a sintaxe C # é mais intuitiva, mas isso é muito subjetivo e baseia-se fortemente no que você começou a conhecer. Eu argumentaria que se você fosse completamente objetiva, a sintaxe do VB.NET provavelmente será mais intuitiva se você não assumir o conhecimento prévio em outro idioma. Por exemplo, dado o mesmo programa em C # e VB.NET, que você acha que seria mais decifrável para alguém que não tem conhecimento de programação. Parece muito claro para mim.

A outra coisa interessante nessa sintaxe é que é muito mais explícito sobre o fechamento de estruturas (END IF, END WHILE, NEXT X) em comparação com o modelo de bracketing. Isso torna o código um pouco mais legível e geralmente permite que o compilador seja mais preciso em que número de linha exatamente está causando erros de compilação. Se você já esteve em uma busca entre parênteses / ponto e vírgula devido a um erro do compilador a 50 linhas do problema, você sabe o que quero dizer.

Além disso, na coluna VB.NET Win, na minha opinião, há falta de == / = como operadores de comparação / atribuição. Os raros benefícios de ter um operador distinto para cada um nunca compensarão todos os (às vezes) pontos difíceis de descobrir que ajudam a criar.

Finalmente, eu odeio a distinção entre maiúsculas e minúsculas em linguagens de programação. Uma das reclamações sobre o VB é que ele tem muita bagagem, mas o C # levou adiante o albatroz da sensibilidade de casos do C. Nunca estive em uma situação em que desejasse que dois identificadores no mesmo escopo diferissem apenas por caso. Isso contribui para o trabalho ocupado e me atrasa. O VB.NET obtém alguns pontos sobre o C # nesse sentido para mim.

Os programadores de C #
gostam de ser concisos, e é por isso que acho que geralmente favorecem essa sintaxe. Apenas tem um certo apelo estético. No entanto, de uma perspectiva completamente prática, eu gosto, porque é muito semelhante a linguagens como Java, JavaScript e C ++.

Como eu desenvolvo muito o desenvolvimento da Web que requer programação do servidor e do cliente, acho mais fácil alternar mentalmente entre C # e JavaScript, como frequentemente preciso.

Também gosto do fato de que, na maioria das vezes, se eu tivesse que fazer a transição para programação em Java ou C ++, eu teria um pouco de vantagem se estivesse usando C # na maioria das vezes.

Prefiro a sintaxe de colchete das linguagens no estilo C à sintaxe mais "detalhada" das linguagens no estilo BASIC.

Minha introdução à programação foi com o Turbo Pascal. (A parte da programação BASIC que fiz no Commodore 64, quando criança, não conta realmente.) Depois de aprender Java, nunca olhei para trás e preferi a sintaxe no estilo C.

Eles são funcionalmente iguais, não há nada que você possa fazer em um que não possa fazer no outro e, no futuro, a Microsoft prometeu que as equipes de idiomas se desenvolverão igualmente, de modo que é improvável que essa equivalência mude.

As diferenças agora são puramente culturais e pessoais. Este artigo é uma leitura interessante sobre as diferenças entre as culturas de programadores usando C # e VB.net

_{[Nota: Embora eu seja um desenvolvedor de C #, a conclusão do artigo vinculado não reflete necessariamente minha opinião pessoal, é apenas uma abordagem alternativa interessante no debate]}

Eu vim para o .NET a partir de C e C ++ (com um pouco de Java, Ada e Pascal), então o C # era a progressão natural para mim.

Se surgisse um trabalho que exigisse o VB.NET, certamente não o recusaria.

Eu trabalhei muito com o VB.NET, mas compreendo C # suficiente para entender o que está acontecendo no código. Minha preferência atual é o VB.NET porque eu estou mais familiarizado com isso (obviamente), mas realmente não tenho uma preferência entre a sintaxe detalhada do BASIC e a sintaxe do estilo C, ambas são muito legíveis e compreensíveis para mim.

A maior parte do histórico de programação de meus colegas de trabalho é COBOL e VB6; portanto, o VB.NET era a opção de linguagem .NET mais confortável para nós, como equipe. Não havia uma razão sólida para nós que tornasse o aprendizado de C # um requisito, pois eles são funcionalmente iguais.

Dito isto, aprender C # está definitivamente na minha lista de coisas a fazer.

Eu prefiro c #.

Comecei como programador do VB.NET, mas com o passar do tempo tornou-se óbvio que muitos recursos novos chegavam primeiro ao C # e depois ao VB.NET (por exemplo, propriedade automática). E a comunidade em torno do C # é muito mais animada que a do VB.NETs.

Além disso, se você pretende aprender Java ou linguagem semelhante, o C # é o melhor ponto de partida - a sintaxe é quase a mesma em todas as linguagens derivadas do C. Embora isso não seja um ponto de inflexão para mim, uma vez que a sintaxe é algo que você pode aprender rapidamente de qualquer maneira.

Além das outras respostas postadas aqui, eu escolheria C # em vez de VB porque os programadores de C # recebem mais. Mais experiência com C # = mais $$ :)

Eu sei que os dois idiomas são quase os mesmos e é realmente fácil alternar entre os dois, mas acho que quando a gerência olha para um monte de chaves e ponto-e-vírgula, eles aceitam o fato de estarmos fazendo algo que não podem fazer, onde o VB. Na rede, eles podem olhar e dizer "ah, isso não deve ser tão difícil de fazer se eu puder entender".

C # porque eu posso alternar entre ele e Java com o mínimo esforço

VB.NET é uma sintaxe totalmente diferente. C #, sendo semelhante ao Java e outras linguagens, me dá uma posição melhor para me adaptar rapidamente a coisas novas. Como a saída de C # e VB.NET é praticamente intercambiável, faz sentido usar C #. Além disso, se o código da sua empresa estiver em C #, é mais provável que você treine um desenvolvedor Java como codificar C # do que um desenvolvedor Java VB. Existem apenas vantagens sutis, mas sutis ainda é uma vantagem.

Colocando minhas preferências pessoais de lado. Como alguém que está recrutando (e tentando ser recrutado) recentemente, quando tivemos esse debate no escritório, o consenso geral era de que deveríamos procurar migrar para C # do VB.

Por quê? Como o C # era mais prevalente no mercado (à nossa volta, de qualquer maneira), permitindo-nos recrutar mais facilmente e ser recrutado mais facilmente.

Parece que deu um ciclo completo; as pessoas aprendem c # porque os recrutadores querem, porque há mais candidatos.

Sendo um desenvolvedor um pouco mais velho (é 59 "um pouco" mais velho?), Eu aprendi o BASIC primeiro em um Commodore VIC-20, me ensinei Turbo Pascal (v1!), Aprendi COBOL na faculdade e passei 14 anos desenvolvendo na IBM mainframes, com breves diversões escrevendo aplicativos de tamanho médio no Revelation BASIC (uma variante do PICK BASIC) e alguns utilitários no Modula-2, antes de passar para o VB5 e VB6. E então veio o .NET.

Por causa da minha formação básica, achei que deveria começar com o VB.NET, apenas para descobrir que continuava tentando fazer as coisas da maneira "antiga" e isso estava me deixando louca (ok, mais loucas). Sendo que eu tinha feito algum trabalho em C, pensei em dar um giro em C # para ver como isso foi. E OMG, foi como emergir de um túnel escuro para a luz do dia! Totalmente inesperado. E eu costumava fazer barulhos depreciativos sobre o C ser uma linguagem "somente de gravação" - "tão difícil de entender que um programador de C não conseguia descobrir o que seu próprio código fazia seis meses depois de escrevê-lo", uma observação feita por romancista semi-famoso que eu achava fofo na época.

Portanto, em virtude de eu não estar familiarizado com o C, o C # era paradoxalmente mais fácil para eu aprender programação .NET do que o paradigma básico muito mais que deveria ser familiar. Eu ainda gosto de VB6, mas já adorei C #. A melhor linguagem de programação do planeta.

Eu desenvolvo no Visual Basic .Net desde 2001 e adoro e odeio !!!

A ordem de apresentação desses pontos é baseada apenas na ordem em que ele veio à minha mente ...

No vb.net com visual studio, há uma quebra de linha visual entre cada método, propriedade. Para muitas pessoas, não é um bom motivo para preferir vb.net em vez de c #, mas não entendo por que a equipe de c # da Microsoft não a implementou. Há um suplemento que desenha essa linha no c #, mas obrigado novamente a Microsoft a ter uma equipe de c # e uma equipe do Visual Basic que não se comuniquem.

No vb.net, ao criar um winform, você tem duas caixas de combinação no visual studio na parte superior do editor e pode gerar automaticamente um evento automaticamente ao selecionar um evento na caixa de combinação correta. Quando você anexa dezenas de eventos por dia, pode ser muito complicado não ter esse recurso. Com o c #, você tem um pequeno botão na parte superior da grade de propriedades que pode gerar eventos, mas não é rápido como no vb.net. Além disso, se você anexar um evento de controle em c # e excluir o controle no formulário, o delegado criado no código gerado automaticamente para manipular o evento deverá ser excluído manualmente. Obrigado novamente Microsoft.

No vb.net, quando você tenta modificar um método que contém uma consulta linq sem modificar a própria consulta, não há problema, mas em c #, todo o código do método está bloqueado. Se você tiver muitas consultas linq ou expressão lambda, o recurso de edição e continuação será rapidamente uma boa coisa. Ok, um pouco de exagero ... mas :)

No vb.net, quando você cria um nome de método e toca em enter, o 'end sub' será criado automaticamente. Em c #, faça você mesmo. Ok, se você tiver o re-sharper ou o DevXpress instalado, será melhor, mas por que todos esses recursos, exceto os grandes, não foram implementados em c #.

No vb.net, quando você tem erros no seu código, os erros são exibidos automaticamente e quando você o corrige, esses erros são removidos da pilha em tempo real. No c #, você precisa criar seu projeto para perceber que corrigiu com êxito ou não os erros especificados. Por que a equipe do c # não colocou uma opção para verificar erros em tempo real, como no vb.net. Com uma solução grande, nenhuma verificação de erro em tempo real pode ser uma ótima otimização de desempenho, mas eu adoro ver uma pilha de erros desaparecer enquanto a corrigo.

Como outras pessoas mencionaram, acho mais fácil ler a condição vb.net se ... enfim, selecione case ... end select, mas com o suporte de pintura devexpress, esqueça o que eu disse.

Com o vb.net, existem muitos bugs no visual studio. Apenas para mencionar uma no visual studio 2010, os intellisens não filtram a enumeração corretamente se você tiver o modo "comum" ativado em vez de "todos".

Com o vb.net, você é visto como um cara falso, porque, estaticamente, mais programadores ruins usam o vb.net em vez do c # porque o c # é mais difícil de aprender e promove melhores práticas de programação.

Como outro dito, o programador de c # tem mais chances de ter um bom trabalho com mais dinheiro.

Na cabeça do cliente, vb.net = cara que programa em seu porão com um bolinho de espaguete de código. c # = uau, você é muito inteligente. O fato é que não é porque você programa em c # que você faz um bom programa, mas estaticamente, sim.

Com todos esses pontos, optei por converter todo o meu código vb em c #. Eu programo com todas as melhores práticas de orientação a objetos, padrão de design, código limpo com padrões e sintaxe estrita e posso programar assim por 50 anos, mas aos olhos da comunidade, não sou um bom programador. Vou converter meu código em c # sem outras práticas recomendadas e serei outra pessoa; um cara legal que você deve respeitar ..... :( que piada ... !!! mas é a realidade.

Aqui está uma maneira de analisar: entre o SO e o CodePlex, qual idioma é mais popular? C # ou VB.Net?

Às vezes, seguir o rebanho é uma coisa boa, porque é o rebanho que poderá ajudá-lo quando você precisar. Por padrão, o C # será mais rápido que o Vb.Net. Eu acredito que usando a opção Strict pode igualá-lo embora. A última vez que comparei a IL entre as duas, a segurança de tipo do VB.Net acabou adicionando cerca de 15% a mais à IL. Isso se traduz em sobrecarga extra. E ... considerando os idiomas que fazem basicamente a mesma coisa, eu escolho o mais rápido. Minha conveniência não deve substituir a experiência do usuário em geral.

Eu gosto de dizer que a única razão pela qual o BASIC ainda é popular é que foi o primeiro produto da Microsoft e eles o enfiaram pela garganta nos últimos 35 anos. Deveria ter morrido há muito tempo.

Com isso dito, trabalhei em dois projetos importantes de .NET e ambos foram feitos com o VB.Net - embora houvesse um pouco de C # porque a tradução era uma droga, ou a construção não existia no VB.Net. A única vantagem que vejo no VB.Net é que o editor do Visual Studio é muito mais amigável (na minha experiência de qualquer maneira) do que com o C # - o Intellisense parece melhor e o autoformatting (o mesmo ocorre com o autoformatting (observe que, como eu não usei o C # tanto, posso estar faltando alguma coisa na configuração do IDE ...)

Uma grande desvantagem do VB.Net é que eles trouxeram muitas porcarias da era VB6 de volta ao .NET 1.x para facilitar a conversão do código VB6. Esse material ainda está lá, e os codificadores VB6 estão codificando um novo código usando essas ... "extensões" em vez de usar as classes / métodos / classes .NET mais neutros. Não sei quantas vezes perguntei ao meu chefe por que ele ainda usava essa porcaria. "Mas ... funciona ..." Certo. Ei, eu gosto de puta.

Enquanto procurava ajuda na Web, descobri que a grande maioria das soluções estava em C # - consulte os fóruns do MSDN, vários blogs, etc ... Os livros tendem a se concentrar em C # e, se houver uma versão VB, geralmente vem meses depois (por exemplo, Pro LINQ .... do Apress.)

Muitas linguagens compartilham a ancestralidade C, o que facilita a alternância entre C, C ++, C #, Java, PHP e algumas outras. O PHP é um pouco exagerado aqui, mas possui muitas construções do tipo C. VB? Bem, é praticamente a sua própria coisinha e é isso.

Recentemente, um líder de projeto em minha organização me disse que mais e mais novos projetos estão sendo desenvolvidos usando C # em vez de VB - FINALMENTE. Quando o .NET foi introduzido em nossa organização, eles adotaram mais ou menos oficialmente o VB.Net por causa de toda a codificação VB6 que já estava em andamento. Os poderes que mais tarde me admitiram que essa não era sua melhor jogada.

Como alguém acima apontou, eu não diria não a um projeto VB.Net, mas ainda espero que seja lentamente erradicado do desenvolvimento mais recente no meu local de trabalho.

Bem, hoje há pouco ou nenhum motivo real para usar o VB.net. No começo, era apenas uma maneira de fornecer aos programadores de VB uma sintaxe familiar, mas era essencialmente um remapeamento do C # semelhante ao BASIC. Portanto, sua única vantagem real é uma sintaxe mais familiar e sua sintaxe BASIC também é seu único limite real.

Com o tempo, as duas linguagens evoluíram paralelamente, a única diferença significativa é o my pseudo namespace.

Eu aconselho todos os programadores .net que não conhecem o C # a aprender, pois a comunidade é bastante maior e a sintaxe do tipo C é comum à maioria dos idiomas mais usados.

VB, a linguagem é mais fácil de ler para iniciantes, eles tendem a escrever sua primeira, segunda e terceira aplicações nela e todos sabemos como nossas primeiras aplicações são codificadas - terrivelmente.

Programadores de C ++, Java e etc mudaram para C #, enquanto os desenvolvedores do VB.NET são de experiência em VBA, VB e BASIC, programadores não tradicionais essenciais.

Parece haver mais exemplos de código C # online do que exemplos de VB.NET. Não é tão difícil converter um para o outro, mas por que se preocupar se você não precisa.

Eu prefiro VB .Net sobre C #,

• (97) ...
• (98) porque eu aprendi VB antes mesmo de conhecer C #.
• (99) porque eu já comprei um volume de 10.000 páginas no VB .Net.
• (100) porque o VB não possui chaves.
• (101) porque todo mundo odeia VB.

C #. É só porque eu fiz C e Java, então eu sinto que o C # é mais legível para mim. C # é para mim, assim como o VB.NET é para ex-programadores de VB.