Discussion :

[davcha]

De toute façon, ici il n'est pas question d'avoir fait le choix C# parce que c'est mieux que VB.NET, il est question d'avoir fait le choix C# parce que c'est ce qui est le plus utilisé pour les sources/tutos de la communauté .NET

Alors, n'importe quel code fait en C# est peut-être portable sans problème en VB.NET, mais là n'est pas la question.
Un français qui veut apprendre l'allemand se base sur des traductions allemand/français, pas sur des traductions anglais/allemand.

C'est une question de facilité de compréhension et, donc, de gain de temps.

[Nuncyco]

Personnellement, VB.NET et C# offrent tous les 2 des avantages. Mais je trouve VS plus "dynamique" en VB (intellisense plus présent), le compilateur C# offrant lui la possibilité de sniffer le code et vérifier les variables inutilisées etc.

Au niveau performance, il y a forcement des différences. Restent à savoir si elles sont critiques.

Mais je suis désolé, C# et VB.NET sont différents. Ils n'offrent dans l'absolu pas les mêmes possibilités.
Ils intègrent des types différents par exemple. Tous deux sont compatbles avec le CTS du framework, mais vous pouvez trés bien développer une classe VB.NET non compatible avec le CLR du moment que les méthodes d'accès et de retour sont compatibles. Les méthodes / attributs non compatibles doivent avoir une portée privée pour régler ce genre de problème.

Dans tous les cas, les différences entre langages ne sont que minimes pour 95% des développement IMHO.
Whidbey va intégrer un module de génération de doc pour VB.NET, ce qui diminuera encore les argumentations objectives VB.NET vs C#.
Le reste est affaire de gout...

[Moonheart]

VB.Net et C#

Ahhh le débat usuel... Et aussi l'étude que je mène plus ou moins à mon travail pour une migration technologique.

Essayons de résumer:

Avantages de VB.Net:
- Possibilité de mettre les gestions de type en transparence
- Similarité avec le langage VB

Avantages de C#
- Gestion de la documentation approfondie
- Possibilité de surcharger les opérateurs
- Similarité avec le langage C++

Et puis... et puis ca s'arrete là.

L'avantage de C# serait d'obliger à une gestion stricte des types?

C'est un point de vue, et d'un certain coté je le partage, car ceux qui pensent que la gestion des types n'existe pas sous VB.Net se fourrent le doigt dans l'oeil jusqu'au coude. La gestion des types EXISTE sur VB.Net!

Concrètement que se passe-t'il quand vous faitre une opération du style "<variable string> = <valeur numérique>" par exemple en VB.Net?
A la compilation, ca passe... Mais en fait, c'est le compilateur VB qui prends en charge le boulot... Il voit un nombre, et le converti en chaine de caractère en utilisant des casts de la même manière qu'en C#!!!
Mais c'est a la fois un avantage et un inconvénient:
- avantage parce que c'est libérateur pour la tête du programmeur
- inconvénient parce que le compilateur le fait justement sans rien vous demander!!!! Et si vous aviez besoin que le nombre utilise le séparateur décimal "." au lieu du séparateur "," ? Et si vous travaillez dans un format numérique avec des séparateurs de millieurs? Et si vous avez besoin de n chiffres obligatoires après la virgule? Et ben vous voila obligé de réanalyser la chaine de caratère retournée dans la variable et la retraiter pour obtenir le format voulu... hem... pas glop et ce type problème se porte dans tous les types de conversion, pas forcément avec les chaines de caractère
Pour eviter ce genre de confusion de traduction, ou le compilateur traduit les types de données en utilisant une méthode inadaptée, vous devez donc utiliser des casts et des fonctions de conversion en VB... mais si vous mélangez cela a des conversion "implicites" faites par le compilateur, vous rendez purement et proprement votre code imbuvable à la relecture pour les développeur futurs qui auront a retravailler sur votre programme... ce qui fait de vous un mauvais dévelopeur, même si vos collaborateur ne s'en apperceveront peut-etre que dans quelques années, quand ils auront a faire évoluer votre appli sans votre aide.

Alors oui, VB est "confortable" par sa gestion implicite des conversations, mais c'est aussi une très mauvaise habitude que de le laisser faire... Et d'ailleurs, Microsoft ne s'y ait pas trompé et désirant faire de son langage un langage capable d'interresser les développeurs les plus sérieux, il a inclut dans la version .Net de VB une option qui permet de neutraliser la gestion implicite des casts et conversion (elle est accéssibles dans les propriétés de votre projet... il suffit de cocher la case "Option Strict" que je vous recommande de cocher a chaque fois)

Typiquement, c'est vrai vous perdez un peu de temps a caster vos types, mais cela evite bien des erreurs et rends le code bien plus clair a reprendre pour les autres informaticiens... et vous vous épargnez aussi des problèmes de conversions mal faites qui sont source de dégradation de performances.
Car si le cast/la conversion prends autant de temps à l'éxécution qu'elle soit explicite ou implicite, une mauvais conversion implicite suivie d'un traitement pour la corriger est elle bien plus longue a éxécuter qu'une conversion explicite bien faite du premier coup.

Les performances sont meilleurs sur le traitement de certains types dans un langage ou dans un autre?

Faux!!! Car VB.Net et C# ont EXACTEMENT les mêmes performances!!!!
Toutefois... a condition d'utiliser les véritables types .Net

