Que choisir ? C# , VB.NET, C++, Delphi ? pourquoi ?

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#.

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.

<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 !

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

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à.

Envoyé par neo.51

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

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

Envoyé par 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.

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

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 ++

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

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

Envoyé par neo.51

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

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