Discussion :

[Justinien]

Bonjour,

étant débutant en .Net je ne me prononcerai pas sur quel est le meilleur langage entre C# et VB.Net.

Cependant, je me demandais une chose : qu'en est-il de C++ ? Y-en a t'il encore certains d'entre vous qui continue à développer en C++ avec VS .Net ?

En effet, bien qu'il est toujours possible de développer en C++ avec Visual Studio .Net, j'ai l'impression que peu l'utilise au profit de C# ou VB.Net. La preuve le fait d'avoir omis C++ dans le débat.

Je me trompe ?

[DrQ]

Sans le cast en effet ça compile, mais j'ai des soucis de fonctionnement par la suite (je parle du Drag & Drop d'objets et non la soluce à Microsoft qui consiste à passer une chaine de caractères).


Pour ce qui est du C++, tu peux programmer avec pour avoir un gain de perfs dans les zones critiques, ou bien si tu as besoin de faire faire du code non managé. Sinon autant passé à C#.

[Zeo_BO]

Ben sans détenir LA réponse, je dirai que VB.NET a toutes les corrections syntaxiques que j'attendai.
Ce n'est peut être pas le langage le plus rapide, mais il a au moins l'avantage d'être un des plus simple.
Je crois que ces langages comblent à eux deux l'emprise qu'a JAVA depuis un certain temps dans le milieu professionnel (il suffit de regarder les offres d'emploi pour s'en convaincre)
C'est d'ailleurs très similaire dans l'approche du Framework.
C sharp sonne "C" ou "C++" donc pro, VB.NET sonne le RAD par excellence, (j'exorcise volontairement Delphi qui est à mon sens trop "BORLANDISE" pour connaitre un réel élan professionnel)
Donc je dirai : VB.NET récupére les déçu du VB qui passe à DELPHI
C sharp récupére les pros et recolle les morceaux des loupés J++ et visual C++.
En tout cas, je sais que ca va en défriser plus d'un, mais je trouve que VB.NET est une évolution plus que bien pensée du VB

[Thomas_X]

Pour ma part je ne fais comme personne (c'est a dire que je ne fais ni de VB .NET (j'expliquerai plus loin pourquoi) ni de C# (je suis toujours perdu dans les méandres du C++, alors pas le temps). Mais je crois que dés que je me serais dépétré du C++, il y a de fortes chances que je migre vers le C#. En effet ce language a l'air de présenter de nomreux avantage, comme d'etre clairement "fait sur sur mesure" pour windows (qu'on m'arrete si je me trompe), et en plus la syntaxe me plait assez (car proche des language issus de C).
Quand a VB... Je ne sais pourquoi, je n'ai aucune atirance pour ce language... D'abord pour une question de sintaxe que je trouve assez déplaisente.
Et au final j'émets une reserve vis-a-vis de .net et de la programation sous windows en général. En effet je ne suis pas convaincu que cela ne soit pas lassant a la longue de sans arret changer de vertions et de voir les bibliotheques évoluer...
Bréf...

[Rami]

Comme on la dit: que soit VB.Net ou C# on passe par le language intermediaire.
Les librairies qu'on attaque sont les memes: celles du framework.

Donc performance, structures des algos, possibilités sont a "un chouillat prés" les memes non?

Aprés on rentre dans la subjectivité d'appréciation de la synthaxe. La, chacun ses gouts. et a mon avis, une fois maitrisé, le passage de l'un a l'autre c'est assez facile si on est un peu rigoureux.(contrairement au passage VB pur et dur a VB.Net)

par contre l'argument de Neo sur "l'ouverture" du C# est peut etre la clef.

[Shark]

Il y a quelques années j'ai découvert par erreur Visual Basic 2.0... j'ai fait quelques programmes et j'étais content.

Niveau perf c'était pas cela, appeler les différentes DLL était un cauchemard. Puis ensuite j'ai arrêté de programmer pendant plus de 2 ans pour passer ma maturité (le BAC français)

Après j'ai repris la programmation à l'EPFL (www.epfl.ch) avec de l'ADA95, un langage sur-chiant au niveau du typage, mais relativement plaisant au niveau de la qualité du code qui découle de ces contraintes.

Parallèlement je me suis mis au C, puis C++, les perfs étaient au rendez-vous, mais écrire du code "propre" sans fuites mémoires demandait une discipline de fer.

J'ai du faire quelques sites Webs dynamiques et la j'ai touché à deux technologies : ASP avec VBScript qui ressemble fortement à VB et PHP avec un syntaxe proche du C.

Recemment j'ai commencé à ressentir le besoin d'un framework complet pour développer des applications Web, et deux framwork ont retenu mon attention : J2EE de Sun Microsystems et .Net de Microsoft.

Après une étude des deux framework et développement d'un application sosu J2EE il est apparu que J2EE demandait une infrastructure trop importante pour être implémenté correctement, et que les serveurs d'application n'étaient pas tous parfaitement compatibles entre eux.

Bon alors .Net... la le choix du langage se pose ! Je suis à l'aise aussi bien avec l'une et l'autre syntaxe. Je constate que C# est relativement proche de la syntaxe du C++ et que pour VB. Net les incohérences de syntaxes sont corrigées et que les opérateurs du genre &= ont été ajoutés. Donc pas tellement de préférence pour l'un ou l'autre.

Bon alors je me penche sur les perfs... c'est un peu du pareil au même, pas non plus un critère de choix.

Finalement j'ai quand même opté pour VB.Net, pour une seule raison, je trouve que la syntaxe est plus proche du langage naturel...

If [condition] Then est, à mon avis, plus parlant que if ([condition]) {}

[sady1982fr]

Pour ma part, je fais du C++ et du Java en cours. J'ai fait aussi du VB6, de façon autonome. Maintenant, je me suis lancé dans le C# et J#, mais pas encore dans le VB.Net, alors difficile d'en dire quelquechose de construit. Alors voilà ce que j'en pense. Je trouve la plateforme de microsoft, tres bien foutu (c'est génial d'utiliser les mêmes classes quelque soit le langage !) Je ne peut donc faire un comparatif qu'entre C# et J#. Et bien ma réponse va être très simple, je suis plus a l'aise avec J#, parceque j'ai appris la notion d'objet avec Java, et pas C++, donc je navigue plus ou moins en terrain connu avec le J#. Par contre en faisant du C#, il est clair qu'il est d'une grande facilité d'utilisation, même pour les non initiés. Concernant, VB, au temps de VB6, ça a été tres bien pour moi qui n'avais aucune base en programmation, cependant pour avoir lancé VB.Net une ou deux fois, les choses ont l'air de bien avoir changées. donc pas trop d'opinion pour l'instant.

Au final, pour l'instant je reste sur le J# (j'aime beaucoup Java )

