it-swarm.it

Perché VB è così popolare?

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

Tuttavia, continuo a vedere (ciò che sembra essere) la stragrande maggioranza delle app web commerciali di "MS shops" 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é oggi VB/VB.net è così frequentemente utilizzato, specialmente nei progetti web?
28
aaaidan

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

47
Rick J

Penso che dipenda da dove vieni. Quando inizio come programmatore, penso che VB potrebbe essere più facile da leggere di C # per esempio, poiché si basa più sulle parole che sui simboli, il che rende più facile per accogliere persone normali.

Ero un VB per molti anni e quando arrivò .NET lavoravo ancora in VB.NET per i primi due anni (non vedevo davvero il punto con C #). Ora ho qualche anno di C # dietro di me e qualche volta trovo che il codice VB.NET impieghi un po 'più a "decodificare" rispetto al codice C # Forse perché si basa più sulle parole che sui simboli per alcuni contratti ...

42
Fredrik Mörk

Di seguito ho appena copiato il mio risposta a un'altra discussione :

Sviluppo in entrambi VB e C # su base regolare, la maggior parte del mio guadagno ha coinvolto C #. Personalmente, preferisco VB per la maggior parte (ma non tutto ... lambdas!) Non posso davvero nominare alcun vantaggio a parte quelli indicati da Jon. In realtà, Herfried ne ha raccolti alcuni sul suo sito web (in tedesco!) ma sono piuttosto tecnico.

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 spazio dei nomi My, non lo preferisco a causa dei letterali XML, non lo preferisco a causa della digitazione debole, non preferisco a causa di parametri opzionali o a causa dell'istruzione switch molto migliore. No, preferisco a causa della sintassi.


Detto questo, devo ammettere che VB diventa sempre più gravato dalla sua sintassi. L'ultimo hype sembra essere query Linq parametrizzate con funzioni lambda e ammetto prontamente che questo rende molte cose più semplice. Sfortunatamente, la sintassi di VB per lambdas è semplicemente troppo ingombrante per competere con C #. Considera solo quanto è gonfia una chiamata a Parallel.For appare come in VB - rispetto a C #, dove sembra naturale. IMHO, il team di progettazione VB è andato nella direzione sbagliata qui, favorendo il conservatore coerenza sulla 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 numero di elementi di sintassi C che sono oggettivamente più soggetto ad errori rispetto a qualsiasi cosa esistente in VB. In effetti, 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. Un codice ben scritto apparirà elegantemente in pratica, mentre un codice cattivo (lento, soggetto a errori) apparirà brutto. 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.

27
Konrad Rudolph

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 quei problemi mostrano anche le capacità di un programmatore rispetto a un altro.

(Spruzzo indiscriminato On Error Resume Next viene in mente come un modo non così buono per aggirare le carenze della mancanza di eccezioni in VB nei giorni precedenti .NET).

15
coobird

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 in 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) Di C # - Cast-Syntax e object as type Sono ancora più confusi e incoerenti.
  • Cosa c'è di male in with? È possibile creare strutture ad albero nidificate in modo molto intuitivo, cosa impossibile in C #.
  • Gestione degli eventi in VB è molto più elegante che in C #. È possibile introdurre e gestire gli eventi con una singola parola chiave (WithEvents) senza dover inizializzare delegati, eventhandler-procs ecc. Questo rende la programmazione della GUI in VB molto più comoda e non è necessario generare un codice evento dal designer .
  • I parametri opzionali vengono introdotti nel nuovo C # - Quindi sembrano essere buoni.
  • VB.NET ha entrambi operatori booleani rigorosi e di scelta rapida.
  • Tu do verifica la presenza di errori di sintassi al momento della compilazione, a meno che tu non esegua VB come un linguaggio di script.
  • End If è più utile del semplice }. Quando hai strutture sintattiche complesse, tutte le parentesi graffe creano confusione, mentre un End ... Concreto ti aiuta a determinare quale blocco non è stato chiuso.
  • XML Literals - 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 migliore sistema di eventi e un migliore IDE mentre ad esempio gli algoritmi possono essere espressi meglio in C # perché il 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 di stile usano VB.

Ma la sintassi VB più esplicita basata su Word potrebbe 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

per

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

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

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

All'argomento VB sarebbe soggetto a errori. Quando 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++;
}
13
Dario

Storicamente, il VB è stato un modo rapido ed efficace per creare determinati tipi di applicazioni (ad es. App GUI). Ciò ha portato a renderla una scelta molto popolare. Penso VB era la lingua più utilizzata durante il suo periodo di massimo splendore (ad es. VB6).

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

12
dommer

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 es. tenere traccia del tempo impiegato dai dipendenti per i progetti, c'erano 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 avrebbero eseguito Shell-out per eseguire le funzioni di supporto secondo necessità.

Quindi questo ci lascia con VB e VC++:

