Por que o VB é tão popular? [fechadas]

28

Para mim, o Visual Basic parece desajeitado, feio, propenso a erros e difícil de ler. Vou deixar que outros expliquem o porquê . Embora o VB.net tenha sido claramente um grande avanço para o idioma em termos de recursos, ainda não entendo por que alguém escolheria codificar no VB sobre, digamos, C #.

No entanto, ainda vejo (o que parece ser) a grande maioria dos aplicativos comerciais da Web das "lojas da Microsoft" são construídos no VB. Eu poderia ficar corrigido nisso, mas o VB ainda parece mais popular do que merece.

Alguém pode ajudar a responder qualquer uma (ou todas) destas perguntas:

  • Estou perdendo alguma coisa com o VB? É mais fácil aprender ou "mais amigável" que o c #? Existem recursos que eu não conheço?
  • Por que o VB / VB.net é tão usado hoje em dia, especialmente em projetos web?
aaaidan
fonte
4
Como você sabe com que sites comerciais da Microsoft foram criados?
28310 samjudson
30
"Por que o VB / VB.net é usado com tanta frequência hoje em dia", é como perguntar "Por que as mulas / caminhões são tão frequentemente usados ​​hoje em transporte?"
Daniel Daranas
2
Apenas para a posteridade, eu permaneço (timidamente) corrigido. O VB tem uma comunidade de usuários muito leais, o que diz muito.
5
esta pergunta deve ser excluída.
25
Não exclua esta pergunta. É ruim, preconceituoso e subjetivo, mas muitas vezes ocorre e pode servir como referência.
Konrad Rudolph

Respostas:

47

O VB pode ser usado para criar interfaces gráficas (GUO) para rastrear endereços IP. Isso é frequentemente usado na solução de crimes .

Rick J
fonte
4
Uau. Somente. Uau. Isso apenas fez meu dia totalmente incrível.
1
omg wow ... omg uau.
2
Nunca mais vou olhar para o CSI da mesma maneira.
Robert Harvey
3
Ampliar ....... ok melhorar.
42

Eu acho que depende de onde você vem. Ao iniciar como programador, acho que o VB pode ser mais fácil de ler do que o C #, por exemplo, uma vez que depende mais de palavras do que de símbolos, o que facilita a aceitação por pessoas comuns.

