.NET : êtes-vous plus C# ou VB ?

.NET : êtes-vous plus C# ou VB ?
Entretien avec le PDG de SoftFluent qui envisage de réactiver l'option Visual Basic dans CodeFluent Entities


En tant qu’éditeur de CodeFluent Entities, SoftFluent a concentré ses efforts de R&D et surtout de test sur la génération de code C#. Néanmoins, le produit a également été conçu de manière compatible avec Visual Basic .NET.

« Et nous envisageons de réactiver cette option », explique Daniel COHEN-ZARDI, PDG de SoftFluent.

L'occasion de revenir avec lui sur ces deux langages, leurs points communs, leurs différences et pourquoi choisir l'un plutôt que l'autre.

Comment choisir entre VB et C# pour mener un projet ?

Daniel COHEN-ZARDI : Beaucoup de gens débattent avec passion des vertus techniques de chaque langage. Personnellement, il me semble que ce choix ne devrait pas être une décision technique.

Car techniquement, il est important de se rappeler que les deux langages dans leurs versions actuelles ont été conçus pour la plateforme. NET. Visual Basic .NET et C# utilisent le « Common Langage Runtime » et n’ont aucune différence significative en termes de performances, à l'exception de différences marginales sur certains points très précis du compilateur.

Ce sont plus les facteurs opérationnels qui sont à prendre en considération lors d’une prise de décision sur le choix d’un langage de programmation.

D’une part, les compétences de l’équipe de développement et son expérience avec la syntaxe de C# ou VB sera d'une importance primordiale pour la productivité. Surtout si l’équipe est stable et s'est engagée sur le long terme (il serait par exemple contre-productif d'imposer un changement de langage alors que les gens sont à l'aise avec leur style de programmation et qu’il n'y a pas de raison majeure de changer).

D'autre part, si un projet nécessite plusieurs nouvelles embauches, il sera vraisemblablement plus facile de recruter pour un projet C# que pour un projet Visual Basic. On constate en effet que statistiquement les développeurs les plus avancés utilisent C# plutôt que Visual Basic.

Il existe aussi des cas où l'on peut prendre la décision de lancer un projet « hybride » ?

Daniel COHEN-ZARDI : Oui. Dans certains cas, le mélange des langages peut être réalisé grâce à l'interopérabilité. Cela nécessite une masse critique de code et de ressources sur les deux langages pour que cela soit économiquement justifié. Faute de quoi il ne sera pas optimal de maintenir le code sur le long terme.

Bien que Microsoft déclare officiellement « qu'il s'agit de deux langages de programmation de première classe qui s'appuient sur le Framework .NET, et qui sont tout aussi puissants l'un que l'autre », il existe des différences entre Visual Basic NET et Visual C # NET. Quelles sont, d'après vous, les conséquences de ces différences dans les choix de conception ?

Daniel COHEN-ZARDI : Certaines décisions de conception, en particulier au niveau syntaxe, ont été prises pour faciliter la transition des communautés existantes : C# cible principalement C++ et Java, et VB.NET cible plutôt les anciens développeurs Visual Basic.

Parce que C++ était plus puissant que Visual Basic - dans le sens que l'on pouvait faire des choses en C++ que l'on ne pouvait pas faire en VB - il subsiste encore une perception que C# s’adresse aux développeurs professionnels alors que Visual Basic NET s’adresserait aux amateurs. Mais il n'existe aucun fait technique pour appuyer cette affirmation.

Vous semblez néanmoins avoir une petite préférence pour C# ?

Daniel COHEN-ZARDI : Chez SoftFluent nous n'avons aucune préférence. Mais l'argument ultime qui pousse souvent la décision vers C# est la communauté.

Beaucoup d’exemples de code, publiés par Microsoft ou par la communauté, sont en C#. Ce qui, dans de nombreux scénarios, pourra rendre les équipes beaucoup plus productives. Vous trouvez un écosystème plus complet de composants tiers et d'outillage pour C#. C'est ce que nous constatons en situations réelles chez de nombreux clients en France et à l’international.

