Discussion :

[smyley]

Après je trouve que VB est quand même mieux intégrer à Visual Studio.

Hein ?

L'intellisens

Double hein ? tu lui reproches quoi à l'intellisens de Visual C# ?

la correction des erreurs sans avoir à recompiler

c'est possible aussi en C# et C++ ...

le fait de pouvoir définir des namespace par défaut au projet,

Personnellement je n'en ai jamais eu besoin ...

[maa]

c'est possible aussi en C# et C++ ...

Pas par défaut en tout cas. Ou alors une option m'échappe ? Avec Resharper oui, mais ça ralentis pas mal.

[smyley]

Je l'ai toujours fait en C# et C++ avec VS2005 sans toucher à aucune option. Je lance un programme, je le met en pause, je modifie mon code et je le "resume" (comment on dit ça en français ? ) et là il applique les changements au code et continue l'exécution du programme ...

[maa]

non tu n'as pas compris.

Je ne parle pas d'éditer du code à l'exécution mais du fait que Visual Studio souligne les erreurs au fur et à mesure que l'on écrit. Avec C#, il faut recompiler pour avoir la listes des erreurs.

[tomlev]

Un des "avantages" de VB c'est les objets de l'assembly Microsoft.VisualBasic et le namespace My (Computer, Network, Mouse...). Mais je me demande bien pourquoi ils ont rendu ça spécifique à VB... rien n'empêche de référencer cet assembly dans un projet C# et d'utiliser ces objets !

[tomlev]

non tu n'as pas compris.

Je ne parle pas d'éditer du code à l'exécution mais du fait que Visual Studio souligne les erreurs au fur et à mesure que l'on écrit. Avec C#, il faut recompiler pour avoir la listes des erreurs.

Ah ? pas chez moi... la plupart des erreurs s'affichent au fur et à mesure.

[smyley]

Ahhhhh
Et ça sert à quoi ?
Et puis oui en plus ... les erreurs qu'il montre VB de cette manière ce ne sont que les erreurs de syntaxes ? parce que si c'est le cas, Visual C# 2005 le fait aussi ...

[maa]

Et puis oui en plus ... les erreurs qu'il montre VB de cette manière ce ne sont que les erreurs de syntaxes ?

non, toutes les erreurs que l'on obtiendrait si on compilait.

Et ça sert à quoi ?

à gagner du temps.

[smyley]

Ouai bon en même temps dans un projet bien organisé la compilation ne prend que 5 secondes. Chaque langage a ces avantages et ces inconvéniants ...

[maa]

Non là il faut avouer... c'est +1 pour VB (même si j'en suis pas un féru défenseur). Ca prend pas mal de temps si tu as un gros projet et que tu dois le compiler 3 ou 4 fois avant d'avoir corrigé toutes les erreurs.
Mais pire que tu t'en rend compte à la compilation que tout une parti de code est à revoir à cause d'une erreur de conception qui ne compile pas c'est un peu dômmage... il vaut bien mieux corriger l'erreur en temps réel.
J'attends avec impatience la sortie de Resharper pour VS 2008 pour combler ce manque.

[smyley]

En même temps choisir un langage pour une seule fonctionnalité ... et puis il y a toujours ReSharper comme tu dit, donc rien ne nous empèchera de rester dans notre C#

[Kelpan]

VB.NET a hérité de l'expérience de ces prédécesseurs.

- Les paramètres optionnels
- La liaison tardive
- ParamArray
- Redim preserve
- ... et d'autres que j'oublie surement

Si VB6 n'était pas vraiment un langage très structuré, je pense que vb.net est devenu un langage qui mérite d'être pris en compte pour de grand projet.

Actuellement, nous sommes arrivés au point ou les développeurs sont d'accord pour dire que les langages s'equivalent, malgré quelques irreductibles qui considèrent que le langage qu'ils ont choisi est le meilleur.

Personnellement, je suis VBiste et j'ai une légère préférence pour VB

[SaumonAgile]