Voilà, cependant peut etre que dans deux mois j'aurais changé d'avis .

@+

sady

[jmmolina]

Bonjour,

C# : à choisir si on connaît C/C++ ou Java. C'est mon cas et c'est donc logiquement que j'ai choisi C# pour développer mes applications web en ASP.NET avec WebMatrix. Si je me mets au développement d'applications Windows avec .NET, je ne choisirai pas C++ .NET mais C#. Ce langage est tellement génial qu'il faudrait être fou pour ne pas l'adopter . Bien entendu tout dépend du contexte, quand on repart de zéro, autant prendre le petit nouveau sous son aile

VB.NET : je m'essaie à VB.NET car c'est une évolution majeure de VB. J'aime la POO et VB.NET me contente tout à fait ! Sans compter que VB, VB.NET, VBA... tous ces petits gars sont liés en quelque sorte et il vaut mieux les suivre de près. Plus important je pense que VB.NET est idéal pour les débutants ou les développeurs intermédiaires. Il est simple et puissant, sa syntaxe est plus logique pour un novice car elle est plus littéraire que celle de C# ou C++. Pas besoin de ;, de {} et autres

Donc le choix que l'on fait dépend du contexte, de son niveau, des projets sur lesquels on a travaillé, on doit travailler... Ils ont chacun des avantages et des inconvénients. VB.NET est idéal pour s'initier à la programmation alors qu'un développeur confirmé, souvent avec un background C/C++, choisira C#, logiquement.