Ceci dit il ne faut pas en faire une religion. Si l’équipe est majoritairement à l'aise avec Visual Basic et ce style de programmation, pourquoi se compliquer la vie ?


Pas plus C# que VB donc, SoftFluent étudie très sérieusement l'activation de l'option Visual Basic dans CodeFluent Entities. « Nous réfléchissons à la mise en priorité de cette partie de notre feuille de route », conclut Daniel COHEN-ZARDI.

Une bonne idée ?

Et aussi

:fleche: CodeFluent, la première fabrique logicielle pilotée par les modèles (page officielle)

:fleche: «Comment le développement logiciel piloté par les modèles peut vous aider à réussir vos projets», un Livre Blanc de SoftFluent

Et vous ?

:fleche: Êtes-vous plus C# ou VB ?

VB plus verbeux et donc plus lisible
VB pas de ";"

sinon c# ;)

vive les discutions à troll :mrgreen:

Citation:

---

Envoyé par Gordon Fowler

On constate en effet que statistiquement les développeurs les plus avancés utilisent C# plutôt que Visual Basic.

---

+1000
A part quelques rares exceptions, les développeurs VB.NET atteignent rarement le même niveau que les développeurs C#. Même si les 2 langages offrent à peu près les même possibilités, C# impose un style plus strict, ce qui limite les risques d'erreur et oblige le développeur à bien comprendre ce qu'il est en train de faire. Il est plus facile d'écrire du mauvais code en VB.NET qu'en C#... (même si on peut évidemment écrire du bon code en VB.NET et du mauvais code en C#)

Citation:

---

Envoyé par Gordon Fowler

il subsiste encore une perception que C# s’adresse aux développeurs professionnels alors que Visual Basic NET s’adresserait aux amateurs. Mais il n'existe aucun fait technique pour appuyer cette affirmation.

---

Je pense que c'est surtout qu'au départ VB6 (et antérieur) avait été conçu pour que des gens dont ce n'était pas vraiment le métier puissent réaliser des applications simples. A mon avis c'est de là que vient l'idée que VB.NET est un langage facile qui s'adresse aux débutants, alors que ce n'est pas vrai : VB.NET n'est pas "plus facile" que C#. C'était sans doute vrai pour VB6, mais VB.NET est beaucoup plus subtil ; c'est juste que les subtilités sont masquées sous des apparences de facilité.

Citation:

---

Envoyé par Gordon Fowler

:fleche: Etes-vous plus plus C# ou VB ?

---

Au cas où c'était pas évident d'après ce qui précède : C# :ccool:

je suis C# à 100% principalement à cause de sa proximité syntaxique avec Java car lorsqu'on passe d'un language OO(Java ou C++) à un langage du .Net en général on préfère c# histoire de pas trop se casser la tête et de préserver les acquis. :ccool:

Je ne comprend pas trop ce qu'ils veulent dire par "réactiver le générateur de code VB" ni en quoi la différence VB vs C# pose problème.

VB ne diffère que sur certains points très particulier par rapport à C#. Or, les outils de modélisation de SoftFluent sont fait pour générer du code métier, et je ne voit pas en quoi leur code métier pourrait utiliser "des spécifités" C# qui le rendrait incompatible avec VB.

Puis ne serait il pas plus intelligent de continuer à générer du C# et d'utiliser un convertisseur de code qui le convertirait vers VB?

La grammaire de C# est sans ambiguïté, et avoir un parseur 100% d'un code C# généré automatiquement (donc 100% sans erreur) n'est pas chose difficile. Faire générer un code VB au parseur ne devrait pas être la fin du monde. Cela, au contraire, devrait leur permettre de se concentrer sur 1 seul générateur de code plutôt que de devoir refaire les templates pour chacun des languages à chaque fois qu'ils font des grosses modifications.

Citation:

---

Envoyé par tomlev

A part quelques rares exceptions, les développeurs VB.NET atteignent rarement le même niveau que les développeurs C#.

---