Exemple: N'utilisez pas Integer, Long, Double de VB.Net ni int, flt de C#, mais plutot les types int32 et autres de .Net... la raison est simple: Le framework .Net ne reconnait pas ces types!!!!!!
Quand vous allez donc utiliser un "Long", le compilateur VB va en fait transformer votre Long en un type .Net qui est lui, supporté par le Framework... résultat, à l'éxécution, si le type que vous utilisez n'est pas très aisément transposable en un type .Net, le programme va convertir votre variable en un autre type a CHACUNE de ses utilisations... d'ou perte de performance.

C'est pour cela que VB gère plus vite ses entiers que C#: les types entiers de VB sont plus proche des types entiers de .Net que ne le sont ceux de C#, par contre, C# travaille plus vite sur ses flottant, car les types flottants de C# sont plus proches des types flottant de .Net que ceux de VB.
PAR CONTRE, si vous prenez l'habitude dans vos programmes de déclarer vos variables avec les types .Net au lieu des anciens types de votre langage (c'est a dire System.Int32 au lieu de int en C#, par exemple) vous n'aurez aucune différence de performance entre VB et #... Héhé bien évidement puisque le compilateur n'introduit alors plus aucune conversion!!!
De plus, vous gagnerez en temps d'éxécution tout court, car il est plus rapide pour le framework d'éxécuter des opérations sur les types basiques de .Net que sur ceux de votre langage. Vous pouvez donc gagnez en temps d'éxécution simplement en arretant d'utiliser les anciens types de VB et C.


Conclusion:

Pour un développeur "casual", c'est a dire une personne qui développe peu, ou dans un contexte seulement semi-professionel, il est sans doute bien mieux d'utiliser un VB.Net qu'un C#
Plus souple au niveau des conversions, vous n'aurez de plus aucune des inconvénients des casts implicites si vous n'avez pas de gros besoin de développement complexes et minutieux ni d'autres personnes suceptibles de devoir retravailler votre code dans quelques mois/années.

Pour un usage professionnel informatique de haut niveau (=ingénérie informatique plutot que développement à la petite semaine) ou les types de données utilisés doievent être gérés strictement et/ou les développement ne sont pas l'affaire d'un seul homme et/ou l'applicatif aura besoin d'être maintenu sur une très longue durée, le C# est bien supérieur.
Déjà car il ne LAISSE pas les développeurs s'adonner à la flemmardise nocive dans un tel contexte des casts/conversions implicites, mais aussi parce que le système d'auto-génération de documentation est un outil d'une valeur INESTIMABLE pour la reprise de code ou le développement distribué.

L'un dans l'autre, si vous hésitez encore, il vous reste l'argument du "Le langage X.Net ressemble plus au langage X que j'ai déjà utilisé avant" pour trancher, mais c'est là un argument de tout dernier ressort qui ne doit entrer en compte que si les arguments si dessous se retrouvent EXACTEMENT a égalité. Surtout que VB.Net est très loin d'être aussi similaire a VB qu'il y parait en premier ressort... et que C# lui même possède des différences notables et légèrement traitre avec C/C++

[Maniak]

Essayons de résumer:

Avantages de VB.Net:
- Possibilité de mettre les gestions de type en transparence

Avantage ?

- Similarité avec le langage VB

Avantage ?

Concrètement que se passe-t'il quand vous faitre une opération du style "<variable string> = <valeur numérique>" par exemple en VB.Net?
A la compilation, ca passe... Mais en fait, c'est le compilateur VB qui prends en charge le boulot...

Pas le compilateur. Le runtime. Si le compilateur prenait ça en charge, les erreurs seraient interceptées à la compilation. C'est ce ki se passe avec C# (et tous les langages 'stricts'). Le problème avec VB.NET sans Option Strict est ke justement, on se retrouve avec des bugs liés aux types (ki ne provokent pas forcément des plantages, ce sont les pires) k'on met trois plombes à détecter, trouver et corriger.

Avec Option Strict ça va bien mieux à ce niveau, sauf ke du coup, kand on veut mettre 0 dans un entier non-signé, il faut passer par un Convert.ToUInt32 parce ke sorti d'Integer, le compilo est perdu.

- avantage parce que c'est libérateur pour la tête du programmeur

C'est libérateur pour les feignasses oui :)
Maintenir un minimum de rigueur, c'est pas la mort. Après tout développeur est encore un métier, pas un loisir. La 'libération' en kestion provoke une perte de temps assez monumentale dès ke ça commence à coincer.

Avantage ?

[snip la suite]
Rien à redire, suis plutôt d'accord :)
Sauf pour donc l'Option Strict, ki certes évite les problèmes de conversions implicites, mais est d'utilisation particulièrement lourdingue. Largement de koi décourager ceux ki voudraient l'utiliser.

Les performances sont meilleurs sur le traitement de certains types dans un langage ou dans un autre?

Faux!!! Car VB.Net et C# ont EXACTEMENT les mêmes performances!!!!
Toutefois... a condition d'utiliser les véritables types .Net

Moui, faudrait vérifier ce ki se passe au juste du côté de C# pour les conversions k'il fait implicitement et ke VB.NET nécessite de faire explicitement.

Toujours avec mon exemple de la constante 0 à stocker dans une variable UInt32, VB.NET a donc besoin d'un appel à Convert.ToUInt32 (donc appel de fonction, traitement et tout) tandis ke C# le fait tout seul. Et je doute un peu k'en interne, il fasse le même appel de fonction :)

Pour ce ki est de la correspondance entre les types VB.NET/C# et les types du CLR, il y a un mapping pour tous, donc ça ne pose pas de problème. Juste ke VB.NET n'a pas de types 'perso' pour tout (entiers non-signés donc :), et ke c'est d'une lourdeur crasse dès k'on veut utiliser ça :)