JM. Molina

[chatteriekoolkat]

<Petite parenthèse>
Je suis ulcéré de lire - bien que cela soit en partie vrai à la base - que VB est un langage "de débutant", "d'amateur". Je pratique le VB depuis la version 2.0 et je connais des applications conséquentes développées en VB qui tournent sans le moindre bug (logiciels de comptabilité utilisé dans des centres de gestion agréés : d'un autre niveau que les Ciel et autres EBP, je peux vous le dire... ; logiciel de gestion commerciale tournant dans plus de 1500 magasins en France, etc...)
Tout est question de discipline. Ce n'est pas le langage qui fait la qualité du produit final, c'est bien le programmeur (sous-entendu un mauvais programmeur sera toujours plus mauvais qu'un bon programmeur, qqsoit le ou les langages utilisés)
Evidemment il est exclu - à mon humble avis - d'utiliser VB (ancienne génération) pour autre chose que des outils de gestion au sens large. Exit les jeux 3D et autres logiciels de calcul intensif... Il existe des outils mieux adaptés à ce genre de chose !
</Petite parenthèse>

J'utilise aujourd'hui essentiellement VB.NET. Pas par passion mais tout simplement parce que c'est la syntaxe à laquelle je suis le plus habitué (disons que mes doigts trouvent plus vite les touches du clavier quand je code du VB ). De plus certains mécanismes propres à Intellisense ne fonctionnent pas en C# (sauf erreur de ma part) et ils apportent pourtant des gains de productivité appréciables (je suis un inconditionnel de l'autocomplétion)

Mais j'utilise aussi C#, par nécessité. En effet, la majorité des exemples de codes que l'on trouve sur le Net sont en C#. Il a donc été essentiel pour moi de m'imprégner au mieux de sa syntaxe (je connais le PHP et j'ai pratiqué - comme beaucoup - le C/C++ lorsque j'étais étudiant : cela m'a aidé mais j'avoue que je n'ai encore jamais écrit d'application complète en C#...) car il est plus productif d'adapter et d'intégrer des bibliothèques C# dans une solution que de les traduire en VB.NET.

Pour conclure et donner un avis objectif : quel intérêt pour le développeur VB de perdre du temps à apprendre la syntaxe de C#, comme quel intérêt pour le développeur C/C++ à changer de syntaxe pour se mettre à VB.NET ?... Le maître mot est "productivité" et si l'on s'éclate avec son langage de prédilection, il n'y a pas de raison pour en changer !

[Yann]

Comme l'a justement expliqué Vincent, pour répondre à cette question, il faut comprendre l'architecture du FrameWork.
Un premier test c'est évidemmment de décompiler avec ildasm.exe : quel que soit le langage utilisé, c'est le même IL à 99 % (les différences sont triviales, cher modérateur) qui est compilé à la volée et exécuté. DOnc quand qqn vous dis: "moi qui connais .NET, je code en C# parce que c'est plus rapide à l'exécution", vous pouvez être sûr qu'il n'a rien compris à .NET ! Second test: pré-compiler (pre-JIT) votre code et chronométrez...
C#, VB.NET, etc. : tout dépend de quel monde on vient, des goûts de chacun, etc. Mais ceux qui continuent à dire "tout ce qui commence par C, c'est mieux que VB" sont en fait frustrés de ne plus conserver les avantages du C++ sur VB 6.0.

[Rami]

d'accord sur les a prioris C/VB qui n'ont plus lieux d'etre.

Maintenant, sur les performances, les compilateurs de chaques languages n'ont pas les memes settings par défaut et il existe donc des différences de performances suivant les languages et les applications.
Bien sur on peut parametrer la compilation, pour obtenir le meme MIL...
mais si personne n'est la pour dire qu'il existe des différences de perf, personne n'ira toucher aux settings des compilateurs.

attention, les différences de performances ne seront sensibles que dans certains types d'applications. Plus d'info en cherchant dans cet article en anglais

[angiras]

je programme en vb net et

le module de génération de documentation est très pratique

c'est annonce pour la version future de vb net 2004 (net 2.0)

J'ai essaye C# que je trouve trop esoterique avec les }}} on sait jamais ou ca finit

j'ai programmé en vb 4 et vb 6 avant puis vb script (asp)

je voulais me mettre au C# simplement a cause de l'impression que j'avais que microsoft allait laisser tomber vb ... ca n'a pas l'air d'etre le cas

j'active toujours option strict et option explicit , c'est donc strict et explicit si on veut ....

[angiras]

Il nous emmerde encore avec sa gestion des types, ses accolades, ses point virgule et j'en passe.
Je viens encore de passer 2 ans vec 1 projet ATL/com/C++...ahh les conversions (chaines...), unicode, et j'en passe...que de temps perdu.

moi pareil et en plus susceptible a la casse ! ca me les casse
si tu ecris string c'est pas String


je ne veux plus entendre parler de C#

[neo.51]

Pour relancer un peu le débat, j'ai un exemple simple qui fait que je risque de ne jamais basculer vers C# (même s'il m'arrive d'en faire un peu de temps en temps pour le fun )

