Pourquoi est VB si populaire?
Pour moi, Visual Basic semble maladroit, laid, sujet aux erreurs et difficile à lire. Je laisserai les autres expliquerpourquoi . Alors que VB.net a clairement été un énorme bond en avant pour le langage en termes de fonctionnalités, je ne comprends toujours pas pourquoi quelqu'un choisirait de coder en VB sur, disons, C #.
Cependant, je vois toujours (ce qui semble être) la grande majorité des applications Web commerciales des "boutiques MS" sont construites en VB. Je pourrais me corriger sur ce point, mais VB semble toujours plus populaire qu'il ne le mérite.
Quelqu'un peut-il aider à répondre à l'une (ou à toutes) ces questions:
- Suis-je en train de manquer quelque chose avec VB? Est-il plus facile à apprendre ou "plus convivial" que C #? Y a-t-il des fonctionnalités que je ne connais pas?
- Pourquoi VB/VB.net est-il si fréquemment utilisé aujourd'hui, en particulier dans les projets Web?
VB peut être utilisé pour créer des interfaces graphiques (prononcées gluantes) pour suivre les adresses IP. Ceci est souvent utilisé dans résolution de crimes .
Je pense que cela dépend d'où tu viens. Au début en tant que programmeur, je pense que VB pourrait être plus facile à lire que C # par exemple, car il s'appuie plus sur des mots que sur des symboles, ce qui le rend plus facile pour accueillir des gens ordinaires.
J'étais un programmeur VB pendant de nombreuses années et quand .NET est arrivé, je travaillais toujours dans VB.NET pendant les deux premières années (je n'ai pas vraiment vu le point avec C #). Maintenant, j'ai quelques années de C # derrière moi et je trouve parfois que le code VB.NET me prend un peu plus de temps pour "décoder" que le code C #. Peut-être parce qu'il s'appuie plus sur les mots que sur les symboles pour certains produits ...
Ci-dessous, je viens de copier mon réponse à un autre fil :
Je développe dans les deux VB et C # sur une base régulière, la plupart de mes revenus ont impliqué C #. Personnellement, je préfère VB pour la plupart (mais pas tous… des lambdas!) Je ne peux pas vraiment citer d’avantages en dehors de ceux décrits par Jon. En fait, Herfried en a rassemblé quelques-uns sur son site web (en allemand!) mais ils sont plutôt technique.
La chose qui me dérange vraiment dans tous les langages liés au C est la syntaxe stupide. C'est purement culturel mais en tant que quelqu'un qui fait la plupart de son travail professionnel en C++, et étant assez compétent dans ce domaine, je déteste toujours la syntaxe. Et pas seulement les petites bizarreries de C++. Non, tout le package. Pourquoi des accolades? Pourquoi les points-virgules (peut-être la décision la plus stupide de toute l'histoire de la programmation)? Pourquoi la stupide syntaxe de cast de style C? Pourquoi n'y a-t-il pas de mot-clé pour la déclaration de variable (en fait, ceci est la décision la plus stupide)?
Il y a tellement de choses qui me rendent vraiment triste et en colère. VB n'est pas un saint, son langage a d'énormes inconvénients. Mais rien comparé à ce que j'ai dit plus haut.
Je me rends compte que la plupart de ces déclarations doivent être justifiées, mais j'avance que c'est uniquement parce que nous nous y sommes habitués. De plus, ce n'est pas le bon endroit. Il suffit de dire que la syntaxe de C #, tout en étant son principal avantage sur VB, est également son principal inconvénient.
Je ne préfère pas VB à cause de l'espace de noms My, je ne le préfère pas à cause des littéraux XML, je ne le préfère pas à cause d'un typage faible, je ne Je ne le préfère pas à cause de paramètres optionnels, ou à cause de la bien meilleure instruction switch. Non, je le préfère à cause de la syntaxe.
Cela dit, je dois admettre que VB devient de plus en plus encombré par sa syntaxe. Le dernier battage médiatique semble être des requêtes Linq paramétrées avec des fonctions lambda et j'admets facilement que cela fait beaucoup de choses Malheureusement, la syntaxe de VB pour les lambdas est tout simplement trop lourde pour rivaliser avec C #. Considérez simplement à quel point un appel à Parallel.For ressemble à VB - par rapport à C #, où il semble naturel. À mon humble avis, l'équipe de conception VB est allée dans la mauvaise direction ici, privilégiant les conservateurs) cohérence sur la lisibilité.
Pour répondre à votre accusation subjective:
Pour moi, Visual Basic semble maladroit, laid, sujet aux erreurs et difficile à lire.
Vous avez certainement le droit de le penser, mais comme Marc l'a dit ci-dessous, vous aurez du mal à argumenter cela objectivement. Je peux certainement citer un certain nombre d'éléments de syntaxe C qui sont objectivement plus sujet aux erreurs que tout ce qui existe dans VB. En fait, la syntaxe VB a été développée pour empêcher explicitement de telles situations.
"Maladroit, laid… et difficile à lire" sont tous des qualificatifs qui peuvent être étiquetés dans presque toutes les langues que vous ne connaissez pas. Autrement dit: la laideur est une conséquence directe de votre méconnaissance de la langue.
Bien connaître une langue signifie reconnaître les modèles dans le code. Un code bien écrit par virtuel de pratique apparaîtra élégant, tandis qu'un mauvais code (lent, sujet aux erreurs) apparaîtra laid. C'est aussi simple que ça.
Une dernière remarque: les articles que vous citez contiennent plusieurs inexactitudes et informations obsolètes. Comme seule justification d'une discussion hautement subjective et émotionnelle, ils ne sont pas très bien adaptés.
Pour moi, Visual Basic semble maladroit, laid, sujet aux erreurs et difficile à lire.
Pour moi, l'anglais semble maladroit, laid, sujet aux erreurs et difficile à lire, surtout écrit par des gens qui ont une grammaire médiocre, une mauvaise orthographe, un mépris insouciant pour la capitalisation et la ponctuation, et aucun sens de la façon d'organiser spatialement et mentalement leurs pensées.
Ce n'est pas seulement que Visual Basic est difficile à lire ou maladroit à cause de la syntaxe du langage, mais c'est généralement le cas parce que le programmeur n'est pas vraiment bon pour exprimer ses propres pensées:
If blah = 10 Then If stuff = "foo" Then t = 1 + k: s = 42: dostuff21
C'est horrible. Mais il n'est pas non plus particulièrement difficile d'écrire du code horrible dans d'autres langues. Une fois écrit correctement, cela aurait beaucoup de sens même si le code est écrit en VB:
If SelectedType = 10 And UserName = "Foo" Then
CurrentUsers = CurrentUsers + 1
UserConnectionID = 42
PerformUserOperation
End If
Au moins, c'est plus lisible et compréhensible. C'est toujours BASIC. Cela revient vraiment à la capacité du programmeur d'exprimer clairement ses intentions en formatant le code d'une manière facile à lire, en utilisant des identificateurs bien nommés et en prêtant attention à l'écriture de code compréhensible.
Cela dit, je n'ai pas beaucoup touché à Visual Basic depuis les jours VB3 (d'où l'exemple de la "vieille" syntaxe), mais ce n'est pas parce qu'un langage peut être abusé qu'il ne peut pas être utilisé correctement pour écrire du code assez robuste. . Bien sûr, il peut y avoir quelques lacunes, mais les approches conçues pour contourner ces problèmes montrent également les compétences d'un programmeur par rapport à un autre.
(Pulvérisation sans discernement On Error Resume Next vient à l'esprit comme un moyen pas si bon de contourner les lacunes du manque d'exceptions dans VB de retour dans les jours pré .NET.)
La plupart de vos arguments contre VB ne s'applique qu'à VB-Classic (deuxième lien) ou basé sur des arguments faibles ou obsolètes
- Même dans VBC, vous n'utiliserez pas GoSub ... Retour etc.
- Quel est le problème avec
static? C++ le prend également en charge. - VB10 introduit la continuation de ligne implicite (vous n'avez même pas besoin d'une semicola redondante comme C #)
- Les différentes fonctions de conversion existent également en C++ et C #.
(object)(expr)- Cast-Syntax etobject as typeDe C # sont encore plus confus et incohérents. - Quel est le problème avec
with? Vous pouvez créer des arborescences imbriquées de manière très intuitive, ce qui n'est pas possible en C #. - Gestion des événements en VB est beaucoup plus élégant qu'en C #. Vous pouvez introduire et gérer des événements par un seul mot-clé (
WithEvents) sans avoir à initialiser les délégués, eventhandler-procs etc. Cela rend la programmation GUI dans VB beaucoup plus confortable et vous n'avez pas besoin de générer de code d'événement par le concepteur . - Les paramètres facultatifs sont introduits dans le nouveau C # - Par conséquent, ils semblent être bons.
- VB.NET a les opérateurs stricts et raccourcis-booléens.
- Vous faites recherchez les erreurs de syntaxe au moment de la compilation, sauf si vous exécutez VB comme un langage de script).
End Ifest plus utile que juste}. Lorsque vous avez des structures syntaxiques complexes, toutes les accolades sont juste déroutantes alors qu'unEnd ...Concret vous aide à déterminer quel bloc n'a pas été fermé.- Littéraux XML - Le script XML fait maintenant partie du code, entièrement pris en charge par intellisense.
Dans l'ensemble, il y a juste quelques différences objectives entre VB.NET et C # en dehors de la syntaxe. EG: La conception graphique est beaucoup plus efficace dans VB grâce à un meilleur système d'événements et à un meilleur IDE alors que par exemple les algorithmes peuvent être mieux exprimés en C # parce que le la syntaxe est concise.
Le reste n'est qu'une question de style personnel. Les programmeurs de style C se sentent à l'aise avec C #, VB (ou peut-être Pascal?) - Les programmeurs de style utilisent VB.
Mais la syntaxe VB basée sur Word, plus explicite, peut être plus facile à lire pour les débutants que tous les symboles en C. Comparez:
If (a < 15) Xor (b = 2) And Not Condition Then
à
if ((a < 15) ^ (b == 2) && !Condition())
Cela ne signifie pas qu'une langue est meilleure qu'une autre.
Éditer : -----------------------------------------
À l'argument VB serait source d'erreurs. Lorsque vous utilisez Option Strict On C'est aussi strict que C # mais ne nous permet pas de faire de telles erreurs:
// 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++;
}
Historiquement, l'environnement de développement VB était un moyen rapide et efficace de créer certains types d'applications (par exemple, les applications GUI). Cela en a fait un choix très populaire. Je pense VB était la langue la plus utilisée à son apogée (par exemple VB6).
Avec ce type de base installée, il n'est pas surprenant qu'il y ait encore beaucoup de travail en cours.
Tout a commencé avant que C # n'existe
En ~ 1999, nous avions Visual Studio 5/6. Si vous étiez un fournisseur de logiciels indépendant ou une entreprise utilisant Windows et que vous aviez besoin d'une application écrite qui pourrait, par exemple suivre le temps passé par les employés sur les projets, vous aviez plusieurs options:
- Formulaires en Visual Basic.
- MFC, ATL ou Win32 dans Visual C++.
- Formulaires dans Access 97/2000.
- Site Web ASP.
- Applet Java.
À l'époque, nous étions juste avant l'éclatement de la bulle Dot-Com, donc tous ceux qui étaient bons avec (4) ou (5) sont partis négocier des options d'achat d'actions à n'importe quel incroyable dot-com qui les attirait.
(3) avait des problèmes avec le verrouillage et l'évolutivité globale, mais j'ai vu beaucoup de solutions basées sur Access qui permettraient de lancer des fonctions de support selon les besoins.
Cela nous laisse donc avec VB et VC++:
L'éditeur de formulaires dans VB était, à l'époque, excellent pour la productivité. Vous pouviez glisser-déposer vos composants - pas seulement des boutons, des étiquettes et des zones de texte, mais la boîte à outils complète des "contrôles OLE" de réutilisable des composants comme des grilles intelligentes, des feuilles Excel ou des instances IE. Le câblage a été fait en arrière-plan - tout était comme un objet et vous avez simplement double-cliqué sur des choses pour ajouter des gestionnaires d'événements. C'était très beaucoup plus difficile dans Visual C++. En tant que membre de l'équipe de support de développeur Visual Studio à l'époque, je me souviens comment les appels de support Visual Basic étaient principalement sur le composant qui était le mieux à utiliser ou comment optimiser leur application de certaines manières. C'était presque jamais "comment créer une application avec les fonctionnalités d'interface utilisateur X, Y et Z".
La création d'une interface utilisateur riche en Visual C++ était un défi différent. Bien que Visual Editor prenne en charge les boîtes de dialogue et les formulaires SDI/MDI, il était assez limité. La prise en charge de l'intégration de OLE contrôles (ActiveX) dans MFC ou Win32 était un art noir, bien qu'un peu plus facile dans ATL. Le câblage de choses simples comme redimensionner des événements ou dessiner par le propriétaire était assez douloureux, laissez seuls les points de connexion requis pour les événements personnalisés dans les composants.
Oui, VC++ avait la vitesse d'exécution, la capacité de débogage et les options de frameworks/bibliothèques/UI flexibles, mais le support IDE ne pouvait pas couvrir tout ce terrain, donc adressé les opérations les plus courantes avec des choses comme les assistants , des hiérarchies de classes MFC complètes et des lignes d'assistance pendant 90 jours/2 incidents gratuits.
IIRC, le packager d'applications fourni avec VB pourrait empaqueter votre application, le VB runtime et les dernières DLL de contrôles communs et vous fournir un installateur EXE autonome que vous pourrait mettre sur un CD et accéder aux clients. Rien de tout cela "quels msvcrtXX.dll et mfcxx.dll avez-vous installé?", ce qui a tourmenté les développeurs MFC.
Donc, pour des raisons de temps de mise sur le marché et d'interface utilisateur riche, VB a obtenu un très gros succès.
Lorsque Visual J ++ et Visual Interdev ont frappé dans VS6, il était clair que Visual Basic IDE avait gagné une bataille contre Visual C++, qui était juste à mon humble avis. Ce n'était pas une surprise du tout que Visual Studio .NET avait un éditeur de formulaires de type VB pour le nouveau langage C # [~ # ~] cool [~ # ~] .
Le nouveau langage de type Java/C/C++ couplé au concepteur d'interface utilisateur apprécié par VB personnes pendant tout ce temps a donné un nouveau chemin de migration pour les personnes C++ qui en avaient fini avec MFC/ATL/Win32. Pour les VB 3/4/5/6 personnes qui n'aimaient pas le manque de compatibilité à 100% en arrière dans VB.net, cela a offert l'occasion d'apprendre une nouvelle langue dans un environnement familier.
Les raisons pour lesquelles VB était un produit aussi complet ont probablement quelque chose à voir avec les origines de Microsoft, Basic étant leur produit phare de développeur, mais je ne ' Je n'ai pas de citations pour le moment.
Quelle que soit la laideur d'un langage donné, les raisons pour lesquelles il faut s'y tenir se résument généralement à: il est très coûteux de supprimer une énorme base de code et le fait que les développeurs connaissent déjà le langage, le rend moins cher à utiliser que les autres langages.
VB.NET est plus facile à apprendre, vous avez raison, et c'est plus facile dans l'ensemble que C #, à mon avis. C'est le premier point pourquoi VB est si populaire. Un autre, et le plus gros point, je pense, est qu'il existe une énorme communauté de développeurs qui ont travaillé avec VB 6 et les versions antérieures de ce langage et il est plus facile pour eux de développer des applications avec VB.net que pour apprendre une nouvelle langue.
Comme d'autres l'ont dit, votre jugement esthétique sur la syntaxe du langage dépend fortement de ce que vous saviez auparavant. Depuis plus d'une décennie, il semble que ce soit un concours de type C, avec des accolades pour les "blocs", "->" pour l'indirection (Perl, php), des parenthèses pour les arguments d'appel de fonction, // pour commentaires et un point-virgule à chaque extrémité de la ligne. Certaines personnes ont même pensé que grâce à cette "pensée unique", si vous connaissez une langue, vous les connaissez toutes, ce qui est en effet ridicule. Mais cela a inculqué l'idée parmi les gens C++/Java qui est la seule esthétique de syntaxe correcte et tout le reste essaie de cloner COBOL.
Il y a quelques années, je suis passé à Ruby, et maintenant au python, et je ne supporte plus les points-virgules laids, les accolades et autres personnages inutiles. Le code source est destiné à être lu par les humains. Quand j'ai essayé Visual Studio, j'ai choisi VB plutôt que C #. Je soupçonne que certains programmeurs ont choisi C # juste pour "paraître sérieux" avec sa syntaxe de type Java, mais allez, le très les mêmes caractéristiques sont là ... donnez à vos yeux un repos.
Eh bien, si vous parlez de .NET, il y en a un très facile auquel je peux penser:
L'éditeur de VB.NET dans Visual Studio est bien meilleur pour détecter les erreurs de syntaxe que C #.
Alors que l'éditeur de C # a obtenu une énorme amélioration dans VS2008 SP1, il y a encore quelques erreurs de syntaxe que l'éditeur ne détecte pas jusqu'à ce que vous tentiez de compiler le programme.
Une grande partie de la popularité de VB est née à une époque où les outils de VB étaient beaucoup plus conviviaux que les autres langages disponibles. Le "classique" VB offrait un moyen facile de construire Windows applications sans avoir à apprendre les tripes de l'API Win32 ou à se soucier de la gestion manuelle de la mémoire. La barrière à l'entrée pour les programmeurs débutants était beaucoup plus faible avec VB qu'en C++, donc beaucoup de gens se font les dents avec VB.
De nos jours, je pense que VB un avantage sur C # est la familiarité de ceux qui ont travaillé avec VB au fil des ans. Un autre avantage est que VB est facile à lire en raison de la tendance à utiliser des mots clés au lieu des symboles de ponctuation. En tant que personne travaillant en VB, Java, C, C # et Python, je trouve que VB = est le langage le plus facile à utiliser lors de l'examen du code que j'ai écrit il y a des années. La syntaxe est plus détaillée, ce qui facilite souvent la lecture du code, et Visual Studio a toujours fait un excellent travail de mise en forme VB code pour nettoyer la mise en forme lors de la frappe afin que le code soit mis en forme de façon cohérente (indépendamment de la négligence de l'auteur).
En remarque, je trouve Python extrêmement facile à lire et à réviser pour des raisons similaires. En Python, le formatage du code est appliqué par l'interpréteur plutôt que par l'IDE, mais le résultat final est le même. Python favorise également les mots-clés à la ponctuation, mais sans doute moins que VB.
Pour n'en nommer que quelques-uns:
- facilité d'utilisation
- nom familier (basique était l'un des premiers langages de programmation informatique populaires)
- ne sous-estimez pas le marketing Microsoft
Il serait difficile de prétendre qu'elle est plus ou moins "sujette aux erreurs" que toute autre langue. Je doute également de la question de "la grande majorité du Web MS commercial"; d'après ce que j'ai vu, C # prend de loin les devants pour le développement .NET (avec .NET étant l'outil phare dans la pile MS pour les choses qui ne sont pas des pilotes de périphériques, etc.).
VB est très verbeux et facile à utiliser par rapport à C # qui est sensible à la casse. Pour un programmeur débutant, c'est le meilleur point de départ.
Un avantage de VB.NET par rapport à C # (qui disparaîtra avec C # 4), est les paramètres par défaut et nommés, une très bonne chose à avoir lors de l'utilisation de VSTO.
VB/VB.NET appartient à la catégorie RAD (Rapid Application Development). Vous pouvez développer des applications avec simplement des contrôles par glisser-déposer à partir de la boîte à outils et moins de code.
Eh bien, je pense que vous devez faire la différence entre le classique VB et VB.NET.
Je pense que VB.NET est pas très populaire, mais Visual Basic "Classic" l'est toujours1 La raison en est qu'il est TRÈS facile de créer une application Windows. Comparez cela à une application Windows en C++/Mfc, qui était presque la seule alternative à l'époque.
Pour la même raison, Delphi était très populaire il était une fois.
Je pense qu'une partie de la raison est parce que les anciens programmeurs asp entrant dans .NET comme je l'ai fait sont très familiers avec VB déjà parce que VB script est le langage = ASP classique utilisé pour la plupart. Je pensais qu'il fallait moins de temps pour écrire en VB en .NET car je savais déjà parler VB. VB est également moins un pleurnichard que C #. Je peux lire/écrire dans les deux mais je préfère VB parce qu'il est facile de se faire des amis si vous êtes un nouveau programmeur).
Je travaille dans un environnement où nous utilisons les deux. Nous sommes passés au C # en faveur du classique ASP et VB. À mon avis, il n'y a pas de rupture entre les langues. Pour la plupart des projets, vous pouvez faire le même travail avec les deux langues. Maintenant, je le fais partagez votre point de vue sur les erreurs et je trouve également VB à encombrer (sans raison).
Comme d'autres l'ont mentionné, VB est très simple et historiquement, vous pouvez créer des projets très rapidement. Cela a survécu dans le développement Web (qui est développé rapidement), mais je pense que lorsque les gens réalisent que C # est juste aussi rapidement développé, VB disparaîtra. Une autre raison pour laquelle je pense qu'il disparaîtra est que tout le reste que vous codez (CSS, JavaScript) lors de la création d'applications Web ressemble plus à C # qu'à VB, donc il est logique d'utiliser C #, même pour les débutants.
Personnellement, j'aime la façon dont les événements sont attachés dans vb.net avec le mot clé 'handles' ... Le IDE/Visual Studio/est également plus réactif lorsqu'il s'agit de VB et gère automatiquement la plupart des if-end et similaires ... C # est bien sûr beaucoup plus concis et propre (à mon humble avis, j'ai beaucoup travaillé avec les deux)
Depuis le framework 4.0, il n'y a qu'une petite poignée de choses VB manque par rapport à C #, et l'inverse est également vrai. À savoir:
- Le plus notable est que VB.NET n'a pas le mot-clé
Yield, mais il arrive bientôt sur VB.NET avec le nouveau framework async. - Il n'y a pas de mot clé
unsafe. Je ne l'ai jamais trouvé nécessaire, mais il y a sûrement des gens qui l'ont fait. - Il n'y a pas de chaînes multi-lignes. Les chaînes multilignes sont accomplies en utilisant les opérateurs + (ou hérités &) sur les lignes. Ou, ils peuvent être accomplis en utilisant la syntaxe littérale XML:
Dim s = <s>My string... multiple lines...</s>.Value. Ce n'est pas joli, mais si vous n'êtes pas pointilleux et que vous voulez vraiment des chaînes multi-lignes, cela fonctionne. Et, vous pouvez faire une interpolation de chaîne avec elle en utilisant la syntaxe<%= myVar %>Qui est Nice. - Il n'y a pas d'équivalent de portée variable de
dynamic. Les variables dynamiques existent depuis VB depuis longtemps avecOption Compare Off, Mais c'est un fichier de portée, donc ce n'est pas aussi bon quedynamicparce quedynamiclimite la portée à la seule variable déclarée de cette façon. - VB n'a pas de syntaxe lambda laconique. Les lambdas sont là, mais vous devez utiliser
Function(x)ouSub(x).
Certaines fonctionnalités de VB.NET n'ont pas C #:
- Littéraux XML, qui sont pratiques pour toutes sortes de choses, pas seulement XML.
- L'insensibilité à la casse dans une langue est le miaulement du chat. Peu d'autres langues le permettent, mais quelle différence cela fait dans la vitesse de codage de ne jamais avoir à appuyer sur la touche Maj lorsque vous tapez et que votre code se formate automatiquement comme vous le souhaitez.
- La clause
Selectsouvent inutile peut être omise des requêtes Linq. - Le mot clé
Nothingest beaucoup plus utile quenulldans la mesure où tout (même les types de valeur) peut être défini surNothinget vous obtenez la valeur par défaut. Il n'est pas nécessaire d'utiliser le mot clédefault. - VB.NET est constamment compilé dans Visual Studio afin que vous voyiez immédiatement les erreurs. Ne pas frapper CTRL-SHIFT-B toute la journée comme en C #.
Ma boutique fait MVC3 avec Razor en utilisant VB.NET et une fois que vous avez surmonté les préjugés (pour la plupart infondés), c'est en fait un langage très agréable à utiliser. Ce n'est pas vraiment plus verbeux que C # comme beaucoup le prétendent (sauf dans le cas des lambdas), et c'est à peu près parallèle fonctionnalité par fonctionnalité avec C #. J'ai trouvé que la plupart des gens qui haïssent n'ont pas vraiment codé dans VB.NET moderne depuis longtemps.