tout � fait et je pense que la majorit� des d�veloppeur java qui se mettent � .NET migreront directement vers C#Citation:
Envoy� par Maniak
Version imprimable
tout � fait et je pense que la majorit� des d�veloppeur java qui se mettent � .NET migreront directement vers C#Citation:
Envoy� par Maniak
Prions ensemble mes fr�res, pour ke tel soit l'avenir :)Citation:
Envoy� par neo.51
Ca me tire la larme �a les gars :lol:
la larme incendie ? :oops:Citation:
Envoy� par linkOne
/me cherche le smiley 'je sors'
/me ne trouve pas
/me se rabat sur :pan:
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 sniffer :twisted: 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...
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 ?Citation:
Envoy� par Moonheart
Avantage ?Citation:
- 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.Citation:
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 :)Citation:
- 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.Citation:
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�.Citation:
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.Citation:
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.Citation:
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.Citation:
Envoy� par Maniak
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.Citation:
Avantage ?Citation:
- 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.Citation:
Pas le compilateur. Le runtime. Si le compilateur prenait �a en charge, les erreurs seraient intercept�es � la compilation.Citation:
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�.Citation:
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 .NetCitation:
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 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.Citation:
C'est lib�rateur pour les feignasses oui :)Citation:
- 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 .NetCitation:
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.Citation:
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.Citation:
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.Citation:
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 :)Citation:
Envoy� par Moonheart
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.Citation:
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 ? :)Citation:
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 :)Citation:
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� :)Citation:
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 .NetCitation:
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.Citation:
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.Citation:
Envoy� par Maniak
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.Citation:
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�.Citation:
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.Citation:
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#.Citation:
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� :)Citation:
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 .NetCitation:
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.Citation:
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� :)Citation:
Envoy� par Moonheart
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.Citation:
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.Citation:
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.Citation:
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 ? :)Citation:
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�.Citation:
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 :)Citation:
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.Citation:
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.Citation:
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:Citation:
Envoy� par Maniaque
(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?Citation:
Envoy� par Maniak
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.Citation:
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?Citation:
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.Citation:
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.Citation:
Envoy� par Rami
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).Citation:
Envoy� par Moonheart
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 :)Citation:
Ca va exister, c'est pr�vu pour les prochaines versions du compilateur.Citation:
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 :)Citation:
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 :)Citation:
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.Citation:
Envoy� par Maniak
Je pense que c'est plutot l� qu'il faut faire des efforts: empecher les amalgames entre petits et gros projets.Citation:
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.Citation:
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.Citation:
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 :)Citation:
Envoy� par Moonheart
C'est bien ce ke je dis (encore :)Citation:
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 :)Citation:
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.Citation:
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.Citation:
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.Citation:
Envoy� par Maniak
En m�me temps, le sujet c'est pas "VB.Net ou C# pour les gros projets?" donc faut bien parler des deux :)Citation:
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 :)
Et je n'ai jamais dit le contraire ke je sache :)Citation:
Envoy� par Moonheart
Ou faire deux threads :)Citation:
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.Citation:
Envoy� par Maniak
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.