en asp.net, avec vb.net on gère les évènements de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Public Sub rechercher_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles rechercher.Click

Handles permet d'associer l'évènement rechercher.Click à ma procédure rechercher_Click

Donc quand je déclare ma procédure, en 2 mots j'y associe un évènement d'un webform.

En C# c'est pas tout à fait pareil :

Dans mon InitializeComponent() je dois déclarer toutes mes procédures et y associer les évènements.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

this.DataGrid1.ItemCommand  += new System.EventHandler(this.DataGrid1_ItemCommand);

et c'est aprés que je peux faire ma procédure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public void rechercher_Click(System.Object sender, System.EventArgs e)
{
}

Alors c'est peut-être moi qui n'ai pas su trouver un moyen d'associer un procédure à un évènement "à la volée" mais je trouve la syntaxe C# assez génante et bien moins claire que celle du VB.NET sur ce point là.

[Maniak]

Alors c'est peut-être moi qui n'ai pas su trouver un moyen d'associer un procédure à un évènement "à la volée" mais je trouve la syntaxe C# assez génante et bien moins claire que celle du VB.NET sur ce point là.

Sur ce point-là, oui. Sur ce point-là unikement :)
'Handles machin' est un raccourci pour associer les méthodes gérant des événements dans la même classe, ça c'est bien. Par contre si on veut associer une méthode à un événement d'ailleurs, faut passer par un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AddHandler événement, AddressOf gestionnaire

plutôt similaire à la version C# :)

Sinon, pour rester dans les comparaisons de syntaxe, un autre exemple totalement au hasard :

C# :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public string Toto
{ get { return _toto; } }

VB.NET :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Public ReadOnly Property Toto() As String
  Get
    Return _toto
  End Get
End Property

Kand on a bcp de classes avec chacune son lot de propriétés, ça devient rapidement bien plus lourd k'une ligne de plus aux kelkes endroits ki associent des méthodes à des événements :)

Autre comparaison, pas vraiment liée à la syntaxe cette fois :
C# :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
uint toto = 0;
if ( toto == 0 )
  DoSomething();