Mis à part ça, les correspondances entre ces types se font à la compilation en MSIL. Aucun traitement supplémentaire si on utilise une variable Integer ou Int32. Encore heureux d'ailleurs :)

Après, utiliser des types ki n'existent pas directement dans le CLR, évidemment c'est autre chose. Mais je n'ai pas d'exemple ki me vienne à l'esprit là tout de suite :)

C'est pour cela que VB gère plus vite ses entiers que C#: les types entiers de VB sont plus proche des types entiers de .Net que ne le sont ceux de C#, par contre, C# travaille plus vite sur ses flottant, car les types flottants de C# sont plus proches des types flottant de .Net que ceux de VB.

Mmh... int = Integer = Int32. Aucune différence de ce côté là.
Plus simplement, C# propose des types pour toutes les tailles, de 8 à 64 bits.
sbyte/byte/short/ushort/int/uint/long/ulong, chacun de ces types a un ékivalent direct dans le CLR (ils ont été développés en parallèle, c'est un peu normal après tout).

PAR CONTRE, si vous prenez l'habitude dans vos programmes de déclarer vos variables avec les types .Net au lieu des anciens types de votre langage (c'est a dire System.Int32 au lieu de int en C#, par exemple) vous n'aurez aucune différence de performance entre VB et #... Héhé bien évidement puisque le compilateur n'introduit alors plus aucune conversion!!!

La différence de perfs à la compilation est négligeable. La différence à l'exécution est de toute façon inexistante, vu k'une fois en MSIL, les types sont les mêmes, C# comme VB.NET.

Conclusion:

Pour un développeur "casual", c'est a dire une personne qui développe peu, ou dans un contexte seulement semi-professionel, il est sans doute bien mieux d'utiliser un VB.Net qu'un C#
Plus souple au niveau des conversions, vous n'aurez de plus aucune des inconvénients des casts implicites si vous n'avez pas de gros besoin de développement complexes et minutieux ni d'autres personnes suceptibles de devoir retravailler votre code dans quelques mois/années.

À condition de ne pas compter faire ça de manière plus sérieuse plus tard, parce k'on prend un sacré paket de mauvaises habitudes au passage. Mais pour des non-développeurs ki ont juste besoin de pondre un petit bout de code à un instant T, VB.NET est plus pratike, certes.


Bref, globalement d'accord sur le fond, pas totalement sur l'importance des problèmes causés par le laxisme de VB.NET, assez pas d'accord sur les histoires de types de données (ça se teste vite en débuggant et en affichant le code asm après tout, et utiliser int en C# n'a pas le moindre impact sur les perfs, de même k'Integer en VB.NET, en revanche il ne faut pas avoir besoin d'utiliser un ékivalent à UInt32 en VB.NET), mais l'essentiel reste le fond :)

[Moonheart]

Essayons de résumer:

Avantages de VB.Net:
- Possibilité de mettre les gestions de type en transparence

Avantage ?

Pour le développement d'application à faible durée de vie, cela réduit un peu les temps de développement et tout est bon a prendre pour réduire les couts dans une entreprise.

- Similarité avec le langage VB

Avantage ?

Pour une entreprise qui a des développeurs VB et non C dans ses murs et veux passer a .Net, cela réduit le temps homme nécessaire à la prise en main de la technologie.

Concrètement que se passe-t'il quand vous faitre une opération du style "<variable string> = <valeur numérique>" par exemple en VB.Net?
A la compilation, ca passe... Mais en fait, c'est le compilateur VB qui prends en charge le boulot...

Pas le compilateur. Le runtime. Si le compilateur prenait ça en charge, les erreurs seraient interceptées à la compilation.

Un compilateur c'est un outil qui recoit un code en entrée et réagit de deux facons possible soit il traduit, soit il remonte une erreur.
Ce n'est donc pas parce qu'il n'en remonte pas qu'il ne prends pas en charge quelque chose: il peux l'avoir tout simplement traduite.

Et en effet, si tu regardes l'IL générée par le compilateur VB.Net (en l'absence de l'option "Strict") correspondant au code "<variable string>=<valeur numérique>" tu trouveras en sortie un code ressemblant à "<varitable string>=<variable numérique>.ToString" ----> Le compilateur à rajouté le cast manquant, et donc pris en charge le dit cast.

Le runtime, lui ne verra AUCUNE différence entre cette instruction et sa version castée de C# une fois compillée avec le compilateur C#... le travail qu'il fera sera le même des deux cotés.

Le problème avec VB.NET sans Option Strict est ke justement, on se retrouve avec des bugs liés aux types (ki ne provokent pas forcément des plantages, ce sont les pires) k'on met trois plombes à détecter, trouver et corriger.

Ca dépend des développeurs. Pour un développeur rodé sur VB, la compréhension des casts implicites est aussi évidente que de placer des casts explicites pour un développeur Java/C++ expérimenté.

Avec Option Strict ça va bien mieux à ce niveau, sauf ke du coup, kand on veut mettre 0 dans un entier non-signé, il faut passer par un Convert.ToUInt32 parce ke sorti d'Integer, le compilo est perdu.

Le compilateur n'est perdu avec aucun type de donné venant de l'ancien langage et du domaine .Net, c'est d'ailleurs l'une des règles de bases des compilo .Net

Le seul truc, c'est comme je l'ai expliqué, pour des soucis de performances, il vaut mieux n'utiliser que les types .Net mais cela n'est pas propre à VB.Net... en C# aussi, l'utilisation de certains anciens types de données peuvent réduire les performances