Eu fui programador de VB por muitos anos e, quando o .NET chegou, eu ainda trabalhava no VB.NET nos primeiros dois anos (realmente não entendi o que era o C #). Agora, tenho alguns anos de c # atrás de mim e às vezes acho que o código VB.NET demora um pouco mais para eu "decodificar" do que o código c #. Possivelmente porque depende mais de palavras do que símbolos para alguns produtos ...

Fredrik Mörk
fonte
5
Você também está descrevendo minha situação.
6
O mesmo aqui - o código VB.NET está cheio de "ruído" quando você olha para ele de uma perspectiva de sintaxe no estilo C. Sem ofensa a nenhum desenvolvedor de VB. Exatamente como você se sente quando passa de C # para VB.
2
concordou, eu não suporto o VB.NET - a sintaxe é como uma história ... e sim, eu tenho que usá-lo constantemente há meses, me deixou louco, eu amo a sintaxe C #.
Dal
2
Programadores de C # não são pessoas comuns?
rightfold 13/09/11
@rightfold Nope. Programadores VB.net também não são normais. Os programadores do VB.net são mais impressionantes do que as pessoas comuns e, para C # ... sem comentários. = D REGRAS DO VB.net !!!!!!!
Anonymous Penguin
27

Abaixo, eu apenas copiei minha resposta para outro tópico :

Eu desenvolvo em VB e C # regularmente, a maior parte do meu dinheiro envolvia C #. Pessoalmente, prefiro o VB para a maioria (mas não todos ... lambdas!) Do trabalho. Eu realmente não posso citar nenhuma vantagem difícil além das descritas por Jon. Na verdade, Herfried coletou alguns em seu site (em alemão!), Mas eles são bastante técnicos.

O que realmente me incomoda em toda a linguagem relacionada ao C é a sintaxe estúpida. Isso é puramente cultural, mas como alguém que faz a maior parte de seu trabalho profissional em C ++, e sendo bastante proficiente nisso, eu ainda odeio absolutamente a sintaxe. E não apenas pequenas peculiaridades fofas do C ++. Não, todo o pacote. Por que aparelho? Por que ponto e vírgula (talvez a decisão mais estúpida em toda a história da programação)? Por que a estúpida sintaxe de elenco no estilo C? Por que não existe uma palavra-chave para declaração de variáveis ​​(na verdade, essa é a decisão mais estúpida)?

Há tantas coisas que realmente me deixam triste e com raiva. VB não é santo, sua linguagem tem enormes desvantagens. Mas nada comparado ao que eu disse acima.

Percebo que a maioria dessas declarações precisa de justificativa, mas afirmo que isso ocorre apenas porque nos acostumamos a elas. Além disso, aqui não é o lugar certo. Basta dizer que a sintaxe do C #, embora seja sua principal vantagem sobre o VB, também é sua principal desvantagem.

Não prefiro o VB por causa do Mynamespace, não prefiro os literais XML, não prefiro a digitação fraca, não prefiro os parâmetros opcionais ou o melhor switchdeclaração. Não, eu prefiro por causa da sintaxe.


Dito isto, tenho que admitir que o VB fica cada vez mais sobrecarregado por sua sintaxe. O hype mais recente parece ser as consultas do Linq parametrizadas com funções lambda e eu admito prontamente que isso simplifica muitas coisas. Infelizmente, a sintaxe do VB para lambdas é simplesmente muito complicada para competir com o C #. Considere como a chamada Parallel.Forfica inchada no VB - em comparação com o C #, onde parece natural. IMHO, a equipe de design do VB foi na direção errada aqui, favorecendo a consistência conservadora sobre a legibilidade.


Para responder à sua acusação subjetiva:

Para mim, o Visual Basic parece desajeitado, feio, propenso a erros e difícil de ler.

Você certamente tem o direito de pensar assim, mas, como Marc disse abaixo, será difícil argumentar isso objetivamente. Definitivamente, posso citar vários elementos da sintaxe C que são objetivamente mais suscetíveis a erros do que qualquer coisa existente no VB. De fato, a sintaxe do VB foi desenvolvida para impedir explicitamente tais situações.

"Desajeitado, feio ... e difícil de ler" são todos os qualificadores que podem ser marcados em quase todos os idiomas com os quais você não está familiarizado. Simplificando: a feiúra é uma conseqüência direta de seu desconhecimento da língua.

Conhecer bem um idioma significa reconhecer padrões no código. Código bem escrito parecerá virtualmente elegante, enquanto código ruim (lento, propenso a erros) parecerá feio. É simples assim.


Uma última observação: os artigos citados por você contêm várias imprecisões e informações desatualizadas. Como única justificativa para uma discussão altamente subjetiva e emocional, eles não são muito adequados.

Konrad Rudolph
fonte
4
Blake: sim, pontos completos para Ruby. Finalmente, uma linguagem fazendo certo. Python também tem uma pontuação alta comigo. Ainda assim, estou parcialmente insatisfeito com todas as sintaxes existentes.
289 Konrad Rudolph
2
Ruby é péssimo: P ... agora que eu tenho isso fora do caminho ... a verdadeira razão das diferenças de sintaxe majoy entre a palavra-chave com base no aparelho se resume à facilidade de escrever o analisador. Eu costumava ser um enorme VB (BASIC em geral) fã, mas desde que eu mudei para C # Acho que é muito mais fácil e mais rápido para trabalhar.
Matthew Whited
4
Por que aparelho? Porque eles demarcam visualmente um bloco de código, se usado corretamente. Sim, percebo que o recuo no VB também faz isso, mas os aparelhos fazem isso com maior clareza IMO. O ponto e vírgula facilita as coisas para o compilador (basta perguntar à equipe do compilador VB sobre isso). Acho a transmissão em C # altamente intuitiva e compacta. E lá é uma palavra-chave declaração da variável:var
Robert Harvey
1
@ Robert Harvey: 1) VB usa palavras-chave para indicar blocos, não recuo. Tanta clareza. 2) Sobre a transmissão, o C ++ optou corretamente por reprovar a transmissão no estilo C há muito tempo, porque é visualmente imperceptível ( não é uma coisa boa; uma transmissão deve se destacar, pois introduz semânticas alteradas e possíveis fraquezas do uso do tipo). 3) Não. Eu quis dizer uma dica sintática que precede todas as declarações. var int xvem à mente. Todas as outras instruções e blocos são introduzidos por palavras-chave dedicadas, por que não declarações de variáveis ​​e métodos? Fie. Inconsistente e feio.
Konrad Rudolph
4
@ Konrad: Admito que demorou um pouco para se acostumar. Parte da diferença filosófica pode ser que eu não penso mais na minha linguagem de programação como uma variante do inglês, como eu fazia quando programava em VB. Mover para C # tornou a linguagem de programação que eu uso um pouco mais simbólica (e sucinta), sem ser muito opaca. Esse simbolismo me permitiu a liberdade mental de pensar mais conceitualmente sobre coisas como orientação a objetos, transmissão de mensagens e lambdas.
Robert Harvey
15

