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.
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).Citation:
Envoyé par Moonheart
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 :)
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 :)Citation:
Envoyé par DrQ
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.
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.
Bonjour,
c'est sûr que C# est vraiment un bon langage qui allie les avantages du C++ et du Java. La facilité de programmation du Java (pas de pointeur et de mémoire à gérer par exemple) et les performances du C++ pour une application Windows et non Internet (il faut dire que Java est portable partout mais pour une application, les performances ne sont pas des meilleures). C'est pour cela que j'aime bien développé en C# et j'ai encore énormemment de chos à apprendre mais je ne suis encore qu'étudiant donc ça viendra.
Cyrille
Mmm je pense que le but de ce thread est surtout de comparer les deux languages, aussi je me demande si encenser l'un sans le comparer à l'autre est bien pertinent...
Enfin sans vouloir jouer les rabas-joie.
On le voit dans ce thread, on ne peut pas s'empécher de parler de vb6 ...
:lol:
Je pense que le problème de VB.NET s'est que le vb souffre de son passé vb6,vba, vbscript qui fait plus pensé à des bidouilleur que les java ou le c++ qui ont une plus grande renomée.
C'est vraiment l'impression que j'ai en lisant les propos de Maniak ;)
En tous cas je pense que le C# et le VB.NET resteront les deux piliers du framework .NET.
Jusqu'à Java.Net :)Citation:
Envoyé par neo.51
tu parles de J# ? :mouarf:Citation:
Envoyé par Moonheart
Nan, je parles de Java.Net :mrgreen:
Bah c'est pas k'il souffre de son passé, c'est k'il en hérite :)Citation:
Envoyé par neo.51
La lourdeur de la syntaxe et le non-typage sont encore là. Et à en croire les arguments ki ont été avancés en faveur de VB.NET, le non-typage est la principale raison de l'utiliser. Hors, vu ke le non-typage n'est utilisable proprement (et encore) ke dans de petits projets, n'ayant aucun riske de devenir gros, ça limite forcément le champ d'action :)
Et là-dessus, je suis catégorike. Kelk'un ki prône le non-typage dans de gros projets, avec évolution, maintenance et tout ce ki s'ensuit, je demande à ce k'il soit pendu par les yeux, là, tout de suite :)
Après au niveau de la syntaxe elle-même, k'elle soit plus lourde est une évidence, k'elle soit plus claire est une kestion de goût (pour moi non par exemple, mais je sais bien ke pour d'autres c'est la syntaxe du C ki semble obscure :), bref c'est plus flou.
Par contre, vu ke j'ai tendance à utiliser des entiers non-signés chake fois ke je n'ai pas besoin de nombres négatifs (c'est un peu fait pour après tout), et vu ke VB.NET est (bêtement) complètement à la masse pour les gérer, poubelle :)
Vraiment, le seul avantage ke je vois à VB.NET, c'est de ne pas avoir à compiler pour voir les erreurs. Ça, j'aimerais beaucoup (beaucoup) l'avoir en C#. Mais mis à part ça... k'est-ce ke VB.NET fait ke le C# ne fait pas, ou k'est-ce k'il fait mieux ou moins lourdement... je sèche :)
Des idées ? :)
On dirait, à lire l'ensemble des messages qui précèdent, que l'on s'accroche sur deux ou trois points principaux :
1. Qui est le plus rapide? Faux débat! Si la performance est un facteur important, travaillez en C++ et évitez l'OO autant que possible. Si l'on parle de rapidité de rédaction, il faut se rappeler que celà ne joue qu'un rôle tout à fait négligeable dans le cadre plus général du cycle complet d'une application.
2. Le style, la lisibilité, la concision etc. Un vrai débat, car le style peut jouer un rôle important dans le cadre de la lisibilité et donc de la maintenabilité d'une application (ce n'est pas le seul facteur, évidemment ...). A ce que j'en lis, il n'y a pas de vrai progrès en la matière par rapport à VB6 (pour moi, le basic et le pascal sont des exemples de styles conçus pour être facilement lus et compris, le basic original insistant sur la simplicité, le pascal sur la rigueur). La syntaxe du c quant à elle a été conçue pour économiser les lignes de code, en ces temps anciens où l'en encodait encore en faisant des trous dans des petites cartes en carton...; par la suite, cette syntaxe concise a fait le bonheur de la caste universitaire.
3. Le caractère "professionnel" des langages. Les ingénieurs ingénieux n'auront jamais de gêne à utiliser VB pour obtenir une solution rapide vite fait, bien fait (il n'y a pas d'incompatibilité). Le marché étant ce qu'il est pour les informaticiens, Java et C#, cela fait indiscutablement plus "pro". Un tuyau à tous les pros en question : soignez votre orthographe, et votre style "rédactionnel", c'est indiscutablement un des premièrs indices de professionnalisme que l'on peut évaluer.
Bon, dans les mois qui suivent, j'ai justement une mission bien précise à effectuer (mémoire) : comparer la gestion des événements (au sens large) dans les langages OO : de VB6 (eh oui) à C#, en passant par Java et VB.net ...
Souhaitez moi bonne chance ...
Ça fait longtemps ke l'argument 'performance' entre OO et procédural est devenu bidon, et totalement insignifiant kand on prend en compte tous les avantages de l'OO :)Citation:
Envoyé par BisonDiligent
Surtout pour les non-développeurs. J'ai notamment comme exemple dans mon voisinage tout proche une grosse appli faite en VB, unikement parce ke des non-développeurs ont besoin d'aller y farfouiller pour changer kks bricoles par-ci par-là et k'ils comprennent bien mieux un langage plus verbeux.Citation:
2. Le style, la lisibilité, la concision etc. Un vrai débat, car le style peut jouer un rôle important dans le cadre de la lisibilité et donc de la maintenabilité d'une application (ce n'est pas le seul facteur, évidemment ...).
Pour les développeurs, la différence de lisibilité est mineure (voire inversée), alors ke le temps de rédaction prend plus d'importance :)
Euh, tu ne confondrais pas avec le Cobol là ? :)Citation:
La syntaxe du c quant à elle a été conçue pour économiser les lignes de code, en ces temps anciens où l'en encodait encore en faisant des trous dans des petites cartes en carton...
C'est surtout lui ki a été fait pour les cartes perforées, avec ses lignes à commencer à une colonne particulière selon leur rôle :)
Ben déjà, tu gagneras du temps en ne mettant ke C# ou VB.NET dans la comparaison, la gestion des événements est identike :)Citation:
Bon, dans les mois qui suivent, j'ai justement une mission bien précise à effectuer (mémoire) : comparer la gestion des événements (au sens large) dans les langages OO : de VB6 (eh oui) à C#, en passant par Java et VB.net ...
Par contre, VB6 langage orienté objet, euh... non ? :)
C'est aussi OO ke du C++ dans lekel les classes ne servent k'à faire des structures un peu moins stupides :)
Bonne chance Jim :)Citation:
Souhaitez moi bonne chance ...
I love VB6 so much ...
Does simple things so simply!
Simple OO features, for 95 % of local application needs.
A people's language, so frustrating for real programmers!
Good to remember : OO was not required at all in order to manage the Apollo XIII crisis ...
Regarding events handling : VB has some powerfull event handling keywords that are native to the langage. So a very simple, straightforward event handling is easy to implement, enough again for 95 % of the usual needs.
Nevertheless, more complicated event handling "à la Java" is possible as well in VB, if required.
IMHO, VB is, simply spoken, THE reference, the starting point of any event handling study.
Best,
Ca dépends du contexte. Parce qu'il n'y a pas que les IHM dans la vie, il existe aussi des applications avec de GROS besoin de performances, qui ne peuvent tout simplement pas se permettre de gaspiller du temps d'éxécution à la gestion objets, au garbage collector, et autres...Citation:
Envoyé par Maniak
J'ai l'impression aussi.Citation:
Euh, tu ne confondrais pas avec le Cobol là ? :)Citation:
La syntaxe du c quant à elle a été conçue pour économiser les lignes de code, en ces temps anciens où l'en encodait encore en faisant des trous dans des petites cartes en carton...
Si si, même si ca reste l'OO du pauvre.Citation:
Par contre, VB6 langage orienté objet, euh... non ? :)
Même pas... Pour moi un "vrai" programmeur est un programmeur qui sait se satisfaire de n'importe quel langage capable de faire ce qui a besoin d'être fait. (Ceci compte aussi la facilité de maintenance quand elle est requise, qui est le point faible de VB6 par rapport à Java et C#)Citation:
Envoyé par BisonDiligent
Par contre, "People's language" tu y vas quand même ultra fort sur la pédale, là... C'est verbeux, oui, mais de la à dire que n'importe qui peux comprendre du code VB6, c'est un peu excessif, ca reste un langage informatique... et donc a priori pas accessible à tous à moins de faire du code simplissime, ce qui est rare.
Ca... Dans le genre argument sans queue ni tête...Citation:
Good to remember : OO was not required at all in order to manage the Apollo XIII crisis ...
VB6 non plus n'a pas été requis pour gérer la crise de l'Apollo XIII, alors quel rapport avec le sujet?
N'importe qui peux sortir une phrase du genre: "Simple OO features was not requiered at all in order to manage the 9/11 crisis" mais ca ne fait pas avancer le schimilblick pour autant... d'ailleurs ce n'est même pas un argument: c'est tout un plus une belle phrase capable d'impressionner ceux qui vont pas creuser le sens des mots plus loin que la surface.
VB.Net et C# ont une gestion des évènements à peine plus compliquée mais surtout beaucoup plus souple et maléable... La simple présence des "délégués" les rends 10 fois plus puissants en terme de gestion évènementielle.Citation:
Regarding events handling : VB has some powerfull event handling keywords that are native to the langage. So a very simple, straightforward event handling is easy to implement, enough again for 95 % of the usual needs.
Oui, en VB tout court, tu peux gérer 95% des cas (et encore, ca reste à prouver... c'est quoi les sources d'une telle statistique?), mais les languages .Net le font d'une manière tout simplement 10 fois plus performante.
Essaie un peu de coder un évènement nécessitant des délégués sous VB6: tu vas y arriver avec un peu d'huile de coude, mais bonjour l'usine à gaz pour cela!!!!
Je ne parles pas du temps perdu au développement, à l'éxécution et surtout à la maintenance!
Au moins tu anonce clairement ton paradigme.... ;)Citation:
IMHO, VB is, simply spoken, THE reference, the starting point of any event handling study.
Vous l'aurez compris, il y avait là un peu de provoc, à différents niveaux.
Quand je dis que VB est la référence en gestion événementielle, je ne dis pas que c'est le meilleur, je dis que c'est un point de comparaison obligé, ne fût-ce que pour des raisons historiques.
Et tu ne me contredis pas, en fait, quand tu dis que le système des délégués est dix foix plus puissant (que VB) et presque aussi simple (que VB).
Quid des 95 %?
Simple : cherche sur le forum ou ailleurs des questions, des problèmes relatifs à "Public Event()", à "Raise Event", à "Public WithEvents" ... et rôle exact de doevents, qui est très mal expliqué dans la doc VB6. Il n'y en a guère et je crois en fait que très peu de programmeurs programment des événements (en dehors des événements des contrôles, bien entendu).
La phrase qui ne veut rien dire à propos du programme Apollo se veut un simple rappel : l'OO à tout casser n'est pas toujours indispensable. Tout le monde insiste sur la réutilisabilité, mais moi je me rappelle que deux des plus beaux crash de l'aérospatiales (Arianne V et je ne sais plus quel robot explorateur martien) se sont soldés par des échecs retentissants, parceque l'on s'était fié à cette notion de réutilisabilité, justement.
A propos, une bonne bibliothèque de fonctions, ce n'est pas réutilisable? On dirait que les méthodes de classe sont une découverte de l'OO?
Mais quid des fonctions mathématiques en tout genre?
Il y a beaucoup d'autres assertion jetées à la figure du public concernant l'OO, qui sont souvent des pétitions de principe, ou des "démonstrations" basées sur un exemple, alors que le contre-exemple existe mais est passé sous silence.
Bon, moi j'essaie d'être pragmatique, et, je me suis sérieusement attaqué à Java, pour éviter de parler sans connaître. Je ne suis pas au bout, loin de là, mais ce que j'en découvre ne me convainct pas toujours.
Il reste beaucoup de confusion, de procédés tortueux, c'est loin d'être "direct".
Bref, j'ai choisi mon mémoire sur un sujet de programmation, qui va me forcer à explorer un domaine bien particulier en .net et en java.
C'est pas de la bonne volonté çà?
Ca m'interresse de connaitre tes sources car je n'avais pas entendu la même chose personnellement.Citation:
Envoyé par BisonDiligent
Déjà parce que l'Aerospatiale n'est pas trop une utilisatrice de language OO (trop lent) et ensuite parce qu'il me semble que le crash d'Arianne V était du à un dépassement de capacité binaire ce qui est un problème plus du ressort des langages procéduriers ou assembleurs que des languages OO -qui soulèvent des exceptions dans ces cas-là-)
Ce qu'apporte les méthodes de classe, ce n'est pas tellement l'avantage de la réutilisabilité (comme tu dis, une bibliothèque de fonction le fait aussi) mais plutot le concept de "boite noire" et d'héritage/dérivation, à mon avis.Citation:
A propos, une bonne bibliothèque de fonctions, ce n'est pas réutilisable? On dirait que les méthodes de classe sont une découverte de l'OO?
Comme toutes les propagandent publicitaires. :)Citation:
Il y a beaucoup d'autres assertion jetées à la figure du public concernant l'OO, qui sont souvent des pétitions de principe, ou des "démonstrations" basées sur un exemple, alors que le contre-exemple existe mais est passé sous silence.
Bon, Arianne V => Le principe en cause : la réutilisabilté.
Pour ce que j'en ai lu, au moins une partie du logiciel qui fonctionnait bien sur Arianne IV a été transférée dans le système Arianne V sans être suffisemment testé dans son nouvel environnement (D'accord, c'est plus un défaut politique qu'un défaut logiciel)
Mars : une erreur d'emploi d'unité => ré-utilisation d'une partie de logiciel calculant en unités ango-saxonnes dans un logiciel plus moderne (je suppose) calculant en SI. Là encore, insuffisance de test et de simulation.
Bref, la ré-utilisabilité, ce n'est pas gratuit.
Une interface "boîte noire" est séduisante. Mais elle se présente à l'utilisateur sans spécifier réellement ce quelle fait : on ne connaît que la signature des méthodes, mais on ne connaît rien des spécifications réelles. Alors, si on ne fait pas un test sérieux ...
Bien. Je sais que l'OO apporte quelque chose, qu'une classe bien conçue, c'est chouette à utiliser.
Mais je pense que celà a un prix, et que dans certains cas, la programmation "procédurale" reste non seulement plus efficace, mais aussi plus naturelle. Et j'ai l'impression que le courant de pensée actuel présente l'OO une technologie de programation incontournable, une véritable panacée. On fait de l'OO pour faire de l'OO.
Ceci dit, je crois que l'on a bien divergé par rapport au sujet de cette discussion. Je m'en excuse, je ne suis qu'un "semi-professionnel".
Merci à tous, en tous cas pour les avis éclairés qui sont publiés sur ce forum.
Euh oui, en koi la POO est en cause là-dedans au juste ?Citation:
Envoyé par BisonDiligent
Reprendre des modules et les coller ailleurs, ça se fait aussi en procédural, depuis longtemps, avec les mêmes implications.
Tu peux appliker le même raisonnement à tout et n'importe koi hein, ça ne veut strictement rien dire :)
À kand un "la canicule de l'été dernier, c'était la faute à la POO" ? :)
Pi bon, je doute ke ki ke ce soit ici soit en position de commenter ce ki se passe dans l'aérospatiale. C'est "un peu" plus pointu ke l'essentiel des projets ke le commun des développeurs fait à longueur de temps. Des erreurs ki n'auraient aucune importance en entreprise peuvent causer de gros dégâts en l'air.
Alors les critiker parce k'ils n'ont pas bien testé (ouh les feignasses) alors k'on n'a pas la moindre idée de ce ke ça demande, c'est un peu facile.
Et je pense ke tu as tort. Tu ne parles ke du côté "réutilisation" (et encore), k'on peut très bien reproduire en procédural (ou plutôt, ki existait déjà en procédural avant ke la POO existe).Citation:
Mais je pense que celà a un prix, et que dans certains cas, la programmation "procédurale" reste non seulement plus efficace, mais aussi plus naturelle. Et j'ai l'impression que le courant de pensée actuel présente l'OO une technologie de programation incontournable, une véritable panacée. On fait de l'OO pour faire de l'OO.
Les principaux avantages de la POO se situent en dehors du contexte "pissage de code". Va faire de la maintenance sur kks millions de lignes de code procédural. Va :)
D'où l'interet du langage objet qui "encapsule" les méthodes avec leurs données: ainsi pas de problèmes du au fait qu'on emploie une méthode dans un environnement non-adapté... La méthode apporte son propre environnement (virtuel) avec elle.Citation:
Envoyé par BisonDiligent
Ce que tu présentes là, c'est une boite noire mal développée.Citation:
Une interface "boîte noire" est séduisante. Mais elle se présente à l'utilisateur sans spécifier réellement ce quelle fait : on ne connaît que la signature des méthodes, mais on ne connaît rien des spécifications réelles. Alors, si on ne fait pas un test sérieux ...
Une boite noire correctement développée s'accompagne TOUJOURS d'une documentation expliquant ce que chacune de ses interfaces fait... La seule chose d'une boite noire qui est censée être ignorée de son utilisateur en informatique, ce n'est pas ce qu'elle fait, mais comment elle le fait.
Propagande de ceux qui vendent de l'OO, ni plus ni moins.Citation:
Et j'ai l'impression que le courant de pensée actuel présente l'OO une technologie de programation incontournable, une véritable panacée. On fait de l'OO pour faire de l'OO.
L'OO c'est génial, mais c'est génial uniquement dans le contexte pour lequel l'OO a été créé... L'OO ne replacera jamais avantageusement un langage concu pour un domaine qui n'a pas été visé par l'OO au départ.
Par exemple, le C a été fait pour la programation système, l'OO non... donc l'OO n'a aucune raison ni avantage à être employé en programation système.