VB.NET :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Dim toto As UInt32
If toto.Equals( Convert.ToUInt32( 0 ) Then
  DoSomething()
End If

Si kkn connait un moyen de faire comprendre à VB.NET ke les entiers non-signés ne sont pas des bestioles importées d'amazonie et ke les comparer à des constantes n'est pas anormal, je suis preneur.

Dans le même genre :
C# :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
uint toto = 0, titi = 1;
if ( toto == titi )
  DoSomething();

VB.NET :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Dim toto As UInt32 = 0
Dim titi As UInt32 = 1
If ( toto.Equals( titi ) ) Then
  DoSomething()
End If

Car bien sûr, l'opérateur de comparaison entre UInt32 et UInt32 n'existe pas.


Je passe sur l'absence de clause using très, très pratike pour une gestion de ressources propre. Tout laisser trainer dans un coin en attendant ke le garbage collector daigne faire le ménage, c'est pas terrible. Appeler Dispose à la main partout est mieux, plus lourd, et pas garanti, exceptions obligent. Plus généralement, using permet de simuler l'exécution automatike de code kand un objet passe 'out of scope' (ce k'on peut faire en C++ avec les destructeurs, mais pas en .NET vu k'on n'a aucun contrôle sur le moment où les destructeurs sont appelés). Bien pratike aussi, et pas ke pour la gestion de ressources (ie pour se faire un traceur ki analyse des blocs de code particuliers).

+ la doc automatike (ki arrivera peut-être dans VS.NET2004 oui, mais en attendant on est en 2003 et toutes les entreprises ne vont pas se précipiter pour racheter des licences dans kks mois), + tous les petits avantages spécifikes à la syntaxe C, ke ce soit les opérateurs type += ou ++, ou encore le for surpuissant. Toutes ces petites choses ki rendent le code bien plus compact/clair/lisible (pour peu k'on ne colle pas tout comme un gros crade et k'on exploite correctement la coloration de syntaxe), tout en étant plus performant.


Tout ça pour dire, je peux comprendre k'on trouve la syntaxe VB.NET plus 'claire' (c'est verbeux, y a pas à apprendre le sens de kks opérateurs, même si ça n'a rien de compliké), mais dire ke la syntaxe de C# est plus lourde ke celle de VB.NET en se basant sur un cas particulier, alors ke le reste du temps c'est totalement le contraire (verbeux donc :), là non :)

[neo.51]

Je n'ai jamais dis que la syntaxe C# était plus lourde que la syntaxe VB, j'ai dis que la syntaxe VB.NET était plus claire.

Pour la génération de documentation il y a des outils comme Ndoc qui font ça trés bien.

Revenons sur tes exemples de syntaxe :

C#

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public string Toto 
{ get { return _toto; } }

VB.NET

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
Public ReadOnly Property Toto() As String 
  Get 
    Return _toto 
  End Get 
End Property

ok il y a plus de ligne de code en VB.NET, mais bon quand on utilise Visual Studio l'argument ne tient plus car rien qu'en déclarant la property le squellette se fait tout seul.

Mais au niveau lisibilitée

je trouve qu'un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

End Property

est plus explicite qu'un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

}

Quand on a beaucoup de code je trouve que les end de VB rendent le code plus lisible.

Aprés pour ce qui est de la gestion des type, je suis d'accord avec toi, mais je reste nuancé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
uint toto = 0, titi = 1; 
if ( toto == titi ) 
  DoSomething();

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Dim toto As UInt32 = 0 
Dim titi As UInt32 = 1 
If ( toto.Equals( titi ) ) Then 
  DoSomething() 
End If

ok en VB.NET c'est bien moins pratique et ça peu trés vite devenir trés chiant. Mais on pourra pas reprocher à VB.NET de pas être objet

+= existe en VB.NET, pas ++

P.S : maniak arrettes avec tes "k" s'il te plait et lis tes mp

[Maniak]

Je n'ai jamais dis que la syntaxe C# était plus lourde que la syntaxe VB, j'ai dis que la syntaxe VB.NET était plus claire.

Et 'assez gênante', c'est surtout ça ki m'a fait tiker :)

Pour la génération de documentation il y a des outils comme Ndoc qui font ça trés bien.

Notamment kand ça utilise les fichiers XML générés automatikement grâce aux tags /// du C# :)

ok il y a plus de ligne de code en VB.NET, mais bon quand on utilise Visual Studio l'argument ne tient plus car rien qu'en déclarant la property le squellette se fait tout seul.