Juste pour en revenir aux paramètres optionnels, j'utilise une technique dans mon projet InfoBox qui permet d'avoir un pseudo comportement optionnel. Les paramètres obligatoires (le message) est un paramètre standard, tout le reste passe dans un params.
Le tout associé à une bonne documentation, et tout le monde est content.

[SaumonAgile]

Juste pour réagir à ce que tes arguments :

- Les paramètres optionnels

Peuvent être pratiques mais une surcharge de méthode utilisant une valeur par défaut est viable aussi. C'est dans ta liste, à mon avis, la fonctionnalité la plus intéressante.

- La liaison tardive

Discutable, il y a des avantages et des inconvénients à ce concept.

- ParamArray

params en C#

- Redim preserve

A t'on encore besoin de réallouer des array à l'heure des collections typées ?
Je ne le pense pas.

Ceci dit, je respecte ton point de vue et apprécie au plus haut point que pour une fois, quelqu'un à le courage de dire "je préfère VB.NET" plutôt que "VB.NET c'est mieux".

[tomlev]

En fait, je pense que VB.NET est plus ou moins équivalent à C#, à condition d'utiliser Option Strict On. Sinon c'est limite dangereux, il donne même pas un warning pour des trucs qui devraient être complètement interdits !

[TSalm]

et pis d'abord, y'a pas un langage meilleurs qu'un autre

Ca dépends de ce qu'on doit faire, de la taille du projet, et si on est à l'aise avec

Mais perso, je suis d'accord, j'adoooore C#
Même si je trouve que le D est bien meilleurs

[smyley]

Même si je trouve que le D est bien meilleurs

Heureusement que ce langage est toujours en cours de conception ...

[SirJulio]

VB.NET a hérité de l'expérience de ces prédécesseurs.

- Les paramètres optionnels
- La liaison tardive
- ParamArray
- Redim preserve
- ... et d'autres que j'oublie surement

<troll incoming !>
-l'operateur d'[in][de]crementation.

Ha non ... =D

Plus serieusement, de toutes facons, pour les programmeurs .Net, la finalité est la meme, puisqu'on programme tous sur le meme langage in fine. De fait, je pense que VB.Net est un bon langage en soit (apres je n'aime pas du tout la syntaxe totalement illisible (subjectif inside)), et on peut faire au moins autant de chose qu'en C# (apres c'est le Fx qui va limiter de toutes facons).

Juste pour note, les late-binding implicites, je trouve plutot tres dangeureux qu'un vrai avantage.

[Kelpan]

Juste pour note, les late-binding implicites, je trouve plutot tres dangeureux qu'un vrai avantage.

Ce n'est pas le fait que la langage permette les liaisons tardives qui est dangereux, c'est l'utilisation que le développeur en fait.
Un développeur se doit d'être rigoureux et ne pas programmer n'importe comment.
Le fait de ne pas tester si le diviseur est égale à 0 avant d'effectuer une division est tout aussi dangereux. Pourtant C# ne t'oblige pas à le faire.

Le réel problème que je constate actuellement, c'est que beaucoup de monde se prétend développeur à partir du moment qu'il connait le langage. (qui deviennent de plus en plus accessible).
Combien de fois, ai-je vu quelqu'un poser un problème sur ce forum avec un source sans que mon cerveau se retourne tellement il y a de choses aberrantes ? ... pas beaucoup...

Franchement, je ne suis pas d'accord pour dire que c'est le langage qui doit s'adapter à ces "pseudo-développeurs".

[SirJulio]

Je reformule, dangeureux n'etait sans doute pas le bon terme.

Je trouve qu'il est risqué de masquer un appel tardif, surtout connaissant le surcout en performance que coute ce type d'appel. Je ne vois meme pas l'interet (a part l'aspect candy de la chose) d'autoriser ce genre d'appel. Ou comme on l'a vu dans ce thread, les problemes de conversions implicites de pointeurs managés (A& = B& passe à la compil mais plantera à l'execution).

Bref, comme tu dis la rigueur est importante, est dans ce cas quel est l'interet de cette option Strict desamorcable en VB (ce n'est pas un troll. y a t'il une raison historique ?).