VB.Net vs C # dibattito [chiuso]

Sono stato nei luoghi di lavoro in cui, all'inizio di un progetto, è stata sollevata la domanda "Dovremmo usare VB.Net o C #".

Certo, è probabilmente meno comune dover prendere quella decisione ora di quanto non fosse nei primi giorni di .Net, in particolare vista la tendenza verso la convergenza linguistica, ma può ancora essere un acceso dibattito.

Quindi, tra VB.Net e C #, quale lingua preferisci e perché?

Preferisco C # su VB.NET perché

• è più facile trovare programmatori / lavori:

• è più facile trovare aiuto:

^{(da StackOverflow)}

Odio VB.NET. I giorni che trascorro ancora ad usarlo sono i giorni di cui mi pento. Detto questo, i miei gusti sono parte della mia situazione ed esperienza e non hanno necessariamente alcuna rilevanza per quello che stai facendo ...

Penso che sia importante, quando si confrontano linguaggi in continua evoluzione come C # e VB.NET, guardare indietro alla loro storia e vedere come sono arrivati ​​al loro stato attuale:

I vantaggi originali di BASIC sui microcomputer includevano dimensioni e semplicità (sintassi piccola e facile da analizzare creata per interpreti piccoli e ragionevolmente veloci e spazio in memoria per il programma e i dati effettivi), un ambiente interattivo che consentiva la sperimentazione e una sintassi che ha evitato simboli e strutture concisi per una sintassi ragionevolmente chiara, simile all'inglese. Era scarsamente adatto per programmi grandi e strutturati e tendeva a incoraggiare il codice spaghetti. Tuttavia, la sua disponibilità e semplicità lo hanno reso un'ottima scelta per un'introduzione alla programmazione.

QuickBasic ha aggiornato la sintassi per consentire programmi di grandi dimensioni più strutturati e ha aggiunto la compilazione per un'esecuzione più rapida.

VisualBasic ha fornito un form builder potente e facile da usare per consentire la costruzione rapida di applicazioni GUI, adottando la sintassi QB per l'uso nello scripting di queste interfacce utente. Funzionava meglio se usato per creare interfacce utente per la logica di basso livello fornite come componenti predefiniti (di solito scritti in un'altra lingua). Nel tempo, la sintassi divenne sempre più ampia e incoerente man mano che venivano messe a punto nuove funzionalità. L'attenzione sulla redazione di una UI prima e poi sulla compilazione di frammenti di script ha funzionato bene per le piccole app centrate sull'interfaccia utente, ma tendeva a incoraggiare la programmazione di copia e incolla e una variazione sul codice spaghetti mentre scoraggiava il riutilizzo, strutture di dati complesse e separazione degli interessi. Nella mente di molti, "codice VB" divenne sinonimo di "grande palla di fango"; "Programmatore VB" con "hack inesperto".

VB.NET è un linguaggio simile a VB sulla piattaforma .NET, un tentativo (non del tutto riuscito) di ripulire e modernizzare la sintassi VB troppo cresciuta. Non era perfettamente compatibile con il codice VB esistente e non ha fatto alcuno sforzo per fornire la compatibilità con i moduli VB (probabilmente la parte più importante di VB). Ciò ha lasciato molti proprietari di prodotti VB con la spiacevole scelta di riscrivere efficacemente le loro applicazioni in VB.NET (gestendo sottili incompatibilità in ogni routine che non è stata attentamente esaminata) o in realtà riscrivendo le loro applicazioni in C # (trattando con un non familiare sintassi in aggiunta ala nuova libreria di runtime e designer di moduli). La maggior parte degli utenti di VB.NET erano utenti VB che lo utilizzavano solo per la sintassi, molti lo usavano come stampella mentre imparavano C #. Di conseguenza, ha subito acquisito la reputazione di paradiso per i programmatori che si erano bloccati nei loro modi, non disposti o incapaci di espandere o migliorare le proprie abilità.

A questo punto, VB.NET continua a evolversi, perdendo lentamente bagaglio mentre raccoglie sintassi nuova e interessante (LINQ, letterali XML). Tuttavia, non conserva quasi nessuno dei vantaggi originali di BASIC: è un linguaggio ampio e complesso con una curva di apprendimento piuttosto ripida e opportunità limitate di sperimentazione interattiva.