L'editor dei moduli in VB era, al momento, eccellente per la produttività. Potresti trascinare i componenti - non solo pulsanti, etichette e caselle di testo ma l'intera casella degli strumenti "Controlli OLE" di riutilizzabile componenti come Griglie intelligenti, fogli Excel o IE. Il collegamento è stato fatto dietro le quinte: tutto era come un oggetto e hai semplicemente fatto doppio clic su cose per aggiungere gestori di eventi. Questo è stato molto 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 certi modi. 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 OLE Controls (ActiveX) in MFC o Win32 era un'arte nera, anche se un po 'più facile in ATL. Cablare cose semplici come ridimensionare eventi o disegnare il proprietario era piuttosto doloroso, lascia che solo i punti di connessione richiesti per eventi personalizzati nei componenti.

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

IIRC, il packager dell'applicazione fornito con VB potrebbe impacchettare la tua app, il VB e le ultime DLL dei controlli comuni e fornirti un programma di installazione EXE autonomo che potrebbe 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 Visual Basic IDE aveva vinto un po 'di battaglia su Visual C++, che era giusto IMHO. Non è stata una sorpresa tutto ciò che Visual Studio .NET aveva un editor di moduli simile a VB per il nuovo [~ # ~] cool [~ # ~] linguaggio C #.

Il nuovo linguaggio simile a Java/C/C++ accoppiato al progettista dell'interfaccia utente apprezzato da VB persone 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 piaceva la mancanza di compatibilità con le versioni precedenti al 100% in VB.net, ciò offriva l'opportunità di imparare una nuova lingua in un ambiente familiare.


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

7
JBRWilkinson

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

6
Brian Rasmussen

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 che per imparare una nuova lingua.

6
iburlakov

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 a Ruby, e ora a Python, 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 su C #. Sospetto che alcuni programmatori abbiano scelto C # solo per "sembrare serio" con la sua sintassi simile a Java, ma dai, proprio le stesse caratteristiche ci sono ... dai agli occhi un po 'di riposo.

6
vincent

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 a 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.

4
Powerlord

Gran parte di VB è nata in un momento in cui gli strumenti di VB erano molto più amichevoli rispetto ad altre lingue disponibili. Il "classico" VB offriva un modo semplice per costruire Windows applicazioni 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 al C++, quindi molte persone si sono tagliate i denti con VB.

In questi giorni, penso VB un vantaggio rispetto a C # è la familiarità per coloro che hanno lavorato con VB nel corso degli anni. Un altro vantaggio è che VB è facile da leggere a causa della tendenza a usare parole chiave anziché simboli di punteggiatura. Come qualcuno che lavora in VB, Java, C, C # e Python, trovo che VB = è 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 VB codice 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 Python essere 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.

4
gbc

Per dirne alcuni:

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

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 MS commerciale"; 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.).

3
Marc Gravell

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.

3
chugh97

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

3
Blake Pettersson

VB/VB.NET appartiene alla categoria RAD (Sviluppo rapido di applicazioni). È possibile sviluppare applicazioni con i controlli di trascinamento della selezione dalla casella degli strumenti e meno codice.

3
NinethSense

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

Sento che VB.NET è non 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.

3
PhpFlashGuy

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

3
Eric

Lavoro in un ambiente in cui usiamo entrambi. Siamo passati a C # in favore di classic ASP e VB. Secondo me non ci sono interruzioni di contratto tra le lingue. Per la maggior parte dei progetti puoi fare lo stesso lavoro con entrambe le lingue. Ora lo faccio condividi la tua opinione sul rischio di errori e trovo anche VB da ingombrare (senza motivo).

Come altri hanno già detto, VB è molto semplice e storicamente potresti costruire progetti molto velocemente. Questo è sopravvissuto allo sviluppo web (che è rapidamente sviluppato), ma penso che quando le persone si rendono conto che C # è solo come sviluppato rapidamente, VB svanirà. Un'altra ragione per cui penso che svanirà è che tutto il resto in cui codifichi (CSS, JavaScript) quando si creano applicazioni web sembra più C # che VB, quindi ha senso usare C #, anche per i principianti.

2
miccet

Personalmente mi piace il modo in cui gli eventi sono collegati in vb.net con la parola chiave 'handle' ... Il IDE/Visual Studio/è anche più reattivo quando si tratta di 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)

2
Petar Kabashki

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

  1. Il più notevole è che VB.NET non ha la parola chiave Yield, ma arriverà presto su VB.NET con il nuovo framework asincrono.
  2. Non esiste una parola chiave unsafe. 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 eseguire l'interpolazione di stringhe usando la sintassi <%= myVar %> Che è piacevole.
  4. Non esiste un equivalente con ambito variabile di dynamic. Le variabili dinamiche sono in circolazione in VB da molto tempo con Option Compare Off, Ma questo è nell'ambito del file, quindi non è buono come dynamicbecause dynamic limita l'ambito alla sola variabile dichiarata in questo 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 clausola Select spesso non necessaria può essere omessa dalle query Linq.
  4. La parola chiave Nothing è molto più utile di null in quanto tutto (anche i tipi di valore) può essere impostato su Nothing e ottieni l'impostazione predefinita. Non è necessaria la parola chiave default.
  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 piacevole 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 davvero codificato nel moderno VB.NET per un certo periodo di tempo.

2
mattmc3