Si tu utilises les assistants peut-être. Et en ASP.NET, utiliser les assistants est un choix de vie ki est loin, très loin, d'être le mien. Parce ke gagner kks secondes avec ce genre de choses pour en perdre plein d'autres avec toutes les saletés ke ça pond, c'est pas rentable :)

Mais au niveau lisibilitée

je trouve qu'un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

End Property

est plus explicite qu'un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

}

Quand on a beaucoup de code je trouve que les end de VB rendent le code plus lisible.

Kestion de goût pour ça. D'habitude aussi probablement.
Perso, les accolades, du moment k'elles sont bien alignées verticalement et ke le code est bien aéré, ça ne me pose aucun pb de lisibilité. Au contraire. Tu vois un }, tu remontes les yeux et tu tombes sur le { correspondant. Rapide et précis :)

À condition de ne pas avoir 10 écrans entre une accolade d'ouverture et une de fermeture, mais là ça rentre dans le principe d'avoir du code propre :)

S'il y a un point sur lekel je ne discuterai pas, c'est bien ke la syntaxe C permet de faire du code vraiment illisible. Mais avec un minimum de rigueur (k'il vaut mieux avoir kand on est développeur), elle n'a rien à envier à la syntaxe du VB niveau clarté, tout en étant plus légère.

Aprés pour ce qui est de la gestion des type, je suis d'accord avec toi, mais je reste nuancé :

ok en VB.NET c'est bien moins pratique et ça peu trés vite devenir trés chiant. Mais on pourra pas reprocher à VB.NET de pas être objet :lol:

Ben si justement :)
VB.NET a été proclamé haut et fort comme étant orienté objet à fond, au même titre ke C++/C#/Java/Whatever. Et kand on veut s'en servir pour faire de l'OO, on tombe sur des couches de lourdeur assez phénoménales.

Donc bon, si on parle de programmation procédurale, ok, la plupart des inconvénients de VB.NET par rapport au C# disparaissent. Surtout ke le code C/C# en procédural a tendance à être immonde. Mais vu ke perso je ne parle ke de programmation objet... :)
(c'est un peu un des principaux intérêts de .NET après tout :)

+= existe en VB.NET, pas ++ :wink:

Ah, pas vu pour le +=, my bad :)
Mais ça ne marche pas pour les gestionnaires d'événements :)

P.S : maniak arrettes avec tes "k" s'il te plait et lis tes mp

Vu, mais ça va être (très) difficile, c'est génétike, j'ai une sainte horreur des 'qu' collés inutilement partout dans cette langue (et mon pseudo n'est pas un hasard). Je n'en mets ke dans les textes 'pro' (et ça n'a rien à voir avec le style SMS ke je ne peux pas voir en peinture. trouve-moi un endroit où j'ai mis une abréviation à la con :)

[Bazoom]

Salut neo,

Par contre, il y a un point qui pour moi est trés important qui n'a pas été abordé. VB.NET est un langage propriétaire de microsoft donc tous les outils pour programmer en VB.NET seront fournis par microsoft et donc par conséquent pour .NET.

C'est sûr? Pourtant SharpDevelop, qui est en open source, permet de faire du C# ET du VB.Net.

Où peut-on trouver un historique de la création de C# ? Pour ma part, ce qui m'a étonné le plus en découvrant .Net ce n'est pas la coexistence de C# et VB, mais celle de C# et C++, deux langages OO hérités de C.

[neo.51]

Apparement les choses ont évolués

en tout cas le C# est déposé en tant qu'ISO pas le VB.NET.

Pour ce qui est la coexistance de VC++.NET et C# c'est surtout pour faire migrer les codeurs VC++ vers .NET

[Maniak]

Pour ce qui est la coexistance de VC++.NET et C# c'est surtout pour faire migrer les codeurs VC++ vers .NET :wink:

Pour ça il y a le managed C++. C# est plutôt pour attirer les développeurs Java :)

(ki sont semble-t-il particulièrement têtus vu k'il a fallu leur faire un J# globalement inutile, juste histoire d'être encore plus proche, et c'est même pas dit ke ça suffise :)