- avantage parce que c'est libérateur pour la tête du programmeur

C'est libérateur pour les feignasses oui
Maintenir un minimum de rigueur, c'est pas la mort. Après tout développeur est encore un métier, pas un loisir. La 'libération' en kestion provoke une perte de temps assez monumentale dès ke ça commence à coincer.

Je partage ce point de vue, mais il faut comprendre qu'en informatique, on ne travaille pas qu'avec des informaticiens pur et durs.
Il y a aussi des gens "reconvertis" en informatique, qui ne sont pas aussi à l'aise avec les languages strict que d'autres... pourtant ces "informaticiens" là ne sont pas remplacables pour autant par des hard-coders car ils ont souvant des compétences-métier dures a trouver chez les informaticiens.

Il faut donc faire avec, et parfois savoir faire preuve de souplesse afin de livrer les demandes en temps et en heure. Parce que vois-tu, si les utilisateurs qui sont en bout de chaine ont besoin d'un outil pour dans deux semaines parce que dans deux semaines, c'est la livraison de la comptabilité annuelle de la société, crois-moi qu'il vaut mieux gagner un jour dans ces deux semaines que gagner 2 semaines dans 3 mois.
Un jour de retard sur un bilan annuel d'une société multinationale = de 100.000 euros d'amende à la liquidation de la société par la justice. 2 semaines de galère de reprise de code par un ingénieur informaticien de haut vol = 10.000euros grand max, le calcul est vite fait.

Faux!!! Car VB.Net et C# ont EXACTEMENT les mêmes performances!!!!
Toutefois... a condition d'utiliser les véritables types .Net

Moui, faudrait vérifier ce ki se passe au juste du côté de C# pour les conversions k'il fait implicitement et ke VB.NET nécessite de faire explicitement.

Oh c'est facile a vérifier... suffit de regarder l'IL générée par les deux compilo. Dans les deux cas il est évident du gain d'utiliser les types .Net

Toujours avec mon exemple de la constante 0 à stocker dans une variable UInt32, VB.NET a donc besoin d'un appel à Convert.ToUInt32

C'est faux, car il suffit de placer le suffixe indiquant que ton 0 est un 0 d'UInt32 pour n'avoir a utiliser aucune fonction de conversion.

Mmh... int = Integer = Int32. Aucune différence de ce côté là.

Je ne parlais pas des entiers non-signés sur 32 bits, par chance ils sont les mêmes partout... Mais a vrai dire, c'est juste une coincidence heureuse.

[Maniak]

Avantages de VB.Net:
- Possibilité de mettre les gestions de type en transparence

Avantage ?

Pour le développement d'application à faible durée de vie, cela réduit un peu les temps de développement et tout est bon a prendre pour réduire les couts dans une entreprise.

- Similarité avec le langage VB

Avantage ?

Pour une entreprise qui a des développeurs VB et non C dans ses murs et veux passer a .Net, cela réduit le temps homme nécessaire à la prise en main de la technologie.

Yup et yup. On est d'accord, mais ça reste des cas particuliers, et orientés sur le court terme :)

Et en effet, si tu regardes l'IL générée par le compilateur VB.Net (en l'absence de l'option "Strict") correspondant au code "<variable string>=<valeur numérique>" tu trouveras en sortie un code ressemblant à "<varitable string>=<variable numérique>.ToString" ----> Le compilateur à rajouté le cast manquant, et donc pris en charge le dit cast.

Vi, le compilo prend en charge le code devant gérer les types, mais c'est le runtime ki paye le prix à l'exécution.
Enfin là on joue sur les termes alors k'on est d'accord, donc pas besoin de tirer en longueur :)

Le compilateur n'est perdu avec aucun type de donné venant de l'ancien langage et du domaine .Net, c'est d'ailleurs l'une des règles de bases des compilo .Net

T'as essayé d'ajouter 1 à une variable de type UInt32 en VB.NET ? :)

Je partage ce point de vue, mais il faut comprendre qu'en informatique, on ne travaille pas qu'avec des informaticiens pur et durs.
Il y a aussi des gens "reconvertis" en informatique, qui ne sont pas aussi à l'aise avec les languages strict que d'autres... pourtant ces "informaticiens" là ne sont pas remplacables pour autant par des hard-coders car ils ont souvant des compétences-métier dures a trouver chez les informaticiens.

Vi, mais là encore c'est un cas un peu particulier. Je me concentre sur le cas de ceux ki se disent développeurs, donc ki sont censés avoir la rigueur correspondante :)

Ceux ki ne le sont pas et ne prétendent pas l'être, c'est autre chose :)

Faux!!! Car VB.Net et C# ont EXACTEMENT les mêmes performances!!!!
Toutefois... a condition d'utiliser les véritables types .Net

Moui, faudrait vérifier ce ki se passe au juste du côté de C# pour les conversions k'il fait implicitement et ke VB.NET nécessite de faire explicitement.

Oh c'est facile a vérifier... suffit de regarder l'IL générée par les deux compilo. Dans les deux cas il est évident du gain d'utiliser les types .Net

J'ai regardé juste après avoir fait le message, et je n'ai pas vu la moindre différence dans le code assembleur généré :)

[Moonheart]

Yup et yup. On est d'accord, mais ça reste des cas particuliers, et orientés sur le court terme

Des cas particuliers qui sont malheureusement légion dans l'informatique de gestion... Or l'informatique de gestion est tout de même un énorme pole de l'informatique en général.

