Perché VB è così popolare? [chiuso]

Per me Visual Basic sembra goffo, brutto, soggetto a errori e difficile da leggere. Lascerò spiegare agli altri perché . Mentre VB.net è stato chiaramente un enorme passo avanti per la lingua in termini di funzionalità, non capisco ancora perché qualcuno dovrebbe scegliere di scrivere codice in VB, ad esempio C #.

Tuttavia, vedo ancora (ciò che sembra essere) la stragrande maggioranza delle app web commerciali di "MS negozi" sono costruite in VB. Potrei essere corretto su questo, ma VB sembra ancora più popolare di quanto meriti.

Qualcuno può aiutare a rispondere a una (o tutte) queste domande:

• Mi sto perdendo qualcosa con VB? È più facile da imparare o "più amichevole" di C #? Ci sono funzionalità che non conosco?
• Perché VB / VB.net è così frequentemente usato oggi, specialmente nei progetti web?

VB può essere utilizzato per rendere la GUI (pronunciata appiccicosa) per tenere traccia degli indirizzi IP. Questo è spesso usato nella risoluzione del crimine .

Penso che dipenda da dove vieni. Quando inizi come programmatore, penso che VB potrebbe essere più facile da leggere rispetto a C # per esempio, dal momento che si basa più sulle parole che sui simboli, il che rende più facile accettare persone normali.

