.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

Le , par Gordon Fowler

0PARTAGES

10  1 
Etes-vous plus C# ou VB ?
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

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

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

Et vous ?

Êtes-vous plus C# ou VB ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de BenoitM
Expert confirmé https://www.developpez.com
Le 27/09/2011 à 15:38
VB plus verbeux et donc plus lisible
VB pas de ";"

sinon c#

vive les discutions à troll
4  1 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 27/09/2011 à 16:14
Citation Envoyé par Gordon Fowler Voir le message
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 Voir le message
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 Voir le message
Etes-vous plus plus C# ou VB ?
Au cas où c'était pas évident d'après ce qui précède : C#
6  0 
Avatar de kdmbella
Expert éminent https://www.developpez.com
Le 27/09/2011 à 16:59
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.
3  1 
Avatar de octal
Membre éclairé https://www.developpez.com
Le 27/09/2011 à 17:18
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.
4  0 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 27/09/2011 à 18:44
Citation Envoyé par tomlev Voir le message
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 Voir le message
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 Voir le message
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
4  0 
Avatar de Nathanael Marchand
Rédacteur https://www.developpez.com
Le 27/09/2011 à 19:12
Citation Envoyé par sevyc64 Voir le message
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
0  2 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 27/09/2011 à 22:35
Citation Envoyé par sevyc64 Voir le message
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 Voir le message
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 Voir le message
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#.
6  0 
Avatar de keynux
Futur Membre du Club https://www.developpez.com
Le 28/09/2011 à 3:00
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#.
1  1 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 28/09/2011 à 3:35
Citation Envoyé par sevyc64 Voir le message
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...
0  2 
Avatar de kikione
Membre à l'essai https://www.developpez.com
Le 28/09/2011 à 6:27
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
4  1 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web