Vi, le compilo prend en charge le code devant gérer les types, mais c'est le runtime ki paye le prix à l'exécution.

Comme pour C#, donc aucun avantage au niveau de l'éxécution de part et d'autre. C'est uniqument au niveau du développement que ca se joue.

Or sur ce point VB.Net a un léger avantage du fait qu'il peux soit être strict soit ne pas l'être... alors que C# n'a qu'une seule de ces deux possibilités.

T'as essayé d'ajouter 1 à une variable de type UInt32 en VB.NET ?

Oui, et ca se fait sans aucun problème, si tu n'oublies pas de préciser que tu parles d'un 1 UInt32 par le suffixe approprié.

Vi, mais là encore c'est un cas un peu particulier. Je me concentre sur le cas de ceux ki se disent développeurs, donc ki sont censés avoir la rigueur correspondante

Ca serait bien si ca représentait la réalité du terrain, hélàs laisse moi te dire que c'est très loin d'être vrai... alors il faut bien le prendre en compte.

Faux!!! Car VB.Net et C# ont EXACTEMENT les mêmes performances!!!!
Toutefois... a condition d'utiliser les véritables types .Net

Moui, faudrait vérifier ce ki se passe au juste du côté de C# pour les conversions k'il fait implicitement et ke VB.NET nécessite de faire explicitement.

Oh c'est facile a vérifier... suffit de regarder l'IL générée par les deux compilo. Dans les deux cas il est évident du gain d'utiliser les types .Net

J'ai regardé juste après avoir fait le message, et je n'ai pas vu la moindre différence dans le code assembleur généré

Ce qui montre bien que le code VB.Net n'est pas moins performant que le code C#.
Encore une fois, entre C# et VB.Net, c'est au niveau du développement que ca se joue, et pas du tout au niveau du runtime.

[Maniak]

Yup et yup. On est d'accord, mais ça reste des cas particuliers, et orientés sur le court terme :)

Des cas particuliers qui sont malheureusement légion dans l'informatique de gestion... Or l'informatique de gestion est tout de même un énorme pole de l'informatique en général.

Vi, mais comme tu dis, "malheureusement". Rien n'interdit de faire des efforts pour arranger un peu les choses, même si en effet, c'est loin d'être gagné :)

Vi, le compilo prend en charge le code devant gérer les types, mais c'est le runtime ki paye le prix à l'exécution.

Comme pour C#, donc aucun avantage au niveau de l'éxécution de part et d'autre. C'est uniqument au niveau du développement que ca se joue.

Oui et non. Oui parce k'évidemment, le code compilé s'exécute de la même façon, kel ke soit le langage d'origine (ça vaut mieux :), non parce ke si un langage oblige à faire des appels de fonctions supplémentaires, ces appels seront présents dans le code compilé. C'est mineur, mais ça existe kand même.

Sans parler des divergences type bloc 'using' en C# ki, en plus d'être plus simple niveau code, est aussi plus fiable (on est sûr ke la méthode Dispose sera appelée, sans avoir à tout englober dans un gros try/finally)

Or sur ce point VB.Net a un léger avantage du fait qu'il peux soit être strict soit ne pas l'être... alors que C# n'a qu'une seule de ces deux possibilités.

Yup, et tant mieux, vu ke le public visé n'est pas forcément le même.

T'as essayé d'ajouter 1 à une variable de type UInt32 en VB.NET ? :)

Oui, et ca se fait sans aucun problème, si tu n'oublies pas de préciser que tu parles d'un 1 UInt32 par le suffixe approprié.

Là ça m'intrigue, c'est koi le suffixe pour les non-signés ? :)
Si j'essaye de faire ça, y compris en passant par des Convert.ToUInt32, l'addition entre deux UInt32 me donne un "l'opérateur + n'existe pas pour le type UInt32" :)

Et ça, c'est un truc ke je n'ai jamais réussi à comprendre :)

Vi, mais là encore c'est un cas un peu particulier. Je me concentre sur le cas de ceux ki se disent développeurs, donc ki sont censés avoir la rigueur correspondante :)

Ca serait bien si ca représentait la réalité du terrain, hélàs laisse moi te dire que c'est très loin d'être vrai... alors il faut bien le prendre en compte.

Oh t'en fais pas, je sais, je suis dedans :)
Mais cf plus haut, ça n'empêche pas de faire des efforts pour essayer d'améliorer les choses, même à très petite échelle :)

Ce qui montre bien que le code VB.Net n'est pas moins performant que le code C#.
Encore une fois, entre C# et VB.Net, c'est au niveau du développement que ca se joue, et pas du tout au niveau du runtime.

Dans 99.9999% des cas vi, et le reste est plutôt négligeable, on est d'accord.
Et au niveau du développement proprement dit, dans le cadre de développeurs 'sérieux' et de développements 'sérieux', la balance entre C# et VB.NET me semble pencher très (très) fortement du côté du C#. Hors de ce cadre, les données ne sont pas les mêmes, et j'avoue ne pas trop m'intéresser au langage ki peut être utilisé dans les mini-projets jetables destinés à ne pas servir longtemps :)

[Rami]

j'avoue ne pas trop m'intéresser au langage qui peut être utilisé dans les mini-projets jetables destinés à ne pas servir longtemps