Sono stato un programmatore VB per molti anni e quando .NET è arrivato, ho ancora lavorato in VB.NET per i primi due anni (non vedevo davvero il punto con C #). Ora ho alcuni anni di C # dietro di me e qualche volta scopro che il codice VB.NET impiega un po 'più tempo a "decodificare" rispetto al codice C #. Forse perché si basa più sulle parole che sui simboli per alcuni contratti ...

Di seguito ho appena copiato la mia risposta in un'altra discussione :

Sviluppo regolarmente in VB e C #, la maggior parte del mio guadagno ha coinvolto C #. Personalmente, preferisco VB per la maggior parte (ma non per tutti ... i lambda!). Non posso davvero nominare alcun vantaggio a parte quelli delineati da Jon. In realtà, Herfried ne ha raccolti alcuni sul suo sito web (in tedesco!) Ma sono piuttosto tecnici.

La cosa che mi infastidisce davvero di tutto il linguaggio correlato alla C è la stupida sintassi. Questo è puramente culturale ma come qualcuno che svolge la maggior parte del suo lavoro professionale in C ++, ed essendo abbastanza abile in esso, odio ancora assolutamente la sintassi. E non solo piccole stranezze di C ++. No, l'intero pacchetto. Perché le parentesi graffe? Perché i punti e virgola (forse la decisione più stupida di tutta la storia della programmazione)? Perché la stupida sintassi del cast in stile C? Perché non esiste una parola chiave per la dichiarazione variabile (in realtà, questa è la decisione più stupida)?

Ci sono così tante cose che mi rendono davvero triste e arrabbiato. VB non è un santo, la sua lingua ha enormi svantaggi. Ma niente rispetto a quello che ho detto sopra.

Mi rendo conto che la maggior parte di queste affermazioni ha bisogno di giustificazione, ma ho sostenuto che ciò è dovuto al fatto che ci siamo abituati così tanto. Inoltre, qui non è il posto giusto. Basti dire che la sintassi di C #, pur essendo il suo principale vantaggio rispetto a VB, è anche il suo principale svantaggio.

Non preferisco VB a causa dello Myspazio dei nomi, non lo preferisco a causa dei letterali XML, non lo preferisco a causa della digitazione debole, non lo preferisco a causa di parametri opzionali o a causa del molto meglio switchdichiarazione. No, lo preferisco a causa della sintassi.

Detto questo, devo ammettere che VB diventa sempre più gravato dalla sua sintassi. L'ultima campagna pubblicitaria sembra essere una query Linq parametrizzata con funzioni lambda e ammetto prontamente che ciò semplifica molte cose. Sfortunatamente, la sintassi di VB per lambdas è semplicemente troppo ingombrante per competere con C #. Considera solo come Parallel.Forappare gonfia una chiamata in VB, rispetto a C #, dove sembra naturale. IMHO, il team di progettazione di VB ha preso la direzione sbagliata qui, favorendo la coerenza conservativa rispetto alla leggibilità.

Per rispondere alla tua accusa soggettiva:

Per me Visual Basic sembra goffo, brutto, soggetto a errori e difficile da leggere.

Hai certamente il diritto di pensarlo, ma come ha detto Marc sotto, ti sarà difficile discuterne obiettivamente. Posso sicuramente citare un certo numero di elementi di sintassi C che sono oggettivamente più soggetti a errori rispetto a qualsiasi cosa esistente in VB. In effetti, la sintassi VB è stata sviluppata per prevenire esplicitamente tali sedute.

"Goffo, brutto ... e difficile da leggere" sono tutti i qualificatori che possono essere taggati in quasi tutte le lingue con cui non si ha familiarità. In poche parole: la bruttezza è una conseguenza diretta della tua familiarità con la lingua.

Conoscere bene una lingua significa riconoscere gli schemi nel codice. Codice ben scritto sarà da Virtuel della pratica apparire elegante, mentre il cattivo (lento, soggetto a errori) apparirà brutto codice. E 'così semplice.

Un'ultima osservazione: gli articoli da te citati contengono diverse inesattezze e informazioni obsolete. Come unica giustificazione per una discussione altamente soggettiva ed emotiva, non sono molto adatti.

Per me Visual Basic sembra goffo, brutto, soggetto a errori e difficile da leggere.

Per me, l'inglese sembra goffo, brutto, soggetto a errori e difficile da leggere, specialmente scritto da persone che hanno scarsa grammatica, scarsa ortografia, disprezzo spericolato per capitalizzazione e punteggiatura e nessun senso di come organizzare i loro pensieri spazialmente e mentalmente.

Non è solo che Visual Basic è difficile da leggere o goffo a causa della sintassi del linguaggio, ma di solito è perché il programmatore non è davvero bravo a esprimere i propri pensieri:

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

Giusto, è orribile. Ma non è particolarmente difficile scrivere codice orribile in altre lingue. Se scritto correttamente, avrebbe molto senso anche se il codice è scritto in VB:

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

Almeno questo è più leggibile e comprensibile. È ancora BASIC. Dipende davvero dalla capacità del programmatore di esprimere chiaramente le sue intenzioni formattando il codice in modo facile da leggere, usando identificatori ben noti e prestando attenzione alla scrittura di codice comprensibile.

Detto questo, non ho più toccato Visual Basic dai tempi di VB3, (da qui l'esempio con la sintassi "vecchia"), ma solo perché una lingua può essere abusata non significa che non può essere utilizzata correttamente per scrivere codice abbastanza robusto . Certo, ci possono essere alcune carenze, ma gli approcci ideati per aggirare questi problemi mostrano anche le capacità di un programmatore rispetto a un altro.

(L'irrorazione indiscriminata On Error Resume Nextviene in mente come un modo non così buono per aggirare le carenze della mancanza di eccezioni in VB nei giorni precedenti .NET.)

La maggior parte delle tue argomentazioni contro VB è applicabile solo a VB-Classic (secondo collegamento) o basato su argomenti deboli o obsoleti

• Anche in VBC, non utilizzerai GoSub ... Return ecc.
• Cosa c'è che non va static? C ++ supporta anche questo.
• VB10 introduce la continuazione di riga implicita (non è nemmeno necessaria la semicola ridondante come C #)
• Le diverse funzioni di cast esistono anche in C ++ e C #. (object)(expr)-Cast-Syntax di C # e object as typesono ancora più confusi e incoerenti.
• Cosa c'è di male with? È possibile creare strutture ad albero nidificate in un modo molto intuitivo, cosa impossibile in C #.
• La gestione degli eventi in VB è molto più elegante che in C #. È possibile introdurre e gestire gli eventi con una sola parola chiave ( WithEvents) senza dover inizializzare delegati, processori di eventi, ecc. Questo rende la programmazione della GUI in VB molto più comoda e non è necessario generare un codice di eventi dal progettista .
• I parametri opzionali vengono introdotti nel nuovo C # - Quindi sembrano essere buoni.
• VB.NET ha entrambi operatori booleani rigorosi scelta rapida.
• Si fa a verificare la presenza di errori di sintassi in fase di compilazione a meno che non si esegue uno script VB come lingua.
• End Ifè più utile del semplice }. Quando si hanno strutture sintattiche complesse, tutte le parentesi graffe sono semplicemente confuse mentre sono concreteEnd ... ti aiuta a determinare quale blocco non è stato chiuso.
• Letterature XML: lo script XML è ora una parte del codice, completamente supportato da intellisense.

Tutto sommato, ci sono solo alcune differenze oggettive tra VB.NET e C # oltre alla sintassi. Ad esempio: la progettazione della GUI è molto più efficiente in VB a causa di un sistema di eventi migliore e di un IDE migliore, mentre ad esempio gli algoritmi possono essere espressi meglio in C # perché la sintassi è più concisa.

Il resto è solo una questione di stile personale. I programmatori C-Style si sentono a proprio agio con C #, VB (o forse Pascal?) - I programmatori Style usano VB.

Ma la sintassi VB più esplicita basata sulla parola può essere più facile da leggere per i principianti rispetto a tutti i simboli in C. Confronta:

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

a

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

Ciò non significa che una lingua sia migliore di un'altra.

Modificare : -----------------------------------------

Per l'argomento VB sarebbe soggetto a errori. Quando lo usi Option Strict Onè rigoroso come C # ma non ci consente di fare tali errori:

// 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++;
}

Storicamente l'ambiente di sviluppo VB è stato un modo rapido ed efficace per creare determinati tipi di applicazioni (ad es. App GUI). Ciò ha portato ad essere una scelta molto popolare. Penso che VB fosse la lingua più utilizzata durante il suo periodo di massimo splendore (ad esempio VB6).

Con quel tipo di base installata, non sorprende che ci sia ancora molto lavoro da fare.

Tutto è iniziato prima dell'esistenza di C #

Nel 1999, avevamo Visual Studio 5/6. Se eri un fornitore di software indipendente o un'azienda che utilizzava Windows e avevi bisogno di un'applicazione scritta che potesse, ad esempio, tenere traccia del tempo impiegato dai dipendenti in progetti, disponevi di alcune opzioni:

1. Moduli in Visual Basic.
2. MFC, ATL o Win32 in Visual C ++.
3. Moduli in Access 97/2000.
4. Sito Web ASP.
5. Applet Java.

All'epoca, eravamo appena prima dello scoppio della bolla Dot-Com, quindi chiunque fosse bravo con (4) o (5) è andato a negoziare opzioni su azioni in qualsiasi incredibile dot-com a cui erano attratti.

(3) ho avuto problemi con il blocco e la scalabilità generale, ma ho visto molte soluzioni basate su Access che si sarebbero sborsate per eseguire le funzioni di supporto secondo necessità.

Quindi questo ci lascia con VB e VC ++:

L'editor di moduli in VB era, all'epoca, eccellente per la produttività. È possibile trascinare e rilasciare i componenti: non solo pulsanti, etichette e caselle di testo, ma l'intera casella degli strumenti "Controlli OLE" di componenti riutilizzabili come griglie intelligenti, fogli Excel o istanze IE. Il collegamento è stato fatto dietro le quinte: tutto era simile ad un oggetto e hai semplicemente fatto doppio clic su cose per aggiungere gestori di eventi. Questo è stato molto più difficile in Visual C ++. In quel momento, come membro del team di supporto per gli sviluppatori di Visual Studio, ricordo come le chiamate al supporto di Visual Basic riguardavano principalmente quale componente era meglio usare o come ottimizzare la loro applicazione in determinati modi. Quasi mai "come faccio a creare un'applicazione con le funzionalità dell'interfaccia utente X, Y e Z".

La creazione di una ricca interfaccia utente in Visual C ++ è stata una sfida diversa. Sebbene esistesse il supporto dell'editor visuale per finestre di dialogo e moduli SDI / MDI, era piuttosto limitato. Il supporto per incorporare i controlli OLE (ActiveX) in MFC o Win32 era un'arte nera, anche se un po 'più facile in ATL. Cablare cose semplici come ridimensionare gli eventi o disegnare il proprietario è stato piuttosto doloroso, per non parlare dei punti di connessione richiesti per gli eventi personalizzati nei componenti.

Sì, VC ++ aveva la velocità di esecuzione, capacità di debug e framework / librerie / opzioni dell'interfaccia utente flessibili, ma il supporto IDE non poteva coprire tutto quel terreno, quindi ha affrontato le operazioni più comuni con cose come Wizards, gerarchie di classi MFC complete e 90 giorni / 2 linee di supporto per incidenti gratuiti.

IIRC, il packager dell'applicazione fornito con VB potrebbe impacchettare la tua app, il runtime VB e le più recenti DLL di controlli comuni e fornirti un programma di installazione EXE autonomo che potresti mettere su un CD e raggiungere i clienti. Niente di tutto questo "quali msvcrtXX.dll e mfcxx.dll hai installato?", Che ha afflitto gli sviluppatori MFC.

Quindi, per motivi di time-to-market e ricca interfaccia utente, VB ha ottenuto un seguito molto grande.

Quando Visual J ++ e Visual Interdev hanno colpito VS6, era chiaro che l'IDE di Visual Basic aveva vinto una battaglia su quello di Visual C ++, che era giusto IMHO. Non è stata affatto una sorpresa che Visual Studio .NET avesse un editor di moduli simile a VB per il nuovo COOL linguaggio C #.

Il nuovo linguaggio simile a Java / C / C ++ unito al progettista dell'interfaccia utente di cui le persone VB hanno goduto per tutto questo tempo ha dato un nuovo percorso di migrazione per le persone C ++ che ora avevano finito con MFC / ATL / Win32. Per le persone VB 3/4/5/6 a cui non è piaciuta la mancanza di compatibilità con le versioni precedenti al 100% in VB.net, ciò ha offerto l'opportunità di imparare una nuova lingua in un ambiente familiare.

Le ragioni per cui VB era un prodotto così completo probabilmente hanno qualcosa a che fare con le origini di Microsoft, con Basic come prodotto di punta per gli sviluppatori, ma al momento non ho citazioni.

Per quanto brutta qualsiasi lingua data possa essere la ragione per cui attenersi ad essa di solito si riduce a: è molto costoso scartare un'enorme base di codice e il fatto che gli sviluppatori conoscano già la lingua, lo rende più economico da usare rispetto ad altre lingue.

VB.NET è più facile da imparare, hai ragione, ed è nel complesso più facile di C #, secondo me. È il primo punto per cui VB è così popolare. Un altro, e il punto più grande, penso, è che esiste un'enorme comunità di sviluppatori che hanno lavorato con VB 6 e versioni precedenti di questo linguaggio ed è più facile per loro sviluppare applicazioni con VB.net piuttosto che imparare una nuova lingua.

Come altri hanno già detto, il tuo giudizio estetico sulla sintassi del linguaggio dipende fortemente da ciò che sapevi prima. Per più di un decennio, sembra che sia stato un contest C-look-like, con parentesi graffe per "blocchi", "->" per indiretta (perl, php), parentesi per argomenti di chiamata di funzione, // per commenti e un punto e virgola a ciascuna estremità della riga. Alcune persone hanno persino pensato che grazie a questa "pensée unica", se conosci una lingua, li conosci tutti, il che è davvero ridicolo. Ma questo ha instillato l'idea tra le persone C ++ / Java che è l'unica giusta sintassi estetica e qualsiasi altra cosa sta cercando di clonare COBOL.

Qualche anno fa sono passato al rubino, e ora al pitone, e non sopporto più brutti punti e virgola, parentesi graffe e altri personaggi insignificanti della spazzatura. Il codice sorgente è pensato per essere letto dagli umani. Quando ho provato a visual studio, ho scelto VB piuttosto che C #. Ho il sospetto che alcuni programmatori abbiano scelto C # solo per "sembrare seri" con la sua sintassi simile a Java, ma dai, le stesse caratteristiche sono lì ... Dai ai tuoi occhi una pausa.

Bene, se stai parlando di .NET, ce n'è uno davvero semplice a cui posso pensare:

L'editor di VB.NET in Visual Studio è molto più bravo nel rilevare errori di sintassi rispetto a quello di C #.

Mentre l'editor di C # ha ottenuto un enorme miglioramento in VS2008 SP1, ci sono ancora alcuni errori di sintassi che l'editor non rileva finché non si tenta di compilare il programma.

Gran parte della popolarità di VB ebbe origine in un'epoca in cui gli strumenti di VB erano molto più amichevoli rispetto ad altre lingue disponibili. Il VB "classico" offriva un modo semplice per creare applicazioni Windows senza dover imparare il coraggio dell'API Win32 o preoccuparsi della gestione manuale della memoria. La barriera all'ingresso per i programmatori principianti era molto più bassa con VB rispetto a C ++, quindi molte persone si sono tagliate i denti con VB.

In questi giorni, penso che VB un vantaggio rispetto a C # sia la familiarità per coloro che hanno lavorato con VB nel corso degli anni. Un altro vantaggio è che il codice VB è facile da leggere a causa della tendenza a utilizzare parole chiave anziché simboli di punteggiatura. Come qualcuno che lavora in VB, Java, C, C # e Python, trovo che VB sia il linguaggio più semplice in cui ripassare quando rivedo il codice che ho scritto anni fa. La sintassi è più dettagliata, il che rende spesso più semplice la lettura del codice e Visual Studio ha sempre fatto un ottimo lavoro di formattazione del codice VB per ripulire la formattazione durante la digitazione in modo che il codice sia formattato in modo coerente (indipendentemente dalla sciattezza dell'autore).

Come nota a margine, trovo che Python sia estremamente facile da leggere e rivedere per ragioni simili. In Python, la formattazione del codice è imposta dall'interprete piuttosto che dall'IDE, ma il risultato finale è lo stesso. Python favorisce anche le parole chiave alla punteggiatura, anche se probabilmente meno di VB.

Difficile sostenere che sia più o meno "soggetto a errori" rispetto a qualsiasi altra lingua. Dubito anche che il punto sia "la stragrande maggioranza della rete commerciale di Stati membri"; da quello che ho visto, C # è di gran lunga in testa allo sviluppo di .NET (con .NET come strumento di punta nello stack MS per cose che non sono driver di dispositivo, ecc.).

Un vantaggio che VB.NET ha su C # (che scomparirà con C # 4), sono i parametri predefiniti e nominati, una cosa molto bella da avere quando si usa VSTO.

VB / VB.NET appartiene alla categoria RAD (Rapid Application Development). È possibile sviluppare applicazioni con i soli controlli di trascinamento dalla casella degli strumenti e meno codice.

Bene, penso che devi distinguere tra VB classico e VB.NET.

Sento che VB.NET non lo è molto popolare, ma Visual Basic "Classic" è ancora1 Il motivo è che è MOLTO facile creare l'app di Windows. Confronta questo con un'app di Windows in C ++ / Mfc, che al momento era quasi l'unica alternativa.

Per lo stesso motivo, Delphi era molto popolare una volta.

VB è molto dettagliato e facile da usare rispetto a C #, che fa distinzione tra maiuscole e minuscole. Per un programmatore alle prime armi è il miglior punto di partenza.

Per dirne alcuni:

• facilità d'uso
• nome familiare (base era uno dei primi linguaggi di programmazione per computer popolari)
• non sottovalutare Microsoft Marketing

Penso che parte del motivo sia perché i vecchi programmatori asp che vanno in .NET come ho già fatto conoscono già VB perché lo script VB è il linguaggio ASP classico usato per la maggior parte. Ho sentito meno tempo a scrivere in VB in .NET perché sapevo già parlare VB. VB è anche meno di un piagnucolone di C #. Riesco a leggere / scrivere in entrambi ma preferisco VB perché è facile fare amicizia se sei un nuovo programmatore.

Lavoro in un ambiente in cui usiamo entrambi. Siamo passati a C # a favore di ASP e VB classici. A mio avviso, non esistono interruzioni di contratto tra le lingue. Per la maggior parte dei progetti puoi fare lo stesso lavoro con entrambe le lingue. Ora condivido la tua opinione sul rischio di errori e trovo anche VB ingombra (senza motivo).

Come altri hanno già detto, VB è molto semplice e storicamente potresti costruire progetti molto velocemente. Questo è sopravvissuto allo sviluppo web (che è sviluppato rapidamente), ma penso che quando le persone si renderanno conto che C # è altrettanto veloce, VB svanirà. Un altro motivo per cui penso che svanirà è che tutto il resto del codice (CSS, JavaScript) quando si creano applicazioni Web assomiglia più a C # che a VB, quindi ha senso usare C #, anche per i principianti.

Personalmente mi piace il modo in cui gli eventi sono collegati in vb.net con la parola chiave 'handle' ... L'IDE / Visual Studio / è anche più reattivo quando si ha a che fare con VB e gestisce automaticamente la maggior parte degli end-if e simili ... C # è ovviamente molto più semplice e pulito (IMHO, ho lavorato con entrambi abbastanza)

A partire dal framework 4.0, ci sono solo una manciata di cose che VB manca rispetto a C #, e anche il contrario è vero. Vale a dire:

1. Il più notevole è che VB.NET non ha la Yieldparola chiave, ma arriverà presto su VB.NET con il nuovo framework asincrono.
2. Non c'è una unsafeparola chiave. Non l'ho mai trovato necessario, ma sicuramente ci sono alcune persone che hanno.
3. Non ci sono stringhe multilinea. Le stringhe su più righe vengono realizzate utilizzando gli operatori + (o legacy &) su più righe. Oppure, possono essere realizzati utilizzando la sintassi letterale XML:Dim s = <s>My string... multiple lines...</s>.Value . Non è carino, ma se non sei esigente e vuoi davvero stringhe multilinea funziona. E puoi fare l'interpolazione di stringhe usando la <%= myVar %>sintassi che è buona.
4. Non esiste un equivalente con ambito variabile di dynamic. Le variabili dinamiche sono presenti in VB da molto tempo con Option Compare Off, ma questo è nell'ambito del file, quindi non è buono come dynamicperchédynamic limita l'ambito alla sola variabile dichiarata in quel modo.
5. VB manca di una sintassi lambda concisa. Le lambda ci sono, ma devi usare Function(x)o Sub(x).

Alcune funzionalità di VB.NET non supportano C #:

1. Letterali XML, utili per ogni genere di cose, non solo per XML.
2. L'insensibilità alle maiuscole in una lingua è il miagolio del gatto. Non molte altre lingue lo consentono, ma che differenza fa nella velocità della codifica di non dover mai premere il tasto Maiusc durante la digitazione e avere il codice semplicemente auto-formattato nel modo desiderato.
3. La Selectclausola spesso non necessaria può essere omessa dalle query Linq.
4. La Nothingparola chiave è molto più utile che nullin tutto ciò che è possibile impostare (anche i tipi di valore) Nothinge si ottiene l'impostazione predefinita. Non è necessario per la defaultparola chiave.
5. VB.NET viene costantemente compilato in Visual Studio in modo da visualizzare immediatamente gli errori. Non premere CTRL-MAIUSC-B tutto il giorno come in C #.

Il mio negozio fa MVC3 con Razor usando VB.NET e una volta superati i pregiudizi (per lo più infondati), in realtà è un linguaggio molto carino da usare. Non è davvero più prolisso di C # come molti sostengono (tranne nel caso di lambda), ed è praticamente parallelo a C #. Ho scoperto che la maggior parte delle persone che odiano non hanno realmente codificato in VB.NET moderno per un certo periodo di tempo.