Para mim, o Visual Basic parece desajeitado, feio, propenso a erros e difícil de ler.

Para mim, o inglês parece desajeitado, feio, propenso a erros e difícil de ler, especialmente escrito por pessoas que têm gramática ruim, ortografia ruim, desconsideração imprudente por letras maiúsculas e pontuação e nenhum senso de como organizar seus pensamentos espacial e mentalmente.

Não é apenas difícil ler ou desajeitado o Visual Basic devido à sintaxe da linguagem, mas geralmente é assim porque o programador não é realmente bom em expressar seus próprios pensamentos:

If blah = 10 Then If stuff = "foo" Then t = 1 + k: s = 42: dostuff21

Certo, isso é horrível. Mas também não é particularmente difícil escrever códigos horríveis em outros idiomas. Quando escrito corretamente, faria muito sentido, mesmo se o código fosse escrito em VB:

If SelectedType = 10 And UserName = "Foo" Then
    CurrentUsers = CurrentUsers + 1
    UserConnectionID = 42
    PerformUserOperation
End If

Pelo menos isso é mais legível e compreensível. Ainda é BÁSICO. Na verdade, tudo se resume à capacidade do programador de expressar claramente suas intenções, formatando o código de maneira fácil de ler, usando identificadores bem nomeados e prestando atenção na criação de código compreensível.

Dito isso, não toquei muito no Visual Basic desde os dias do VB3 (daí o exemplo com sintaxe "antiga"), mas apenas porque uma linguagem pode ser abusada não significa que ela não pode ser usada corretamente para escrever código bastante robusto . Claro, pode haver algumas deficiências, mas as abordagens criadas para contornar esses problemas também mostram as habilidades de um programador em detrimento de outro.

(A pulverização indiscriminada On Error Resume Nextvem à mente como uma maneira não tão boa de contornar as deficiências da falta de exceções no VB nos dias anteriores ao .NET).

coobird
fonte
13

A maior parte de sua argumentação contra o VB é aplicável apenas ao VB-Classic (segundo link) ou com base em argumentos fracos ou obsoletos

  • Mesmo no VBC, você não usará o GoSub ... Return etc.
  • O que há de errado static? O C ++ também suporta isso.
  • O VB10 introduz continuação implícita de linha (você nem precisa de semicola redundante como C #)
  • As diferentes funções de conversão também existem em C ++ e C #. A (object)(expr)sintaxe Cast de C # e object as typesão ainda mais confusas e inconsistentes.
  • O que há de ruim with? Você pode criar estruturas de árvores aninhadas de uma maneira muito intuitiva, o que não é possível em C #.
  • A manipulação de eventos no VB é muito mais elegante que no C #. Você pode introduzir e manipular eventos com uma única palavra-chave ( WithEvents) sem precisar inicializar delegados, eventhandler-procs etc. Isso torna a programação da GUI no VB muito mais confortável e você não precisa gerar o código de evento pelo designer .
  • Parâmetros opcionais são introduzidos no novo C # - portanto, eles parecem bons.
  • VB.NET tem ambos os operadores rigorosos e atalho-booleano.
  • Você não verificar se há erros de sintaxe em tempo de compilação, a menos que você executar VB como uma linguagem de script.
  • End Ifé mais útil do que apenas }. Ao ter estruturas sintáticas complexas, todas as chaves são apenas confusas, enquanto um concreto End ...ajuda você a determinar qual bloco não foi fechado.
  • Literais XML - o script XML agora faz parte do código, com suporte total do intellisense.