des fois, ca vaut le coup:
(Cas particulier, je ne généralise pas)
un projet 'pas serieux' (réalisé en 2 mois dont 3 semaines de dev. en webform vb.net, option strict off, IHM minimaliste (mais ergo.) durée de vie 3mois) a permis a notre département de faire économiser
70% du temps de saisie d'une operation ponctuelle et automatisant l'import dans le system (2 millions de $ de saving estimé)
consequences:
-> budget maintenues
-> projets 'serieux' maintenus
-> l'equipe reste au complet

si l'equipe n'avait pas etait capable de reussir ceci, un develop. commencé il y a deux ans aurait été arrété + deux départs etaient programmés.

ceci pour dire aussi qu'avoir plusieurs cordes a son arc est un plus.
alors au débat: C# VB.NET que choisir? je reponds les deux, en connaissant les point forts et faiblesses de chacun. Et vous les avez bien détaillées tous les deux.

[Moonheart]

Des cas particuliers qui sont malheureusement légion dans l'informatique de gestion... Or l'informatique de gestion est tout de même un énorme pole de l'informatique en général.

Vi, mais comme tu dis, "malheureusement". Rien n'interdit de faire des efforts pour arranger un peu les choses, même si en effet, c'est loin d'être gagné

Arranger les choses du point de vue de qui?
De nous, qui sommes des informaticiens "stricts"?

Pourquoi les choses devrait-elles s'arranger pour nous et non pas pour les autres?

Si j'essaye de faire ça, y compris en passant par des Convert.ToUInt32, l'addition entre deux UInt32 me donne un "l'opérateur + n'existe pas pour le type UInt32"

Ca va exister, c'est prévu pour les prochaines versions du compilateur.
N'oublions pas que nous avons à faire à un produit jeune, il faut laisser le temps que ca se décante.

Oh t'en fais pas, je sais, je suis dedans
Mais cf plus haut, ça n'empêche pas de faire des efforts pour essayer d'améliorer les choses, même à très petite échelle

Encore une fois, les améliorer pour qui?

Dans 99.9999% des cas vi, et le reste est plutôt négligeable, on est d'accord.
Et au niveau du développement proprement dit, dans le cadre de développeurs 'sérieux' et de développements 'sérieux', la balance entre C# et VB.NET me semble pencher très (très) fortement du côté du C#. Hors de ce cadre, les données ne sont pas les mêmes, et j'avoue ne pas trop m'intéresser au langage ki peut être utilisé dans les mini-projets jetables destinés à ne pas servir longtemps

Je n'aime pas trop l'appellation "sérieux" pour les développements cités. Tous les développement professionnels sont sérieux, mais tous n'ont pas forcément une durée de vie très longue.

Exemple: on change de logiciel dans ta société pour une raison X ou Y... Les utilisateurs ont cependant besoin de garder leurs données, donc il faut les traduire.
Problème: il a y plusieurs millions d'enregistrements provenant d'une base non-SQL a transférer vers une autre base non-SQL. Tu fais quoi?

Ben tu programmes une moulinette qui prenent en entrée des fichiers plat de l'ancien logiciel qui les retraite, les convertisse et qui crée de nouveaux fichiers plats qui seront injectés dans le nouveau logiciel...
Le développement d'une telle chose peut-être compliqué si les données d'entrée sont complexes et le format de sorti très différent, toutefois le temps de vie de ta moulinette sera lui très court (un ou deux mois max)

Est-ce que donc ca vaut le coup de te perdre du temps avec des centaines casts explicites à écrire pour un code qui n'aura jamais à être maintenu ou à évoluer?
La réponse est pour moi: non.

Il s'agit d'un développement sérieux et important, mais il tirerait avantage d'une Option Strict Off de VB.Net qui est absente de C#

ceci pour dire aussi qu'avoir plusieurs cordes a son arc est un plus.
alors au débat: C# VB.NET que choisir? je reponds les deux, en connaissant les point forts et faiblesses de chacun. Et vous les avez bien détaillées tous les deux.

Je suis d'accord avec cet avis moi aussi.
Surtout que:
1- Les deux sont entièrement compatibles et facilement traduisibles l'un dans l'autre
2- Les deux sont fournis dans le seul environnement de développement potable qui existe pour le moment sur .Net (= Visual Studio .Net)

Vu que ca ne coute pas plus cher au niveau des licenses d'utiliser les deux et que la compatibilité est totale ou presque, pourquoi s'en priver?

[Maniak]

Arranger les choses du point de vue de qui?
De nous, qui sommes des informaticiens "stricts"?

Pourquoi les choses devrait-elles s'arranger pour nous et non pas pour les autres?

Pour tout le monde. Dans le cas des développements (vu k'il ne s'agit ke de ça), une absence totale de rigueur finit toujours par poser des problèmes (sauf pour les trucs vraiment très basikes et à durée de vie vraiment très limitée, mais comme dit précédemment, je ne les prends pas en compte, même s'ils sont utiles dans des cas comme l'a raconté Rami).

Promouvoir cette absence de rigueur, au riske de la voir se propager (encore davantage) dans les 'gros' projets est néfaste à terme pour tout le monde.

Si j'essaye de faire ça, y compris en passant par des Convert.ToUInt32, l'addition entre deux UInt32 me donne un "l'opérateur + n'existe pas pour le type UInt32" :)

Ca va exister, c'est prévu pour les prochaines versions du compilateur.
N'oublions pas que nous avons à faire à un produit jeune, il faut laisser le temps que ca se décante.

Ok, ça me rassure :)
Donc c'est bien ça. Là tout de suite, à l'instant T et malgré deux versions de compilo VB.NET, les opérations entre entiers non-signés sont kelke peu problématikes, et c'est bien une divergence au niveau des possibilités des compilos VB.NET et C#.