Pas d'accord. Si ça peut être vrai pour des développeurs plus ancien qui viennent de VB6/VBA et qui n'ont jamais fait que du VB, c'est pas du tout vrai pour des développeurs plus jeunes, ou plus polyvalent, habitués à développer dans différents langage.

Citation:

---

Envoyé par tomlev

C# impose un style plus strict, ce qui limite les risques d'erreur et oblige le développeur à bien comprendre ce qu'il est en train de faire.

---

Pas d'accord non plus. Contrairement au C++ ou au JAva et autre, le coté strict est ici imposé par le framework et non pas par le langage. Les contraintes sont absolument les mêmes en C# et en VB.

Citation:

---

Envoyé par kdmbella

je suis C# à 100% principalement à cause de sa proximité syntaxique avec Java car lorsqu'on passe d'un language OO(Java ou C++) à un langage du .Net en général on préfère c# histoire de pas trop se casser la tête et de préserver les acquis.

---

Et c'est bien la cause principale du succès du C#, et sur ce point Microsoft s'est complètement planté.
C# a été initialement créé pour amener les VBistes vers le C++ et l'ex J++ qui état le conçurent du Java.
Au contraire, ce qui s'est passé c'est que les principaux utilisateurs de C# ne viennent pas de VB mais plutôt de C, C++ et Java.
VB devait, au départ, à terme, petit à petit disparaitre. Désormais, depuis la version 2008 Microsoft s'est engagé à faire évoluer VB et C# de concert, pour, à terme (VS2011 ?) toute évolution dans l'un des langage sera aussi dans l'autre et réciproquement.

Pour le sondage ?
Je me prononce pas.
Plutôt VBiste par expérience, mais polyvalent (C, divers basic, Pascal, autres divers langages ), je fais aussi du C# mais pas de C++, et seulement une petit initiation au Java.
Je ne vois aucun intérêt et aucune raison à préférer l'un à l'autre

Citation:

---

Envoyé par sevyc64

Pas d'accord non plus. Contrairement au C++ ou au JAva et autre, le coté strict est ici imposé par le framework et non pas par le langage. Les contraintes sont absolument les mêmes en C# et en VB.

---

Ca a été vu plusieurs fois sur ce forum mais sans le mode strict, c'est la fête au slip en VB.Net...
Mais même sans ca!
Par exemple un object qui est nul est égal à False :calim2:

Citation:

---

Envoyé par sevyc64

Pas d'accord. Si ça peut être vrai pour des développeurs plus ancien qui viennent de VB6/VBA et qui n'ont jamais fait que du VB, c'est pas du tout vrai pour des développeurs plus jeunes, ou plus polyvalent, habitués à développer dans différents langage.

---

Ma remarque était purement empirique ; c'est ce que j'ai observé depuis plusieurs années sur les forums (ici, et dans une moindre mesure sur Stack Overflow). Il suffit de passer en revue les questions d'une journée sur les forums de Developpez pour se rendre compte que les gens qui posent des questions sur VB sont d'un niveau beaucoup plus débutant que ceux qui posent des questions sur C#.

Je me doute bien qu'il y a de bons développeurs VB (et il y en a d'ailleurs quelques uns sur ce forum) mais il y a quand même une forte corrélation entre utilisation de VB et niveau très faible... A moins bien sûr de supposer que Developpez.com est un cas particulier qui ne reflète pas du tout la réalité globale.

Citation:

---

Envoyé par sevyc64

Pas d'accord non plus. Contrairement au C++ ou au JAva et autre, le coté strict est ici imposé par le framework et non pas par le langage. Les contraintes sont absolument les mêmes en C# et en VB.

---

Si tu mets Option Strict On (ce que beaucoup de gens ne font pas), c'est presque vrai. Mais même avec ça, il reste encore quelques trucs un peu batards en VB qui peuvent induire des erreurs difficiles à détecter. Quelques petits exemples :