Em suma, existem apenas algumas diferenças objetivas entre VB.NET e C #, além da sintaxe. EG: O design da GUI é muito mais eficiente no VB devido a um melhor sistema de eventos e um IDE melhor, enquanto, por exemplo, os algoritmos podem ser expressos melhor em C # porque a sintaxe é concisa.

O resto é apenas uma questão de seu estilo pessoal. Programadores de estilo C se sentem confortáveis ​​com C #, VB (ou talvez Pascal?) - programadores de estilo usam VB.

Mas a sintaxe VB mais explícita e baseada em palavras pode ser mais fácil de ler para iniciantes do que todos os símbolos em C. Compare:

If (a < 15) Xor (b = 2) And Not Condition Then

para

if ((a < 15) ^ (b == 2) && !Condition())

Isso não significa que um idioma seja melhor que outro.

Editar: -----------------------------------------

Para o argumento VB seria propenso a erros. Quando você usa Option Strict On, é tão rigoroso quanto o C #, mas não nos permite cometer tais erros:

// VB would initialize with zero (C/C++ doesn't)
int countZeros;
// No confusion with loop bounds with For x = 1 To Length
for (int i = 1; i <= length; i++) {
    // Never confusing == with = 
    if (data[i] = 0) 
        countZeros++;
}
Dario
fonte
1
C # causaria um erro de compilação por não inicializar countZeros (no escopo local) e por atribuir um valor aos dados [i] na instrução if. Eu sei que você referenciada c / c ++ em seu comentário, mas acredito que o OP estava comparando VB para C # :)
1
Na minha opinião, o VB10 supera o C # 10 em grande momento!
Shimmy 25/05
Eu gosto de todas as línguas: LISP, C, VB, PHP, o nome dele.
systemovich
+1 e eu acrescentaria que a instrução Switch do VB não é inútil como a de C #.
Joel Brown
12

Historicamente, o ambiente de desenvolvimento do VB era uma maneira rápida e eficaz de criar certos tipos de aplicativos (por exemplo, aplicativos da GUI). Isso levou a ser uma escolha muito popular. Eu acho que o VB foi a linguagem mais usada durante o seu auge (por exemplo, VB6).

Com esse tipo de base instalada, não surpreende que ainda exista muito trabalho nele.

dommer
fonte
2
+1 AFAICS VB6 e especialmente o VS IDE fornecida uma (muito) baixa barreira à entrada que criou uma geração de novos codificadores, com todos os problemas e as possibilidades que
7

Tudo começou antes que o C # existisse

Em 1999, tínhamos o Visual Studio 5/6. Se você era um fornecedor independente de software ou uma empresa usando o Windows e precisava de um aplicativo escrito que pudesse, por exemplo, rastrear o tempo gasto pelos funcionários em projetos, você tinha algumas opções:

  1. Formulários no Visual Basic.
  2. MFC, ATL ou Win32 no Visual C ++.
  3. Formulários no Access 97/2000.
  4. Site ASP.
  5. Applet Java.

Naquela época, estávamos um pouco antes do estouro da bolha da Dot-Com, então qualquer um que fosse bom em (4) ou (5) saiu para negociar opções de ações em qualquer ponto-com incrível pela qual se sentisse atraído.

(3) teve problemas com bloqueio e escalabilidade geral, mas vi muitas soluções orientadas a acesso que seriam executadas como shell para executar as funções de suporte conforme necessário.