Je n'aime pas trop l'appellation "sérieux" pour les développements cités. Tous les développement professionnels sont sérieux, mais tous n'ont pas forcément une durée de vie très longue.

Bah faut bien leur donner un nom :)
Les "développements ki nécessitent un investissement en temps, moyens et personnes importants" par opposition aux "développements de courte durée à utilisation ponctuelle", si tu préfères :)

Est-ce que donc ca vaut le coup de te perdre du temps avec des centaines casts explicites à écrire pour un code qui n'aura jamais à être maintenu ou à évoluer?
La réponse est pour moi: non.

Il s'agit d'un développement sérieux et important, mais il tirerait avantage d'une Option Strict Off de VB.Net qui est absente de C#

Rien à redire sur la raison d'être de ces 'petits' projets, là encore je suis au courant, je suis dedans :)
Mais comme dit précédemment, je ne renie et ne critike pas l'existence et la façon de faire ces projets-là. C'est juste ke le 'problème' du langage est plutôt mineur à ce niveau. Tu prends ce ki te permets de faire ce k'il te faut le plus vite, c'est tout. Si tu es plus à l'aise en VB.NET et ke tu ne crains pas de perdre du temps à débugger au travers de l'absence de typage, ok. Si tu es plus à l'aise en C# et ke le typage ne te ralentit en rien, ok aussi. Y a vraiment pas matière à débat là-dessus.

Je concentre juste mon point de vue dans la discussion actuelle sur les 'gros' projets. Ceux ki auront besoin d'être maintenus, de durer longtemps, d'évoluer. Et là, les données changent :)

Je n'ai rien, asbolument rien, contre utiliser VB.NET pour les projets 'rapides' (et importants malgré tout :)
Je préfère de loin le C# parce ke la syntaxe du VB.NET me fait perdre un temps monstrueux, mais dans ce contexte-là, c'est un choix purement personnel.

Pour les projets pour leskels le typage n'est pas bien important (voire ralentit plus k'autre chose), VB.NET va très bien si on est à l'aise avec. À partir du moment où le typage devient important (entre autres), ce n'est plus vraiment le cas.

[Moonheart]

Pour tout le monde. Dans le cas des développements (vu k'il ne s'agit ke de ça), une absence totale de rigueur finit toujours par poser des problèmes (sauf pour les trucs vraiment très basikes et à durée de vie vraiment très limitée, mais comme dit précédemment, je ne les prends pas en compte, même s'ils sont utiles dans des cas comme l'a raconté Rami).

Sauf que tu ne peux pas ne pas les prendre en compte vu qu'ils sont réalité et qu'ils représentent un pourcentage non négligeable tu travail informatique d'aujourd'hui.

Promouvoir cette absence de rigueur, au riske de la voir se propager (encore davantage) dans les 'gros' projets est néfaste à terme pour tout le monde.

Je pense que c'est plutot là qu'il faut faire des efforts: empecher les amalgames entre petits et gros projets.
Un gros projet, c'est pas un petit projet avec un peu plus de taf à faire! C'est une logique complètement différente et des outils eux aussi différents.

Si tu es plus à l'aise en VB.NET et ke tu ne crains pas de perdre du temps à débugger au travers de l'absence de typage, ok. Si tu es plus à l'aise en C# et ke le typage ne te ralentit en rien, ok aussi. Y a vraiment pas matière à débat là-dessus.

Le truc, c'est que le typage ralentit forcément... Même le plus à l'aise des programmeurs stricts n'ira pas plus vite en écrivant des casts qu'en les laissant en implicite.
Même si la différence peux parfois être mineure, elle existe.

Je concentre juste mon point de vue dans la discussion actuelle sur les 'gros' projets. Ceux ki auront besoin d'être maintenus, de durer longtemps, d'évoluer.

Mais c'est une erreur, parce que les gros projets ne sont pas la majorité du travail qu'il y a à faire de nos jours.
On est plus dans une époque ou tout restait à mettre en place, de plus en plus on a juste besoin de développement ponctuels et non pas de gros chantiers.

[Maniak]

Sauf que tu ne peux pas ne pas les prendre en compte vu qu'ils sont réalité et qu'ils représentent un pourcentage non négligeable tu travail informatique d'aujourd'hui.

C'est bien ce ke je dis. On peut le prendre en compte, mais sans le cautionner pour autant. C'est pas parce ke ça existe et ke c'est répandu ke c'est bien :)

Un gros projet, c'est pas un petit projet avec un peu plus de taf à faire! C'est une logique complètement différente et des outils eux aussi différents.

C'est bien ce ke je dis (encore :)
Et c'est pour ça ke je limite mon raisonnement aux gros projets. Pour les petits, ça n'a plus rien à voir, et essayer de discuter des deux à la fois, c'est une source de discussions sans fin (comme on en fait la démonstration ici même :)

Le truc, c'est que le typage ralentit forcément... Même le plus à l'aise des programmeurs stricts n'ira pas plus vite en écrivant des casts qu'en les laissant en implicite.
Même si la différence peux parfois être mineure, elle existe.

Ça ralentit pour taper le code, ça accélère pour débugger. De mon point de vue, le ralentissement pour taper le code est mineur (je tape vite, ça aide :), et ne pas avoir de bugs obscurs liés à l'absence de typage est un luxe dont j'aurais du mal à me priver :)
Mais là, il y a une grosse part de préférence perso (ou forcée par l'entreprise, mais c'est autre chose). C'est pour ça ke j'essaye de sortir les 'petits' projets de la discussion. Les arguments 'indépendants du développeur' ont relativement bcp moins de poids par rapport aux goûts du développeur lui-même.