• les paramètres ByRef : le passage par référence n'est spécifié qu'à la déclaration de la méthode, pas lors de l'appel. Résultat, si on n'y prête pas attention, on peut passer un paramètre par référence sans le savoir, et donc ne pas réaliser que sa valeur peut être modifiée par la méthode. Ca peut causer des bugs assez difficile à repérer...
• "l'instance par défaut" (je sais pas si ça a un vrai nom) des Forms : le fait de pouvoir manipuler une Form via le nom de la classe est une horreur sans nom. Ca fait que les débutants mettent souvent longtemps à comprendre le concept d'instance de classe, ce qui est quand même assez fondamental dans un langage objet
• le fait qu'une fonction n'est pas obligée de retourner explicitement une valeur : le fait d'oublier un Return peut causer des bugs à l'exécution alors que ça aurait pu (du) être détecté à la compilation. OK, ça fait un warning, mais a priori la plupart des débutants ne font pas trop attention aux warnings...

J'ai mentionné 2 fois les débutants dans ces exemples, et ce n'est pas par hasard. Le problème est que VB.NET est souvent présenté comme un langage pour débutant, alors que c'est un très mauvais langage pour débuter, justement à cause de son "laxisme" et parce qu'il ne force pas le développeur à adopter de bonnes pratiques. Pour un développeur expérimenté c'est bien sûr moins gênant, parce qu'il connait les pièges à éviter...

Citation:

---

Envoyé par sevyc64

Je ne vois aucun intérêt et aucune raison à préférer l'un à l'autre

---

Bah si on met de côté les problèmes mentionnés plus haut, c'est surtout une question de goût... Perso je trouve la syntaxe de VB affreuse, mais c'est totalement subjectif et je n'utiliserai jamais cet argument pour convaincre quelqu'un de préferer C#.

Je programme en VB. Mais souvent quand je cherche une solution à mon problème je m'inspire de solution écrit en C#. Donc, si on est plusieurs utilisateur de VB qui utilise les solutions donné en C#. Ça expliquerait peut-être le pourquoi il a moins d'exemple en VB qu'en C#.

Citation:

---

Envoyé par sevyc64

VB devait, au départ, à terme, petit à petit disparaitre. Désormais, depuis la version 2008 Microsoft s'est engagé à faire évoluer VB et C# de concert, pour, à terme (VS2011 ?) toute évolution dans l'un des langage sera aussi dans l'autre et réciproquement.

---

c'est exact il vaut mieux pérenniser sur C#...si VB.NET risque de disparaître c'est encore des tas de projets à migrer éventuellement sous C#.
Déjà que Microsoft nous a arnaqué avec VB6...

Bonjour,

je suis développeur VBNET, je passe parfois au c#. Il est évident qu'ils sont pareil à 1 ou 2 exceptions près. L'instrustion "yield" en C# n'a pas d'équivalent vbnet, mais combien l'utilise ?... Je pense sincèrement que le VBNET a un avantage synthaxique : il est plus simple à apprendre et sans doute plus lisible qu'un code c#.

Il faut aussi considérer que le coding c# ou vb créera exactement le même code compilé. C'est le point fort de DOTNET et à mon avis le plus important à concidérer.

Si j'étais à votre place, je choisierai VBNET et des personnes avec une bonne formation algorythmique, ils s'adapteront plus facilement au VB qu'au C#.

Suite aux lectures sur les travers des développement VBNET des commentaires que j'ai lu... Un chef de projet se doit quand même à instaurer des règles pour éviter des codings de ce type(instance directe de fenêtre, imposer des projets avec Option Strict ON et Option Explicit ON). Après ce sont des guerres inutiles.
La maintenance des langages et le pouvoir de supprimer un langage dans DEVStudio me fait un peu sourire... Microsoft ne va pas se tirer une balle dans le pied, ils sont besoin que les boites achetent devstudio. Et VB6, ils l'ont fait évoluer pour DOTNET. Ils ont juste proposer un langage, une syntaxe nouvelle. VB6 était vieillissant, il fallait aussi passer à autre chose...
---
Par exemple un object qui est nul est égal à False
--> Ce n'est pas vrai, si vous codez ça erreur direct
null équivalent nothing
apres on se doit de tester avec des opérateurs is ou isNot
non c'est des anciennes croyances populaires
---

