Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
tout à fait et je pense que la majorité des développeur java qui se mettent à .NET migreront directement vers C#Envoyé par Maniak
(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
Prions ensemble mes frères, pour ke tel soit l'avenir :)
Ca me tire la larme ça les gars
la larme incendie ?Ca me tire la larme ça les gars
/me cherche le smiley 'je sors'
/me ne trouve pas
/me se rabat sur
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é !
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 snifferle 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...
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++
Avantage ?
Avantage ?- Similarité avec le langage VB
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.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...
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.
C'est libérateur pour les feignasses oui :)- avantage parce que c'est libérateur pour la tête du programmeur
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.
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.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
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 :)
Mmh... int = Integer = Int32. Aucune différence de ce côté là.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.
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).
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.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!!!
À 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.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.
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 :)
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.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.Avantage ?- Similarité avec le langage VB
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.Pas le compilateur. Le runtime. Si le compilateur prenait ça en charge, les erreurs seraient interceptées à la compilation.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...
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.
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é.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.
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 .NetAvec 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 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
Je partage ce point de vue, mais il faut comprendre qu'en informatique, on ne travaille pas qu'avec des informaticiens pur et durs.C'est libérateur pour les feignasses oui- avantage parce que c'est libérateur pour la tête du programmeur
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.
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.
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 .NetMoui, 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.Faux!!! Car VB.Net et C# ont EXACTEMENT les mêmes performances!!!!
Toutefois... a condition d'utiliser les véritables types .Net
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.Toujours avec mon exemple de la constante 0 à stocker dans une variable UInt32, VB.NET a donc besoin d'un appel à Convert.ToUInt32
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.Mmh... int = Integer = Int32. Aucune différence de ce côté là.
Yup et yup. On est d'accord, mais ça reste des cas particuliers, et orientés sur le court terme :)
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.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.
Enfin là on joue sur les termes alors k'on est d'accord, donc pas besoin de tirer en longueur :)
T'as essayé d'ajouter 1 à une variable de type UInt32 en VB.NET ? :)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
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 :)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.
Ceux ki ne le sont pas et ne prétendent pas l'être, c'est autre chose :)
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é :)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 .NetMoui, 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.Faux!!! Car VB.Net et C# ont EXACTEMENT les mêmes performances!!!!
Toutefois... a condition d'utiliser les véritables types .Net
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.Yup et yup. On est d'accord, mais ça reste des cas particuliers, et orientés sur le court terme
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.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.
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.
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é.T'as essayé d'ajouter 1 à une variable de type UInt32 en VB.NET ?
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.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
Ce qui montre bien que le code VB.Net n'est pas moins performant que le code C#.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é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 .NetMoui, 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.Faux!!! Car VB.Net et C# ont EXACTEMENT les mêmes performances!!!!
Toutefois... a condition d'utiliser les véritables types .Net
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.
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é :)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.
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.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.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.
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)
Yup, et tant mieux, vu ke le public visé n'est pas forcément le même.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.
Là ça m'intrigue, c'est koi le suffixe pour les non-signés ? :)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é.T'as essayé d'ajouter 1 à une variable de type UInt32 en VB.NET ? :)
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 :)
Oh t'en fais pas, je sais, je suis dedans :)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.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 :)
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 :)
Dans 99.9999% des cas vi, et le reste est plutôt négligeable, on est d'accord.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.
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 :)
des fois, ca vaut le coup: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
(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.
Arranger les choses du point de vue de qui?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é
De nous, qui sommes des informaticiens "stricts"?
Pourquoi les choses devrait-elles s'arranger pour nous et non pas pour les autres?
Ca va exister, c'est prévu pour les prochaines versions du compilateur.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"
N'oublions pas que nous avons à faire à un produit jeune, il faut laisser le temps que ca se décante.
Encore une fois, les améliorer pour qui?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
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.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
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#
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?
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.
Ok, ça me rassure :)Ca va exister, c'est prévu pour les prochaines versions du compilateur.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" :)
N'oublions pas que nous avons à faire à un produit jeune, il faut laisser le temps que ca se décante.
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#.
Bah faut bien leur donner un nom :)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.
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 :)
Rien à redire sur la raison d'être de ces 'petits' projets, là encore je suis au courant, je suis dedans :)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#
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.
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.
Je pense que c'est plutot là qu'il faut faire des efforts: empecher les amalgames entre petits et gros projets.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.
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.
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.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.
Même si la différence peux parfois être mineure, elle existe.
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.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.
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.
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 :)
C'est bien ce ke je dis (encore :)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.
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 :)
Ç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 :)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.
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.
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.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.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.
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.
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 pas parce ke ça existe et ke c'est répandu ke c'est bien
En même temps, le sujet c'est pas "VB.Net ou C# pour les gros projets?" donc faut bien parler des deuxC'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
Et je n'ai jamais dit le contraire ke je sache :)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.
Ou faire deux threads :)En même temps, le sujet c'est pas "VB.Net ou C# pour les gros projets?" donc faut bien parler des deux :)
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 :)
Comme quoi on est pas d'accord.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
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.
Partager