Discussion :

[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 :)

[neo.51]

(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

tout à fait et je pense que la majorité des développeur java qui se mettent à .NET migreront directement vers C#

[Maniak]

tout à fait et je pense que la majorité des développeur java qui se mettent à .NET migreront directement vers C#

Prions ensemble mes frères, pour ke tel soit l'avenir :)

[linkOne]

Ca me tire la larme ça les gars

[Maniak]

Ca me tire la larme ça les gars

la larme incendie ?

/me cherche le smiley 'je sors'

/me ne trouve pas

/me se rabat sur

[dadg]

Qu'une chose à dire ! Je programme en VB.net parceque je n'ai pas le choix ! si non je ne programmerais ni en VB.net ni en C# !
j'éspère ne pas trop vous avoir vexé !

[Xzander]

Le premier langage de prog que j'ai appris est le VB6. J'ai ensuite passé à VB.NET. Après quelques mois, j'ai essayé C# et je ne le regrette pas. Personnellement, je préfère } à End If. Je suis conscient que } n'est pas très instinctif, surtout au début, mais on s'y habitue rapidement. J'adore écrire en code ultra condensé alors C# me sert bien.

[FRED.G]

Moi j'ai commencé sans faire exprès avec VBA, puis comme ça m'a plu, je suis passé à VB.NET. Et là je fais découvrir la prog à mon petit frère avec C# directement.
Car C# est le langage privilégié par la communauté .NET pour les sources et autres tutos.

[FremyCompany]

Ce que tu dis est ridicule...
Un code fait en C# est portable sans problème en VB.NET (mais pas nécéssairement inversément car Optional n'existe pas en C#, etc)
==> VB .Net est plus riche et plus simple à comprendre.

Je ne dis pas que les langages en { ... } sont mauvais (je suis fan de programmation JavaScript, par exemple) mais C# permet moins de liberté au developpeur que VB .Net, et surtout du point de vue de l'usage COM...

Je t'en prie, fait moi un beau code qui utilise le WebBrowser en C#... Tu seras vite bloqué car l'API (faite en VB .Net) qui relie COM et .NET est limitée (pas de submit de formulaire, pas accès à la fonction eval de JS, ...), alors qu'en VB .Net je passe par l'Active X non typé et j'ai accès à toutes les possibilités offertes par IE.

On m'a bien fait le coup de yield return xxx; Alors pour clore cette polémique idiote, voici ma réponse :

Code VB :

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

1
2
3
4
5
6
Public Function UsingYield() as List(Of Integer)
   UsingYield = new List(Of Integer)
   For X as Integer = 0 to 10
      UsingYield.Add(X)
   Next
End Function

La deuxième chose est qu'on dit que VB .Net est plus propice à l'erreur, et je suis pas d'accord... Les erreurs faites en VB .Net à cause de sa lacheté ne sont pas causée par les developpeurs VB .Net eux-mêmes, mais par les développeurs qui connaissent C# et qui sont obligés de développés en VB .Net. Ils n'ont alors pas l'habitude de gérer VB comme il faut et font des fautes "de débutant".

[FRED.G]

Ce que tu dis est ridicule...

Oulà, pense à calmer tes ardeurs mon petit. Pas un seul de tes arguments ne contredit mon propos qui n'est que le constat d'un fait et surement pas un jugement de valeur ! Je ne vais pas me répéter, il tient en une seule phrase et tu es hors sujet.

[Maniak]

On m'a bien fait le coup de yield return xxx; Alors pour clore cette polémique idiote, voici ma réponse :
[snip]

Et c'est quoi au juste le rapport en ça et le yield de C# ?

La deuxième chose est qu'on dit que VB .Net est plus propice à l'erreur, et je suis pas d'accord... Les erreurs faites en VB .Net à cause de sa lacheté ne sont pas causée par les developpeurs VB .Net eux-mêmes, mais par les développeurs qui connaissent C# et qui sont obligés de développés en VB .Net. Ils n'ont alors pas l'habitude de gérer VB comme il faut et font des fautes "de débutant".

Bizarrement, les développeurs C# que j'ai vus qui doivent faire du VB.NET font du code bien plus propre/clair/solide que les développeurs VB.NET 'purs'. Tout bonnement parce qu'ils appliquent les règles d'un langage plus 'strict' et évitent du coup les problèmes liés aux fonctions surpuissantes de VB.NET telles que... la conservation de l'héritage de VB6 et... euh... bah c'est tout en fait. Et vu que l'héritage de VB6 est une abomination sans nom dont l'utilisation devrait donner envie de vomir...

Blablabla COM blablabla, oui ok, mais heureusement on peut faire une petite DLL en VB.NET pour faire un wrapper autour de ces appels COM, en exposant ensuite une interface typée bien propre, utilisée par le reste de l'appli en C#. Et c'est bien dommage que MS ne se soit pas fatigué à le faire. D'autant que comme ça on peut s'assurer que les ressources sont bien libérées comme il faut, à un seul endroit, contrairement à ce qui a tendance à être fait par des dévs VB qui éparpillent les appels et créations d'objets COM aux quatres coins de l'appli.

(et hop, le topic repart pour une nouvelle boucle :)