Então, isso nos deixa com VB e VC ++:

O editor de formulários no VB era, na época, excelente para produtividade. Você pode arrastar e soltar seus componentes - não apenas botões, etiquetas e caixas de texto, mas também a caixa de ferramentas completa 'OLE controls' de componentes reutilizáveis, como grades inteligentes, planilhas do Excel ou instâncias do IE. A conexão foi feita nos bastidores - tudo parecia um objeto e você clicou duas vezes nas coisas para adicionar manipuladores de eventos. Isso foi muito mais difícil no Visual C ++. Como membro da equipe de suporte ao desenvolvedor do Visual Studio na época, lembro como as chamadas de suporte do Visual Basic eram principalmente sobre qual componente era melhor usar ou como otimizar seu aplicativo de determinadas maneiras. Quase nunca foi 'como faço para fazer um aplicativo com os recursos da interface do usuário X, Y e Z'.

Criar uma interface do usuário rica no Visual C ++ era um desafio diferente. Embora houvesse suporte do editor Visual para diálogos e formulários SDI / MDI, ele era bastante limitado. O suporte para incorporar controles OLE (ActiveX) no MFC ou Win32 era uma arte negra, embora um pouco mais fácil no ATL. A instalação de coisas simples, como redimensionar eventos ou desenhar pelo proprietário, foi bastante dolorosa, sem falar nos pontos de conexão necessários para eventos personalizados nos componentes.

Sim, o VC ++ tinha velocidade de execução, capacidade de depuração e estruturas / bibliotecas / opções de interface do usuário flexíveis, mas o suporte ao IDE não podia cobrir todo esse terreno; portanto, abordou as operações mais comuns com coisas como Wizards, hierarquias abrangentes de classes MFC e 90 dias / 2 linhas de suporte para incidentes livres.

O IIRC, o empacotador de aplicativo fornecido com o VB pode empacotar seu aplicativo, o tempo de execução do VB e as DLLs de controles comuns mais recentes e fornecer a você um instalador EXE independente que você pode colocar em um CD e chegar aos clientes. Nada disso ', que msvcrtXX.dll e mfcxx.dll você instalou?', Que atormentou os desenvolvedores do MFC.

Portanto, por motivos de time-to-market e rica interface do usuário, o VB obteve muitos seguidores.

Quando o Visual J ++ e o Visual InterDev chegaram ao VS6, ficou claro que o IDE do Visual Basic havia vencido alguma batalha sobre o Visual C ++, o que era justo no IMHO. Não foi surpresa que o Visual Studio .NET tivesse um editor de formulários do tipo VB para a nova linguagem COOL C #.

A nova linguagem semelhante a Java / C / C ++, juntamente com o designer da interface do usuário apreciado pelo pessoal do VB durante todo esse tempo, deu um novo caminho de migração para o pessoal do C ++ que agora fazia o MFC / ATL / Win32. Para as pessoas VB 3/4/5/6 que não gostaram da falta de 100% de compatibilidade com versões anteriores no VB.net, isso ofereceu a oportunidade de aprender um novo idioma em um ambiente familiar.


Os motivos pelos quais o VB era um produto tão abrangente provavelmente têm algo a ver com as origens da Microsoft, sendo o Basic o principal produto para desenvolvedores, mas não tenho citações no momento.

JBRWilkinson
fonte
6

Por mais feio que qualquer linguagem possa ser, os motivos para segui-la geralmente se resumem a: é muito caro descartar uma enorme base de código e o fato de os desenvolvedores já conhecerem a linguagem torna mais barato o uso do que outras línguas.

Brian Rasmussen
fonte
6

O VB.NET é mais fácil de aprender, você está certo, e é mais fácil do que o C #, na minha opinião. É o primeiro ponto por que o VB é tão popular. Outro, e o maior ponto, eu acho, é que há uma enorme comunidade de desenvolvedores que trabalharam com o VB 6 e versões mais antigas dessa linguagem e é mais fácil para eles desenvolver aplicativos com o VB.net do que aprender um novo idioma.