N'oublions pas en informatique... "Pierre qui roule ammassera mouse" ;)

Sincères salutations

Personnellement,

je suis passé récemment à C# car j'en avais marre de traduire tout en VB systématiquement.

Mais je trouve que l'éditeur C# est loin d'arrivé à la cheville de celui de VB !

Autrement ça change pas grand chose pour moi et mon niveau de développeur amateur :aie:

Après quelques années de pratique sur les deux langages (et même un peu de C++.NET), le passage d'un langage à l'autre ne demande qu'un temps d'adaptation pour retrouver les automatismes. Si je devais vraiment trancher, je dirais que le C# use un peu moins le clavier que le VB :D
Après je trouve le débat assez stérile, c'est la connaissance du fonctionnement des API's .NET qui compte réellement, pas la façon de les écrire.

Citation:

---

Envoyé par Mat.M

c'est exact il vaut mieux pérenniser sur C#...si VB.NET risque de disparaître c'est encore des tas de projets à migrer éventuellement sous C#.
Déjà que Microsoft nous a arnaqué avec VB6...

---

Pas de risques pour VB.NET a priori... si MS avait l'intention de l'abandonner, ce serait fait depuis longtemps. Au contraire, MS s'est engagé à maintenir la parité entre C# et VB : maintenant toutes les nouvelles fonctionnalités de l'un seront aussi ajoutées à l'autre.

Citation:

---

Envoyé par kikione

L'instrustion "yield" en C# n'a pas d'équivalent vbnet

---

Pas encore, mais ce sera dans VB11 ;)

Citation:

---

Envoyé par kikione

mais combien l'utilise ?

---

Plein de gens, mais c'est vrai qu'en pratique c'est surtout pour des scénarios avancés... Cela dit, une fois que tu as pris l'habitude, c'est souvent une meilleure idée d'utiliser un itérateur que de renvoyer une liste ou un tableau.
Perso je m'en sers souvent pour créer des opérateurs Linq personnalisés (par exemple ceux qui sont dans la lib Dvp.NET)

Citation:

---

Envoyé par DotNET74

Mais je trouve que l'éditeur C# est loin d'arrivé à la cheville de celui de VB !

---

Ca doit être une question d'habitude alors, parce que moi il me semble que l'éditeur C# est largement supérieur... Quand je me retrouve dans l'éditeur VB j'ai l'impression qu'il me manque la moitié des fonctionnalités que j'ai l'habitude d'utiliser.

Chacun utilise sa logique et qui peut prétendre être Meilleur ?
Moi, je suis pour le partage des tâches.
(VB, pour l'affichage, et C pour les calculs, (C'est un exemple))
Certains prétendent que VB n'est pas professionnel, parce que d'aspect simple ?
Pourquoi faire simple quand on peut faire compliquer !...
C'est sa le drame !

Au lieu de vous chamailler sur vos "égaux"... de la plus grosse tête ...
... Pensez à l'utilisateur ! C'est quand même lui qui paie la note au final !

A moins de faire comme toute bonne société qui se respecte:
<<Tant qu'il y a des cons pour payer ...>>

Citation:

---

Envoyé par kikione

je suis développeur VBNET, je passe parfois au c#. Il est évident qu'ils sont pareil à 1 ou 2 exceptions près. L'instrustion "yield" en C# n'a pas d'équivalent vbnet, mais combien l'utilise ?...

---

Tout le monde (sauf les codeurs du dimanche, peut être).

Citation:

---

Je pense sincèrement que le VBNET a un avantage synthaxique : il est plus simple à apprendre et sans doute plus lisible qu'un code c#.

---

Affirmation purement subjective. Je pense, tout aussi subjectivement, exactement le contraire. (il est, par exemple, difficile de trouver une syntaxe aussi contre-intuitive que l'abonnement à un évenement en VB.Net; ah si ! à la réflexion, la déclaration d'une fonction abstract en C++, avec le '=0' qui est pas mal du tout dans le genre)

Citation:

---