• Per i vecchi programmatori che lo hanno bloccato negli ultimi 30 anni, non è una cattiva scelta, a condizione che non si limitino ad esso.
• Per i nuovi programmatori, la somiglianza sempre più vaga dei programmi VB con l'inglese non vale la pena fare un cenno bizzarro alla retrocompatibilità e allo stigma sociale.
• Per i nuovi progetti , VB.NET è una scelta strana a meno che il progetto non sia fortemente coinvolto in una delle poche attività per cui il linguaggio è ottimizzato: integrazione con componenti COM di scarsa qualità (Office ...) (sebbene C # 4.0 riduca notevolmente questo vantaggio ) o generazione XML inline.

Conosco entrambi, ma ho fatto molto del mio lavoro di programmazione iniziale in VB4, VB5 e VB6. Ora che entrambe le lingue in .NET hanno attraversato alcune iterazioni e sono confluite un po 'nelle loro capacità, penso che il dibattito sia decisamente stupido, molto simile a "qual è il tuo colore preferito".

Personalmente, mi piacciono entrambi per motivi diversi.

VB.NET
Molte persone parlano di come la sintassi di C # sia più intuitiva, ma che è molto soggettiva e fortemente basata su ciò che hai iniziato a sapere. Direi che se tu fossi completamente obiettivo la sintassi VB.NET è probabilmente più intuitiva se non assumi una conoscenza precedente in un'altra lingua. Ad esempio, dato lo stesso programma in C # e VB.NET che ritieni possa essere più decifrabile per qualcuno che non ha conoscenza della programmazione. Mi sembra piuttosto chiaro.

L'altra cosa interessante di questa sintassi è che è molto più esplicito sulla chiusura delle strutture (END IF, END WHILE, NEXT X) rispetto al modello di bracketing. Rende il codice un po 'più leggibile e spesso consente al compilatore di essere più preciso in quale numero di riga causa esattamente errori di compilazione. Se sei mai andato a caccia di parentesi / punti e virgola mancanti a causa di un errore del compilatore a 50 righe di distanza dal problema, sai cosa intendo.

Inoltre, nella colonna delle vincite VB.NET, a mio avviso, è la mancanza di == / = come operatori di confronto / assegnazione. I rari vantaggi di avere un operatore distinto per ciascuno non compenseranno mai tutti i problemi (a volte) difficili da scoprire che aiuta a creare.

Infine, odio la distinzione tra maiuscole e minuscole nei linguaggi di programmazione. Una delle lamentele su VB è che ha così tanto bagaglio, ma C # ha portato avanti l'albatro della sensibilità del caso C. Non sono mai stato in una situazione in cui volevo che due identificatori nello stesso ambito differissero solo per caso. È solo un lavoro intenso e mi rallenta. VB.NET ottiene alcuni punti su C # in questo senso per me.

I
programmatori C # adorano essere concisi, motivo per cui penso che in genere favoriscano questa sintassi. Ha solo un certo fascino estetico. Tuttavia, da una prospettiva completamente pratica, mi piace perché è così simile a linguaggi come Java, JavaScript e C ++.

Dato che faccio molto sviluppo web che richiede sia la programmazione lato server che quella lato client, trovo più facile passare mentalmente tra C # e JavaScript come spesso mi viene richiesto.

Inoltre mi piace il fatto che, per la maggior parte, che se dovessi mai passare alla programmazione Java o C ++, avrei un po 'di vantaggio se usassi C # la maggior parte delle volte.

Preferisco la sintassi del bracketing dei linguaggi in stile C rispetto alla sintassi più "dettagliata" dei linguaggi in stile BASIC.

La mia introduzione alla programmazione è stata con Turbo Pascal. (La parte della programmazione BASIC che ho fatto sul Commodore 64, da bambino, non conta davvero.) Dopo aver appreso Java non ho mai guardato indietro e ho preferito la sintassi in stile C.

Funzionalmente sono gli stessi, non c'è niente che tu possa fare in uno che non puoi fare nell'altro, e per il futuro Microsoft ha promesso che i team linguistici si svilupperanno entrambi in modo uniforme, quindi è improbabile che questa equivalenza cambi.

Le differenze ora sono puramente culturali e personali. Questo articolo è interessante da leggere sulle differenze tra le culture dei programmatori che usano C # e VB.net

_{[Nota: sebbene io stesso sia un sviluppatore C #, la conclusione dell'articolo collegato non riflette necessariamente la mia opinione personale, è solo un interessante approccio alternativo nel dibattito]}

Sono arrivato a .NET da C e C ++ (con un po 'di Java, Ada e Pascal inseriti) quindi C # è stata la naturale progressione per me.

Se arrivasse un lavoro che richiedeva VB.NET, certamente non lo rifiuterei.

Ho lavorato molto con VB.NET, ma ho capito abbastanza C # per capire cosa sta succedendo nel codice. La mia attuale preferenza è VB.NET perché ne ho più familiarità (ovviamente), ma in realtà non ho una preferenza tra sintassi BASIC verbosa e sintassi in stile C, entrambe sono molto leggibili e comprensibili per me.

Gran parte del background di programmazione del mio collega è COBOL e VB6, quindi VB.NET è stata la scelta del linguaggio .NET più comoda per noi come squadra. Non c'era una solida ragione per noi che rendesse l'apprendimento di C # un requisito dal momento che funzionalmente erano uguali.

Detto questo, imparare C # è sicuramente nella mia lista di cose da fare.

Preferisco C #.

Ho iniziato come programmatore VB.NET ma con il passare del tempo è diventato ovvio che molte nuove funzionalità stanno arrivando prima in C # e poi in VB.NET (ad es. Proprietà automatiche). E la comunità che circonda C # è molto più vivace di quella di VB.NET.

Inoltre, se hai intenzione di imparare Java o un linguaggio simile, C # è il punto di partenza migliore: la sintassi è quasi la stessa in tutti i linguaggi derivati ​​da C. Anche se questo non sarebbe un punto di svolta per me poiché la sintassi è qualcosa che puoi comunque imparare rapidamente.

Oltre alle altre risposte pubblicate qui, sceglierei C # su VB perché i programmatori C # vengono pagati di più. Più esperienza con C # = più $$ :)

So che entrambe le lingue sono quasi uguali ed è davvero facile passare da una all'altra, ma penso che quando il management guarda un gruppo di parentesi graffe e punti e virgola accetti il ​​fatto che stiamo facendo qualcosa che non possono fare, dove con VB. Net potrebbero guardarlo e dire "oh, non può essere così difficile da fare se riesco a capirlo".

C # perché posso passare da esso a Java con il minimo sforzo

VB.NET è una sintassi completamente diversa. C #, essendo simile a Java e ad altre lingue, mi dà una posizione migliore per adattarmi rapidamente a cose nuove. Poiché l'output di C # e VB.NET sono praticamente intercambiabili, ha senso andare con C #. Inoltre, se il codice della tua azienda è in C #, è più probabile che tu possa addestrare uno sviluppatore Java a codificare C # rispetto a uno sviluppatore Java VB. Ci sono solo vantaggi sottili, ma sottile è ancora un vantaggio.

Mettendo da parte le mie preferenze personali. Come qualcuno che sta reclutando (e cercando di essere reclutato) ultimamente, quando abbiamo avuto questo dibattito in ufficio il consenso generale è stato che dovremmo cercare di passare a C # da VB.

Perché? Perché C # era più diffuso nel mercato (comunque intorno a noi), permettendoci di reclutare più facilmente e di essere reclutati più facilmente.

Sembra che sia andato al punto di partenza; la gente impara C # perché i recruiter lo vogliono, perché ci sono più candidati.

Essendo un dev un po 'più vecchio (ha 59 "un po'" più vecchio?), Ho imparato BASIC prima su un Commodore VIC-20, mi sono insegnato Turbo Pascal (v1!), Ho continuato a studiare COBOL al college e ho trascorso 14 anni a sviluppare su IBM mainframe, con brevi deviazioni che scrivono app di medie dimensioni in Revelation BASIC (una variante di PICK BASIC) e alcune utility in Modula-2, prima di passare a VB5 e VB6. E poi è arrivato .NET.

A causa del mio background di base, ho pensato di iniziare con VB.NET, solo per scoprire che continuavo a provare a fare le cose alla "vecchia maniera" e mi stava facendo impazzire (okay, più impazzito). Essendo che avevo fatto un po 'di lavoro in C, ho pensato di dare un giro a C # per vedere come è andata. E OMG, è stato come uscire da un tunnel buio alla luce del giorno! Totalmente inaspettato. E facevo rumori denigratori sul fatto che C fosse un linguaggio "di sola scrittura" - "così difficile da capire che un programmatore C non riusciva a capire cosa facesse il suo codice 6 mesi dopo averlo scritto", un'osservazione fatta da romanziere semi-famoso che pensavo suonasse carino in quel momento.

Quindi, in virtù del fatto di non avere familiarità con C, C # è stato paradossalmente più facile per me imparare la programmazione .NET rispetto al paradigma di base molto più familiare. Mi piace ancora VB6, ma ho imparato ad amare C #. Il miglior linguaggio di programmazione sul pianeta.

Sviluppo in Visual Basic .Net dal 2001 e lo adoro e lo odio !!!

L'ordine di presentazione di questi punti si basa solo sull'ordine in cui mi è venuto in mente ...

In vb.net con Visual Studio, c'è un'interruzione di linea visiva tra ogni metodo, proprietà. Per molte persone, non è un buon motivo per preferire vb.net a c # ma non capisco perché il team c # di Microsoft non lo abbia implementato. C'è un componente aggiuntivo che traccia questa linea in c # ma grazie ancora Microsoft per avere un team ac # e un team di Visual Basic che non parlano tra loro.

In vb.net, quando crei un winform, hai due combobox in visual studio nella parte superiore dell'editor e puoi generare automaticamente un evento quando selezioni un evento nel combobox giusto. Quando alleghi dozzine di eventi ogni giorno, può essere molto complicato non avere questa funzione. Con c #, hai un piccolo pulsante nella parte superiore della griglia delle proprietà che può generare eventi ma non è veloce come in vb.net. Inoltre, se si allega un evento di controllo in c # e si elimina il controllo nel modulo, il delegato creato sul codice generato automaticamente per gestire l'evento deve essere eliminato manualmente. Grazie ancora Microsoft.

In vb.net, quando si tenta di modificare un metodo che contiene una query linq senza modificare la query stessa, nessun problema, ma in c #, tutto il codice del metodo viene bloccato. Se hai molte query linq o espressioni lambda, la funzione modifica e continua sarà rapidamente una buona vecchia cosa. Ok, un po 'di esagerazione ... ma :)

In vb.net, quando si crea un nome di metodo e si tocca invio, "end sub" verrà automaticamente creato. In c #, fallo da solo. Ok, se hai installato resharper o devexpress, sarà meglio, ma perché tutte queste piccole ma grandi funzionalità non sono state implementate in c #.

In vb.net, quando si hanno errori sul codice, gli errori vengono visualizzati automaticamente e quando lo si corregge, questi errori vengono rimossi dallo stack in tempo reale. In c #, devi costruire il tuo progetto per capire che hai corretto con successo o meno gli errori specificati. Perché il team c # non ha messo un'opzione per verificare in tempo reale l'errore come in vb.net. Con una grande soluzione, nessuna verifica in tempo reale dell'errore può essere una bella ottimizzazione delle prestazioni, ma adoro vedere sparire una serie di errori mentre lo correggo.

Come altri hanno già detto, penso che sia più facile leggere le condizioni di vb.net se..end if, seleziona caso ... fine seleziona ma con la staffa di pittura devexpress, dimentica quello che ho detto.

Con vb.net, ci sono molti molti bug in Visual Studio. Solo per citarne uno in Visual Studio 2010, gli intellettuali non filtrano correttamente l'enumerazione se hai attivato la modalità "comune" anziché "tutto".

Con vb.net, sei percepito come un ragazzo fittizio perché staticamente, i programmatori più cattivi usano vb.net invece di c # perché c # è più difficile da imparare e promuovere migliori pratiche di programmazione.

Come altri hanno detto, il programmatore c # ha maggiori possibilità di avere un buon lavoro con più soldi.

Nella testa del cliente, vb.net = ragazzo che programma nel suo seminterrato con un buco di spaghetti di codice. c # = wow, sei molto intelligente. Il fatto è che non è perché programmi in c #, che fai un buon programma ma staticamente sì.

Con tutti questi punti, ho scelto di convertire tutto il mio codice vb in c #. Programmo con tutte le migliori pratiche di orientamento agli oggetti, modello di progettazione, codice pulito con standard e sintassi rigorosa e posso programmare così per 50 anni, ma agli occhi della comunità non sono un buon programmatore. Convertirò il mio codice in c # senza altre best practice e sarò un'altra persona; un ragazzo eccezionale che devi rispettare ..... :( che barzelletta ... !!! ma è la realtà.

Ecco un modo di vederlo: tra SO e CodePlex, quale lingua è più popolare? C # o VB.Net?

A volte, seguire la mandria è una buona cosa perché è la mandria che sarà in grado di aiutarti quando ne hai bisogno. Per impostazione predefinita, C # sarà più veloce di Vb.Net. Credo che usare Option Strict potrebbe uguagliarlo. L'ultima volta che ho confrontato IL tra i due, la sicurezza di tipo VB.Net ha finito per aggiungere circa il 15% in più a IL. Questo si traduce in costi aggiuntivi. E ... date le lingue che fanno sostanzialmente la stessa cosa, prenderò quella più veloce. La mia praticità non dovrebbe prevalere sull'esperienza del mio utente in generale.

Mi piace dire che l'unica ragione per cui BASIC è ancora popolare è che è stato il primo prodotto di Microsoft e lo stanno spingendo in gola da 35 anni. Sarebbe dovuto morire molto tempo fa.

Detto questo, ho lavorato su due considerevoli progetti .NET ed entrambi sono stati realizzati con VB.Net, anche se c'era un po 'di C # perché o la traduzione era una cagna o il costrutto non esisteva in VB.Net. L'unico vantaggio che vedo con VB.Net è che l'editor di Visual Studio è molto più amichevole (in base alla mia esperienza) di quanto non lo sia con C # - Intellisense sembra migliore, così come la formattazione automatica (nota che da quando non ho usato C # per quanto mi possa mancare qualcosa nella configurazione dell'IDE ...)

Uno svantaggio principale di VB.Net è che hanno portato molta merda nell'era VB6 nel .NET 1.x per facilitare la conversione del codice VB6. Quella roba è ancora lì dentro, e i programmatori VB6 stanno codificando il nuovo codice usando quelle ... "estensioni" piuttosto che usare le classi / metodi / qualunque cosa .NET più neutrali. Non so quante volte ho chiesto al mio capo perché ha ancora usato quella merda. "Ma ... Funziona ..." Giusto. Ehi, mi piace fare la cagna.

Mentre cercavo aiuto sul web, ho scoperto che la stragrande maggioranza delle soluzioni erano in C # - controlla i forum MSDN, vari blog, ecc ... I libri hanno la tendenza a concentrarsi su C #, e se esiste una versione VB, di solito arriva dopo mesi (ad es. Pro LINQ .... di Apress.)

Molti linguaggi condividono l'antenato C, il che rende molto più semplice il passaggio tra C, C ++, C #, Java, PHP e alcuni altri. PHP è un po 'allungato qui, ma ha molti costrutti simili a C. VB? Bene, è praticamente la sua piccola cosa e basta.

Un capo progetto nella mia organizzazione mi ha recentemente detto che sempre più nuovi progetti vengono sviluppati usando C # invece di VB - FINALMENTE. Quando .NET è stato introdotto nella nostra organizzazione, più o meno ufficialmente è andato con VB.Net a causa di tutta la codifica VB6 che era già in corso. I poteri che in seguito mi hanno ammesso che quella non era la loro mossa migliore.

Come ha sottolineato qualcun altro, non direi di no a un progetto VB.Net, ma spero ancora che venga lentamente sradicato dal nuovo sviluppo nel mio posto di lavoro.

Bene, oggi c'è poco o nessun motivo reale per usare VB.net. All'inizio era solo un modo per dare ai programmatori VB una sintassi familiare, ma era essenzialmente un remapping di C # simile a BASIC. Quindi il suo unico vero vantaggio è una sintassi più familiare, e la sua sintassi BASIC è anche il suo vero limite.

Nel tempo le due lingue si sono evolute parallelamente, l'unica differenza significativa è la my pseudo spazio dei nomi.

Consiglierei a tutti i programmatori .net che non hanno familiarità con C # di apprenderlo, poiché la comunità è abbastanza più grande e la sintassi simile al C è comune alla maggior parte delle lingue più utilizzate.

VB la lingua è più facile da leggere per i neofiti, tendono a scrivere la loro prima, seconda e terza applicazione e sappiamo tutti come sono codificate le nostre prime applicazioni - terribilmente.

I programmatori da C ++, Java ed ecc. Sono passati a C # mentre gli sviluppatori VB.NET provengono da background VBA, VB e BASIC, programmatori essenziali non tradizionali.

Sembra che ci siano più esempi di codice C # online che campioni VB.NET. Non è così difficile convertirsi l'uno nell'altro, ma perché preoccuparsi se non è necessario.

Preferisco VB .Net rispetto a C #,

• (97) ...
• (98) perché ho imparato VB prima ancora di conoscere C #.
• (99) perché ho già acquistato un tomo di 10.000 pagine su VB .Net.
• (100) perché VB non ha parentesi graffe.
• (101) perché tutti odiano VB.

C #. È solo perché ho fatto C e Java, quindi sento che C # è più leggibile per me. C # è per me, come VB.NET è per gli ex programmatori VB.