iburlakov
fonte
6

Como já foi dito, seu julgamento estético sobre a sintaxe da linguagem depende muito do que você sabia antes. Por mais de uma década, parece ter sido um concurso semelhante a C, com chaves para "blocos", "->" para indireto (perl, php), parênteses para argumentos de chamada de função, // para comentários e um ponto e vírgula em cada extremidade da linha. Algumas pessoas até pensaram que, graças a essa "pensée única", se você conhece um idioma, conhece todos eles, o que é realmente ridículo. Mas isso instilou a idéia entre as pessoas de C ++ / Java, que é a única estética de sintaxe correta e qualquer outra coisa está tentando clonar COBOL.

Alguns anos atrás, mudei para ruby, e agora python, e não suporto mais pontos e vírgulas feias, chaves e outros caracteres sem sentido de lixo. O código fonte é para ser lido por humanos. Quando tentei o visual studio, escolhi VB em vez de c #. Eu suspeito que alguns programadores escolheram o C # apenas para "parecer sério" com sua sintaxe semelhante a java, mas vamos lá, os mesmos recursos estão lá ... dê um descanso aos seus olhos.

vincent
fonte
4

Bem, se você está falando sobre .NET, há uma realmente fácil que eu consigo pensar:

O editor do VB.NET no Visual Studio é muito melhor para capturar erros de sintaxe do que os c #.

Enquanto o editor do C # obteve uma grande melhoria no VS2008 SP1, ainda existem alguns erros de sintaxe que o editor não repara até que você tente compilar o programa.

Powerlord
fonte
Essa compilação em segundo plano é exatamente o que tornou a edição de grandes projetos VB no VS2005 muito muito lenta. Em qualquer caso, é o que ReSharper é para;)
Lucas
Não é apenas a compilação em segundo plano, as ferramentas de limpeza automática de código e formato corrigem muitas coisas antes mesmo de você sair do bloco para acionar a compilação. Esta é uma enorme economia de tempo em vb em comparação com c # #
## Bill
4

Grande parte da popularidade do VB se originou em uma época em que as ferramentas do VB eram muito mais amigáveis ​​do que outros idiomas disponíveis. O VB "clássico" ofereceu uma maneira fácil de criar aplicativos Windows sem ter que aprender a essência da API do Win32 ou se preocupar com o gerenciamento manual de memória. A barreira de entrada para programadores iniciantes era muito menor com o VB do que com o C ++, então muitas pessoas cortaram os dentes com o VB.

Atualmente, acho que uma vantagem do VB sobre o C # é a familiaridade para quem trabalhou com o VB ao longo dos anos. Outra vantagem é que o código VB é fácil de ler devido à tendência de usar palavras-chave em vez de símbolos de pontuação. Como alguém que trabalha em VB, Java, C, C # e Python, acho que o VB é a linguagem mais fácil para voltar ao revisar o código que escrevi anos atrás. A sintaxe é mais detalhada, o que geralmente facilita a leitura de código, e o Visual Studio sempre fez um ótimo trabalho de formatação do código VB para limpar a formatação enquanto você digita, para que o código seja formatado de forma consistente (independentemente da negligência do autor).

Como uma observação lateral, considero extremamente fácil ler e revisar o Python por razões semelhantes. No Python, a formatação do código é aplicada pelo intérprete, e não pelo IDE, mas o resultado final é o mesmo. O Python também favorece as palavras-chave à pontuação, embora seja indiscutivelmente menor que o VB.

gbc
fonte
3

Seria difícil argumentar que é mais ou menos "propenso a erros" do que qualquer outro idioma. Também duvido que o assunto seja "grande maioria da web comercial do MS"; pelo que vi, o C # está de longe assumindo a liderança no desenvolvimento do .NET (com o .NET sendo a principal ferramenta na pilha do MS para coisas que não são drivers de dispositivo etc.).

Marc Gravell
fonte
3

Uma vantagem que o VB.NET possui sobre o C # (que desaparecerá com o C # 4) é os parâmetros padrão e nomeados, uma coisa muito agradável de se ter ao usar o VSTO.