Si j'étais à votre place, je choisierai VBNET et des personnes avec une bonne formation algorythmique, ils s'adapteront plus facilement au VB qu'au C#.

---

Je ne vois pas du tout sur quoi se base cette affirmation. Peux tu l'étayer ?

Citation:

---

Et VB6, ils l'ont fait évoluer pour DOTNET.

---

Ils ont créé dotnet, avec un langage sur mesure (C#) et lui ont ajouté un langage qui a une proximité syntaxique avec VB6; ce n'est pas la même chose.

Citation:

---

Ils ont juste proposer un langage, une syntaxe nouvelle. VB6 était vieillissant, il fallait aussi passer à autre chose...

---

C'est surtout le fait que Microsoft ne disposait pas de système unifié de développement client lourd/client léger/serveur.

En effet, avant .net, en gros il fallait utiliser :

- C++ et/ou VB6 avec COM pour le client lourd.
- ASP (VBScript) pour le client léger coté serveur.
- C++ avec DCOM pour écrire les services.
- DCOM ou RPC pour les comm client lourd vers services.

Le tout était un joyeux bordel sur le moindre projet un peu complexe ; résultat on partait souvent sur java.

A ce moment l'offre Microsoft ne permettait pas de concurrencer java qui offrait une plateforme unifiée.

.NET a remis les pendules à l'heure.

ne pas mélanger tout merci.

Citation:

---

Envoyé par kikione

Par exemple un object qui est nul est égal à False
--> Ce n'est pas vrai, si vous codez ça erreur direct
null équivalent nothing

---

http://www.developpez.net/forums/d11...m/#post6213974 :)

VB n'est pas plus simple que le C# (même si parfois plus lisible (plus facile de lire "Implements ITrucMuche" que ": ITrucMuche" même si c'est une question d'habitude) mais le problème c'est que VB est plus permissif.
Et même si cette permissivité semble pratique au premier abord, elle est surtour source d'erreurs*,de bug sans parler des trous béant dans la logique POO**

Je ne comprend pas comment l'option Strict ON et l'option Explicit ON n'ont pas été rendu obligatoire.

* Par exemple sans explicit tu n'est pas obligé de déclarer une variable
Résultat mon premier jour de programmation Vb.Net , j'ai du cherché pendant plusieurs minutes un problème. En fait c'était une simple faute de frappe dans le nom d'une variable...Bon j'ai été directement mettre les options à ON

* en partie corriger dans les dernieres version de VB.Net (où on est obligé de déclarer le namespace VisualBasic pour utiliser ses fonctionnalités anti-POO(datediff et consorts )

Je suis tout a fait d'accord avec props. Ceux deux langages quasi-identique avec une syntaxe différente. Je passe régulière de l'un à l'autre régulièrement avec juste un temps d'adaptation. Bon, pour VB.NET je mets les options Strict et Explicit à ON, je vire l'espace de nom Microsoft.VisualBasic et je mets l'option Infer sur ON seulement si j'en ai besoin. Pour les deux langages, je préfixe correctement avec le type de variable, je ne mélange pas les couches, etc..

Mais quelque soit le langage utilisé, j'ai toujours des fois ou je me dit :
"Je devais être très fatigué le jour ou j'ai écrit ce code, c'est franchement crad":aie:

Citation:

---

Envoyé par Bluedeep

- C++ et/ou VB6 avec COM pour le client lourd.
- ASP (VBScript) pour le client léger coté serveur.
- C++ avec DCOM pour écrire les services.
- DCOM ou RPC pour les comm client lourd vers services.

---

- ASP (VBScript ou JavaScript) pour le client léger coté serveur.

en effet, ASP (3.xx) exposait les objets de base (request, server, ...) que l'on pouvait utiliser pour faire des pages dynamique, mais le langage était au choix de l"utilisateur, et en théorie TOUT langage de script était utilisable (PerlScript, JavaScript, VBScript, ...).

ASP.NET lui a imposé d'utiliser un langage utilsant la CLR, et donc l'un des langages générant du code pour la MV .NET (C#, VB.NET, Delphi.NET, ComponentPascal, ...).