Je concentre juste mon point de vue dans la discussion actuelle sur les 'gros' projets. Ceux ki auront besoin d'être maintenus, de durer longtemps, d'évoluer.

Mais c'est une erreur, parce que les gros projets ne sont pas la majorité du travail qu'il y a à faire de nos jours.
On est plus dans une époque ou tout restait à mettre en place, de plus en plus on a juste besoin de développement ponctuels et non pas de gros chantiers.

J'ai pas dit k'il ne fallait pas en discuter hein, juste k'on ne peut pas discuter des deux sujets en même temps vu ke les arguments ne sont pas compatibles. Faudrait faire deux threads bien distincts en fait.

[Moonheart]

C'est pas parce ke ça existe et ke c'est répandu ke c'est bien

C'est pas parce que c'est pas bien qu'il faut pas en tenir compte dans le choix du langage de développement, aussi.

C'est bien ce ke je dis (encore
Et c'est pour ça ke je limite mon raisonnement aux gros projets. Pour les petits, ça n'a plus rien à voir, et essayer de discuter des deux à la fois, c'est une source de discussions sans fin (comme on en fait la démonstration ici même

En même temps, le sujet c'est pas "VB.Net ou C# pour les gros projets?" donc faut bien parler des deux

[Maniak]

C'est pas parce ke ça existe et ke c'est répandu ke c'est bien :)

C'est pas parce que c'est pas bien qu'il faut pas en tenir compte dans le choix du langage de développement, aussi.

Et je n'ai jamais dit le contraire ke je sache :)

En même temps, le sujet c'est pas "VB.Net ou C# pour les gros projets?" donc faut bien parler des deux :)

Ou faire deux threads :)
Mais s'il faut parler des deux, faut kand même pas le faire en même temps. Sinon on arrive sur ce k'on fait depuis 2 pages, à savoir être globalement du même avis, mais ne pas parler de la même chose :)

Donc :
Petits projets : utiliser le langage avec lekel on est le plus à l'aise (à condition k'ils restent petits, parce ke pas mal de gros projets commencent en étant petits, et s'ils commencent avec une approche laxiste, ça se finit mal :)

Gros projets : + de rigueur, non-typage à la poubelle si on ne veut pas passer sa vie en mode debug, et VB.NET bien moins adapté ke C#.

Ça résume ma position vis-à-vis des possibilités des langages. Si on y ajoute la syntaxe, en ce ki me concerne, le VB va directement à la poubelle dans tous les cas :)

[Moonheart]

Mais s'il faut parler des deux, faut kand même pas le faire en même temps. Sinon on arrive sur ce k'on fait depuis 2 pages, à savoir être globalement du même avis, mais ne pas parler de la même chose

Donc :
Petits projets : utiliser le langage avec lekel on est le plus à l'aise (à condition k'ils restent petits, parce ke pas mal de gros projets commencent en étant petits, et s'ils commencent avec une approche laxiste, ça se finit mal

Comme quoi on est pas d'accord.

Pour moi: petit projet = VB.Net, parce que plus rapide pour le développement même si peu adapté à la maintenabilité de longue durée.

[Maniak]

Comme quoi on est pas d'accord.

Pour moi: petit projet = VB.Net, parce que plus rapide pour le développement même si peu adapté à la maintenabilité de longue durée.

Détail. La 'rapidité' de développement en VB.NET est toute relative et dépend beaucoup (essentiellement) du développeur. Pour toi c'est peut-être plus rapide, pour moi c'est plus long (le typage ne me ralentit pas le moins du monde), plus solide et bien plus facile à mettre en place (debugging, tout ça).

Le seul avantage ke j'ai vu au VB.NET juske là, c'est de ne pas avoir besoin de compiler pour voir les erreurs dans la liste des taches :)

Mais là c'est un choix perso. Après, savoir si on est d'accord ou pas dépend de si tu peux concevoir ke VB.NET n'est pas la solution la plus rapide pour tout le monde, ke ça dépend des gens, donc k'on prend ce k'on veut du moment k'on est à l'aise avec et ke ça reste à petite échelle.

Si tu assènes un "VB.NET est plus rapide pour développer pour tout le monde" là non, on ne sera pas d'accord. Ni maintenant, ni jamais :)

[DrQ]

Tout dépend si tu programmes en VB.NET comme en VB6 ou bien si tu fais réellement du .NET.

Dans le cas où tu programmes comme en VB6 alors il est possible que tu ailles un peu (vraiment un peu) plus vite.

[Maniak]

Tout dépend si tu programmes en VB.NET comme en VB6 ou bien si tu fais réellement du .NET.

Dans le cas où tu programmes comme en VB6 alors il est possible que tu ailles un peu (vraiment un peu) plus vite.

Vi, mais là on parle de .NET en principe :)
Et faire des projets soi-disant .NET en programmant comme en VB6... ok c'est peut-être plus rapide (kand on est plus habitué à VB6 k'à .NET), mais c'est pas trop le but :)

Pi bon, une fois habitué à .NET, je doute *vraiment* k'on aille plus vite en VB6. Mais vu ke ce n'est pas du tout la même façon de développer, je ne suis déjà pas sûr k'on puisse comparer.

[cjarnot]

Je ne me rappelle rien ou presque de VB.

Je suis donc parti avec C# ayant des compétences Java et j'ai batir des application Windows sans problèmes.

Je crois que C# est aussi le language le plus complet.