Blake Pettersson
fonte
E, nesse caso, "dinâmico" - dando ao C # algo comparável aos VBs existentes - ligação tardia / despacho.
Marc Gravell
1
Essa vantagem chamada sempre foi problemática para mim - minha leitura é que o C # tem sobrecargas, que são uma maneira mais segura de obter o mesmo resultado prático.
2
A desvantagem das sobrecargas é que elas são mais difíceis e confusas de manter quando você deseja definir alguns valores padrão. Você pode acabar com cadeias complexas de sobrecargas que o compilador chama no método aninhado, em vez de ser resolvido diretamente pelo método pelo compilador.
Matthew Whited
3

VB / VB.NET pertence à categoria RAD (Rapid Application Development). Você pode desenvolver aplicativos com apenas controles de arrastar e soltar da caixa de ferramentas e menos código.

NinethSense
fonte
Você poderia dizer o mesmo sobre a combinação ASP.net + C #, não?
Sim, a maioria dos idiomas baseados no Visual Studio faz.
Bem, na idade de VB (não .net) não havia C # etc. Então, VB era a única GRANDE coisa daquela época. Usuários posteriores do VB migraram para o VB.NET. VB <> VB.NET de qualquer maneira.
3

Bem, acho que você precisa diferenciar entre VB clássico e VB.NET.

Eu sinto que o VB.NET não é muito popular, mas o Visual Basic "Classic" ainda é1. O motivo é que é MUITO fácil criar um aplicativo do Windows. Compare isso com um aplicativo do Windows em C ++ / Mfc, que era quase a única alternativa no momento.

Pela mesma razão, Delphi era muito popular uma vez.

PhpFlashGuy
fonte
Concordo que o VB.net não é tão popular quanto o VB clássico. Alguns desenvolvedores que não puderam migrar sua base de código para o VB.net podem ter desertado para C #.
JBRWilkinson
3

O VB é muito detalhado e fácil de se acostumar em comparação com o C #, que diferencia maiúsculas de minúsculas. Para um programador iniciante, é o melhor ponto de partida.

chugh97
fonte
3

Para nomear alguns:

  • fácil de usar
  • nome familiar (básico foi uma das primeiras linguagens de programação de computador populares)
  • não subestime o marketing da microsoft
Toon Krijthe
fonte
3

Eu acho que parte do motivo é porque os programadores asp antigos que entram no .NET, como eu já conheci, já estão muito familiarizados com o VB porque o script VB é a linguagem que o ASP clássico é usado na maior parte do tempo. Eu senti menos tempo escrevendo VB no .NET porque eu já sabia falar VB. O VB também é menos chorão que o C #. Posso ler / escrever em ambos, mas prefiro o VB porque é fácil fazer amizade se você é um novo programador.

Eric
fonte
2

Eu trabalho em um ambiente onde usamos os dois. Mudamos para C # em favor do ASP e VB clássicos. Na minha opinião, não existem acordos entre os idiomas. Para a maioria dos projetos, você pode fazer o mesmo trabalho com os dois idiomas. Agora, compartilho sua opinião sobre propensão a erros e também acho o VB desorganizado (sem motivo).

Como outros já mencionaram, o VB é muito simples e, historicamente, você pode criar projetos muito rapidamente. Isso viveu no desenvolvimento da Web (que é desenvolvido rapidamente), mas acho que quando as pessoas percebem que o C # é tão rápido quanto o VB desaparecerá. Outro motivo pelo qual eu acho que vai desaparecer é que tudo o que você codifica (CSS, JavaScript) ao fazer aplicativos da Web parecer mais com C # que com VB, então faz sentido usar C #, mesmo para iniciantes.

miccet
fonte
2

Pessoalmente, gosto da maneira como os eventos são anexados no vb.net com a palavra-chave 'handle' ... O IDE / Visual Studio / também é mais responsivo ao lidar com o VB e manipula automaticamente a maioria dos end-ifs e similares ... C # é obviamente muito mais consenso e limpo (IMHO, eu trabalhei com os dois bastante)

Petar Kabashki
fonte
Prefiro me inscrever em eventos, nem todas as coisas mágicas nos bastidores que acontecem com "Handles" e o designer do VS.
2626 Lucas
2

Na estrutura 4.0, existem apenas algumas pequenas coisas que o VB carece em comparação com o C #, e o inverso também é verdadeiro. Nomeadamente:

  1. O mais notável é que o VB.NET não possui a Yieldpalavra - chave, mas em breve estará disponível no VB.NET com a nova estrutura assíncrona.
  2. Não há unsafepalavra-chave. Eu nunca achei necessário, mas certamente existem algumas pessoas que sim.
  3. Não há cadeias de linhas múltiplas. Cadeias de linhas múltiplas são realizadas usando operadores + (ou o legado &) nas linhas. Ou, eles podem ser realizadas usando o XML sintaxe literal: Dim s = <s>My string... multiple lines...</s>.Value. Não é bonito, mas se você não é exigente e realmente deseja strings de várias linhas, ele funciona. E você pode fazer uma interpolação de strings usando a <%= myVar %>sintaxe, o que é bom.
  4. Não há equivalente de escopo variável dynamic. Variáveis ​​dinâmicas existem no VB há muito tempo Option Compare Off, mas esse escopo é de arquivo, portanto não é tão bom quanto dynamicporque dynamiclimita o escopo apenas à variável declarada dessa maneira.
  5. O VB não possui uma sintaxe lambda concisa. Lambdas estão lá, mas você precisa usar Function(x)ou Sub(x).

Alguns recursos que o VB.NET possui que o C # não:

  1. Literais XML, que são úteis para todo tipo de coisa, não apenas XML.
  2. A distinção entre maiúsculas e minúsculas em um idioma é o miado do gato. Não são permitidos muitos outros idiomas, mas que diferença faz na velocidade da codificação para nunca ser necessário pressionar a tecla Shift ao digitar e o código é formatado automaticamente da maneira que você deseja.
  3. A Selectcláusula frequentemente desnecessária pode ser omitida das consultas do Linq.
  4. A Nothingpalavra-chave é muito mais útil do que nullem que tudo (mesmo tipos de valor) pode ser definido Nothinge você obtém o padrão. Não há necessidade da defaultpalavra - chave.
  5. O VB.NET é constantemente compilado no Visual Studio para que você veja erros imediatamente. Não é possível pressionar CTRL-SHIFT-B o dia inteiro como em C #.

Minha loja faz MVC3 com o Razor usando VB.NET e, uma vez que você supera os preconceitos (na maioria infundados), é realmente uma linguagem muito agradável de se usar. Não é realmente mais detalhado do que o C # como muitos afirmam (exceto no caso de lambdas), e é praticamente paralelo recurso a recurso com C #. Descobri que a maioria das pessoas que odeiam não codifica o VB.NET moderno há muito tempo.

mattmc3
fonte
Quanto a mim, o VB.NET é muito detalhado. Você precisa imprimir manualmente muitos códigos padrão, e o ReSharper não ajuda, na verdade. Eu tenho codificado em C # / VB.NET em paralelo por 3 anos já.
Hedin
O VB é de fato horizontalmente detalhado devido às palavras-chave mais longas. Embora você não os digite com frequência, porque o IDE os coloca para você. Mas o IMHO C # geralmente é verticalmente detalhado devido ao uso de chaves. Algumas outras vantagens do VB: evite debater o estilo de chave, porque há apenas um estilo no VB; (a língua entra na bochecha) evite desenvolver o dedo mindinho direito excessivamente musculoso devido à digitação interminável de ponto e vírgula e braçadeira.
MarkJ 9/08
1
@ MarkJ: Acho interessante a maneira como os proponentes do C # criticam AndAlso[não obstante, quando falados, é mais curto que o "e comercial duplo"], mas ignoram o fato de que um If-Then/Else/EndIfleva três linhas mais as instruções controladas, enquanto o equivalente em C # levaria pelo menos quatro e possivelmente seis, dependendo das convenções de chaves, a menos que alguém escreva } else {como uma única linha.
Supercat