Discussion :

[hpfx]

Salut,
merci pour tes reponses, bon avant tout c'est vrai que je n'y susi pas allé de main morte avec dot net, c'est vrai aussi que c'est un language d'avenir. (une des seules chose que j'aime dans vb.net c'est le try...catch). je tiens a m'excuse du ton que j'ai employé, c'est le cri du coeur

Ils ont cependant quasiment tous étaient remplacés par des équivalent ou restent interopérable.

Oui, bon, moi perso c'est winsock et shape que je n'avais pas trouvé, mais si tu me dis qu'il y a un remplacement...

La plupart de ceux qui ont migré du VB6 vers VB.NET disent l'inverse.

Ben, en tout cas dns les version 2001 puis 2003 il semblerait que microsoft lui même admete que la philophie de vb dot net n'était pas la même que VB6 (ou du moins ils n'y étaient pas encore arrivé)

Rick LaPlante, general manager of Visual Studio Team System, said, "We are focusing on how we make sure the VB experience comes back. The Whidbey (Visual Studio 2005) product gives VB its VB back."

J'espere que c'est bon cette fois (lien

Moi s'espere de tout coeur qu'un jour vb.net puisse être le remplacement de VB6 de maniere indiscutable. (et là, oui pour le coups je veux bien oublier le gros framework etc...)

Mais bon,
un petit lien pour la route, c'est un comparatif de performance entre VB6 et VB.NET
vous avez remarqué que jamais la performance n'est cité dans les bonnes raisons de migrer (c'est marrant parceque si ca tournais 2x plus vite je suis sur qu'on n'hesiterais pas une seule seconde a en parler)
http://plasserre.developpez.com/v7-3.htm
premier test, code identique, 7 secondes en VB6, 25 en .net2003 et 45 en .net2005
deuxieme test, ce n'est pas le même code (en VB6 : un tri le plus naze possible) alors qu'en .net il s'agit d'une fonction optimisé (tel que qsort) donc forcement on ne teste plus le language.
Bref, on ne peux rien dire car il faudrait d'autres tests.

D'un autre coté vb.net apporte pleins de truc (en prog objet)... donc bon...

[bidou]

je n'ai nullement été choqué par le ton de ton message, on a tout à fait le droit d'être passionné

Pour répondre sur ton dernier point, à quoi bon comparer les performances entre un code managé et un code natif puisqu'on sait déjà que le code natif ira plus vite. Cependant la encore, un code C++ ira beaucoup plus vite qu'un code VB6, ce n'est pas pour autant que tout le monde fait du C++

[DarkVader]

mouarf, 56" pour le second test sous VB6 à l'adresse de test http://plasserre.developpez.com/v7-3.htm -
effectivement, il est difficile de dire que le code y est optimisé - cela manque un peu d'objectivité comme exposé.
Sous l'ide avec un athlon64 3200 et sans utiliser l'api qsort de ntdll, j'ai obtenu 8/1000ème soit environ 100 fois plus rapide que le test sous vb.net.
Même en multipliant par 2 le résultat afin d'être en correspondance avec le 1er test sous P4 (9"/4") -
il n'y a toujours pas photo - c'était juste pour rétablir un peu vérité.

VB6 est bien 10 à 50 fois plus rapide que VB.net quelquesoit le test
mais comme le dit Bidou ce n'est pas la même chose.


PS: je serais curieux de connaitre les résultat de ces 2 tests sous C++

[jmfmarques]

J'ajouterais bien volontiers à ce que vient d'exprimer DarkVader et qui m'est très largement confirmé sur un autre forum (anglophone) de grand renom, que :

- "Au runtime" : les dlls de Windows utilisées sont finalement (lors de l'exécution finale) les mêmes ... et pour cause ...
- que plus un langage est "évolué", plus il passe par des tremplins alourdissants...
VB.Net n'apporte rien d'autre que des facilités de développement, au détriment notable de la performance....
Il n'est, au bout du compte, qu'une espèce de leurre...

Ceux qui, déjà, savent éviter au maximum d'utiliser les "facilités" de VB, donnant la préférence à des appels directs de l'API, savent également ce que je veux dire.

[bidou]

J'ajouterais bien volontiers à ce que vient d'exprimer DarkVader et qui m'est très largement confirmé sur un autre forum (anglophone) de grand renom, que :

- "Au runtime" : les dlls de Windows utilisées sont finalement (lors de l'exécution finale) les mêmes ... et pour cause ...
- que plus un langage est "évolué", plus il passe par des tremplins alourdissants...
VB.Net n'apporte rien d'autre que des facilités de développement, au détriment notable de la performance....
Il n'est, au bout du compte, qu'une espèce de leurre...

Ceux qui, déjà, savent éviter au maximum d'utiliser les "facilités" de VB, donnant la préférence à des appels directs de l'API, savent également ce que je veux dire.

Voila une des plus faramineuses inepties qu'il m'ait été donné de lire.

Merveilleux, il faut un forum de grand renom pour découvrir qu'in fine, ce sont toujours les fonctions système qui sont appelées. J'ai bien fait de me lever ce matin, je ne m'en serais pas douter autrement.

VB.NET n'apporte rien d'autre que des facilités de développement dis-tu?
J'aimerais déjà comprendre comment quelqu'un qui ne connaît visiblement rien à la plate forme DotNet peut se laisser aller à un tel jugement. Pour toi la sécurité du code, la protection du système, un accès enfin clair aux données, les web services, le multi-threading et j'en passe, tout cela ne sont que des facilités de développement. Un tel propos est plus signe d'ignorance de ce qu'est la réalité du monde du développement qu'autre chose.

Enfin ce sont biens les fameux "Appels directs de l'API qui ont été ces dix dernières années responsables de la plupart des failles de sécurité.

Raisonner aujourd'hui en termes de performance uniquement, c'est l'archétype d'une pensée coincée dans ses certitudes. Cela m'étonne de voir des développeurs VB6, qui ont généralement fais le choix d'échanger de la performance contre la vitesse de développement se faire les chantres de la performance le jour ou ils se sentent menacés.

J'ose espérer qu'il ne s'agissait la que d'une tentative de troll pathétique, car si tu penses vraiment ce que tu viens d'écrire, il va devenir urgent d'ouvrir les yeux…

[jmfmarques]

Pour toi la sécurité du code, la protection du système, un accès enfin clair aux données, les web services, le multi-threading et j'en passe, tout cela ne sont que des facilités de développement.

Drôle de question !

Je persiste et signe donc ...
VB.Net ne fait rien d'autre que de rendre aisé ce que l'on peut faire autrement.
Rien (absolument rien) n'empêche quiconque de développer ses propres outils, une fois pour toutes, et (et c'est là la grande différence en matière de performances finales) de n'ajouter à son application que ceux dont elle a besoin.

L'ouverture des yeux, pour moi, se fait de la façon suivante, pour chacune de mes applications :

Je branche une très vielle machine dédiée et de surcroît affaiblie : underclocking (le contraire de l'overclocking) afin de passer des 850 Mhz d'origine à seulement 350 Mhz...
Disque très lent et super fragmenté
Ram de 256

Et je chronomètre, ma foi...
Et je reviens vers mon appli (ou l'abandonne) si le temps de réaction (calculs en boucle, graphiques, etc...) n'est pas satisfaisant dans ces conditions lamentables.

Même certaines applis créées sous VB ont ainsi finalement été réécrites avec QBasic ou RapidQ pour les rendre plus "acceptables"

C'est donc tout le reste (ce qui n'est pas performance) qui est pour moi, depuis des années et sous différents systèmes d'exploitation (y compris sous Pick) une vue de l'esprit...

Mais je reconnais bien évidemment à chacun le droit de choisir comme il l'entend entre confort de développement et performance d'exécution... c'est son affaire.

[bidou]

Drôle de question !

Je persiste et signe donc ...
VB.Net ne fait rien d'autre que de rendre aisé ce que l'on peut faire autrement.
Rien (absolument rien) n'empêche quiconque de développer ses propres outils, une fois pour toutes, et (et c'est là la grande différence en matière de performances finales) de n'ajouter à son application que ceux dont elle a besoin.

Ah bon, tu es donc le seul être humain sur terre à pouvoir garantir qu'un plantage d'une application native ne plantera pas le système.

Ton code VB6 sait reconnaitre la provenance de son code appelant ?

Je persiste et signe aussi, tu parles de choses que tu ne connais pas.

Même certaines applis créées sous VB ont ainsi finalement été réécrites avec QBasic ou RapidQ pour les rendre plus "acceptables"

Oui, en C ce serait trop lent

C'est donc tout le reste (ce qui n'est pas performance) qui est pour moi, depuis des années et sous différents systèmes d'exploitation (y compris sous Pick) une vue de l'esprit...

Donc si je te suis bien, tu as choisi un des langages ayant les moins bonnes performances des langages natifs pour obtenir des programmes dont le seul critère est la performance. Désolé père, Ubu, mais la je dois dire que c'est incompréhensible.

Mais je reconnais bien évidemment à chacun le droit de choisir comme il l'entend entre confort de développement et performance d'exécution... c'est son affaire.

Absolument. Ce n'est pas la liberté de choix que je conteste mais l'irréalité de ton propos...

[DarkVader]

Bonjour,
Pour répondre à ta question d'origine, Bidou -
J'ai testé la 1ère version béta de .net quand elle est sortie il y a 4 ou 5 ans.
La convivialité de l'interface (la notion de région ... si j'ai bonne mémoire ... permettant une meilleure lisibilité du code)
la facilité de passer de VB6 à .net et sa richesse m'ont laissé une impression plus que positive,
toutefois, à l'époque, la taille du framework conjointement au fait que l'adsl était encore confidentiel,
la relative lenteur du code et les incertitudes sur la diffusion de cette technologie m'ont incité à rester à l'écart.

Aujourd'hui, les motifs de refus de l'époque se sont réduits à peau de chagrin puisque qu'avec XP le framework est distribué d'office
et au pire sa distribution via l'ADSL ne demande plus qu'un temps relativement court.
Toutefois, mon soucis actuel est la migration de librairies personnelles conséquentes
et comme l'outil fourni ne supprime pas la nécessité de réécriture de l'intégralité du code ...

En dehors de ces considérations, une première interrogation :
Les similtudes entre VB.net et C# laissent à penser que .net n'a été développé que pour inciter les utilisateurs VB à sauter le pas
et j'imagine que dans un passé plus ou moins proche, les 2 languages n'en feront plus qu'un seul -
d'où mon interrogation si je saute le pas à passer directement à C#.

Ma seconde interrogation sur laquelle je n'ai aucune indication et qui pourra te sembler naïve
concerne la capacité de .net à résister au piratage logiciel.
Quid de la lecture et l'interprêtation du language natif de .net ?

[jmfmarques]

Bidou, qui écrit avec un certain ... "humour" :

Oui, en C ce serait trop lent

semble ne pas se souvenir de ce que j'ai déjà écrit dans cette discussion.

Pour mémoire :

http://www.developpez.net/forums/sho...1&postcount=52

C'est en effet vers le C que (comme DarkVader) je retournerais, si nécessaire, pas vers VB.Net.

Ne serait-ce que pour ne pas continuer à me prêter à un jeu finalement assez vicieux qui ressemble fort à celui de l'âne et de la carotte.
Je ne serai certainement pas l'un des acteurs de ce jeu là, que semble mener avec assez d'"entrain" MS.

[bidou]

Bonjour,
En dehors de ces considérations, une première interrogation :
Les similtudes entre VB.net et C# laissent à penser que .net n'a été développé que pour inciter les utilisateurs VB à sauter le pas
et j'imagine que dans un passé plus ou moins proche, les 2 languages n'en feront plus qu'un seul -
d'où mon interrogation si je saute le pas à passer directement à C#.

Je l'ai cru aussi ce qui m'a fait attendre la version 2003 avant de me décider à franchir le rubicon . Cependant les évolutions de VB 2005 et celles déjà annoncées pour VB9 montre qu'il y a bien une intention de maintenir les deux langages en côte à côte. Evidemment, si tout le monde s'orientait vers C# je ne serais pas tranquille pour l'avenir de VB, mais en l'état actuel, il me semble avoir un bel avenir.

Ma seconde interrogation sur laquelle je n'ai aucune indication et qui pourra te sembler naïve
concerne la capacité de .net à résister au piratage logiciel.
Quid de la lecture et l'interprêtation du language natif de .net ?

La question est loin d'être naive car cette interrogation est fondée. A l'heure actuelle, la protection du code repose sur la qualité des obfuscateurs. C'est un point faible évident, même si la plupart des personnes capables de lire du code obfusqué sont aussi capable de faire du reverse engineering sur un binaire. Mais en effet, il y a la un problème potentiel...

C'est en effet vers le C que (comme DarkVader) je retournerais, si nécessaire, pas vers VB.Net.

Si les performances étaient fondamentales comme tu le prétends, tu n'aurais certainement jamais du faire autre chose que du C, en l'état c'est plus ta pratique actuelle du VB qui m'épate que ton éventuel choix futur...

Ne serait-ce que pour ne pas continuer à me prêter à un jeu finalement assez vicieux qui ressemble fort à celui de l'âne et de la carotte.
Je ne serai certainement pas l'un des acteurs de ce jeu là, que semble mener avec assez d'"entrain" MS.

Tout dépend toujours de ce qu'on pense être le rapport investissement/résultat. Pour ma part j'en suis satisfait, mais je peux tout à fait comprendre un certain nombre de réticences. Encore faut il s'être penché sur le sujet de façon objective...
Car si je n'ai pas lu tout tes sujets, il me semble bien me rappeler que tu fais du VB5 et non du VB6. Comme le VB5 est un langage interprété, l'argument des performances est encore moins recevable qu'en VB6. Bref, je comme je l'ai dis précédemment, je ne trouve pas tes arguments valables.

[Delbeke]

Comme le VB5 est un langage interprété

Hé non, c'est du natif, dixit MicroSoft, qui en faisait son argument massue pour migrer depuis VB4.

[jmfmarques]

Voilà comment on vante ici les mérites du C par rapport à VB.
Citation (Bidou) :

Si les performances étaient fondamentales comme tu le prétends, tu n'aurais certainement jamais du faire autre chose que du C, en l'état c'est plus ta pratique actuelle du VB qui m'épate que ton éventuel choix futur...

Je me suis en effet laissé avoir par d'autres, qui, défendant VB comme Bidou vante aujourd'hui les mérites de VB.Net, ont fini par déplacer mon regard
Je m'en suis toujours mordu les doigts... (mais bon.... :
1) ces choses-là sont comme la bicyclette : on y revient sans problèmes...
2) le langage finit toujours par céder le pas à la capacité d'analyse et de réflexion, comme je l'ai toujours dit... Il n'est qu'un moyen d'expression... et C'EST TOUT
3) J'ai depuis 5 mois ce qu'il faut pour installer VB6, mais ne le ferai pas, car celà ne m'apporterait rien de plus ... Ce qu'offre VB6 de plus par rapport à VB5 ? ... elle est bien bonne ! rien qui n'ait été résolu depuis longtemps par mes propres outils !....
4) Tiens ! Bidou surveille de près ce que j'utilise (il sait ainsi que je n'ai pas installé VB6... Qu'il cesse donc de perdre son temps à s'intéresser ainsi à un développeur (jmf) qui ne vaut rien... et dont les applications... pourtant vendues ... n'intéressent que les naifs... )

Tout cela est assez surprenant ...

[hpfx]

bonjour DarkVader, je partage exactement la même demarche que toi (test vb.net il y a 4/5 ans...)

puisque qu'avec XP le framework est distribué d'office

Là par contre, non, un XP tout nu ne possede pas de framework, même apres le windows update de secu, par ex : au boulot, j'installe des XP+Office+quelques soft (SAP R3...) et il n'y a pas de framework.

En dehors de ces considérations, une première interrogation :
Les similtudes entre VB.net et C# laissent à penser que .net n'a été développé que pour inciter les utilisateurs VB à sauter le pas...

C'est exactement ce que je pense (j'osais pas le dire de peur qu'on me traite de parano), apres tout, microsoft avait besoin de plus de dev sous C# (ou plutot "dot net") face a java.. et ca marche.

et pour en revenir a la question de performance :
pour moi, il y a deux choses, et il faut trouver un equilibre :
1) un language suffisament facile (pas de l'ASM par exemple) pour être performant en tant que dev.
2) faire en sorte que le temps gagné en dévelloppant ne se paye pas a l'execution pour mes utilisateurs.

et pour moi :
* VB6 est ok pour 1) et 2)
* VB.net est ok pour 1) seulement.
alors bien sur C++ et C sont ok pour 2) mais vu que j'ai perdu l'habitude de ces languages... pas pour 1)

PS jmfmarques, ton nom ne m'est pas inconnu (dans l'univers informatique, pas dans la vraie vie) mais je ne sais plus d'ou peut être tout simplement ici sur ce forum.. ou peut être as tu un site web qui parle de VB/autre ?

[bidou]

@jmfmarques >> Ton dernier message ne contenant absolument aucun argument je serai bien en peine de répondre quoi que ce soit. Par contre il s'agit d'un débat technique et pas d'un troll. Avoir la mauvaise foi d'écrire

Tiens ! Bidou surveille de près ce que j'utilise (il sait ainsi que je n'ai pas installé VB6...

Alors que tu as répété dans des dizaines de messages que tu utilisais VB5 montre bien que tu essayes de détourner le sujet dès que tu n'as plus (pas) d'arguments. Merci de t'en tenir strictement au débat technique sur ce sujet et de réserver les trolls pour la taverne....

Bon ca c'est fait

Hé non, c'est du natif, dixit MicroSoft, qui en faisait son argument massue pour migrer depuis VB4.

ce n'est que partiellement du natif puisque tu ne peux pas exécuter ton code sans le runtime. Il existe toujours une part de code interprété en Visual basic quel qu'il soit d'ailleurs. Le fait qu'on constate des différences de vitesse entre VB5 et VB6 est par ailleurs du à l'optimisation de la compilation VB6

et pour en revenir a la question de performance :
pour moi, il y a deux choses, et il faut trouver un equilibre :
1) un language suffisament facile (pas de l'ASM par exemple) pour être performant en tant que dev.
2) faire en sorte que le temps gagné en dévelloppant ne se paye pas a l'execution pour mes utilisateurs.

et pour moi :
* VB6 est ok pour 1) et 2)
* VB.net est ok pour 1) seulement.
alors bien sur C++ et C sont ok pour 2) mais vu que j'ai perdu l'habitude de ces languages... pas pour 1)

C'est une analyse qui en vaut une autre. Cependant Delphi présente de bien meilleurs performance que VB6 tout en étant assez similaire en facilité. Tu fais donc bien une concession aux performances utilisateurs pour garder un code qui t'es plus familier (n'y vois pas un quelconque reproche, je fais pareil )
Dès lors qu'on parle de logiciel utilisant une grosse IHM, c'est à dire dans le domaine principal d'utilisation de VB6, on sait bien que la performance percue et la performance réelle sont deux choses tout à fait différentes. Il en est de même pour VB.NET. Par ailleurs, VB.NET permet des choses qui ne sont pas accessibles en VB6, donc le débat ne peut se réduire simplement à la performance.

[jmfmarques]

On avance ici le mot troll...

Alors, voyons donc :

La question principale posée était :

Ce message s'adresse à tout ceux d'entre vous qui n'ont pas migré vers VB.NET.
Plusieurs questions se posent.
Comptez vous migrez un jour vers VB.NET et sinon pourquoi ?

Et ma réponse sera aussi claire (et finalement le résumé de ce que j'ai déjà dit) :
- Je ne compte pas migrer un jour vers VB.Net
- parce que VB.Net me parait être une cause d'aloursissement important (selon ce qui me revient de plusieurs sources indépendantes)

Car il est bien clair, n'est-ce-pas, que ce sujet ne saurait se transformer en autre chose, notamment en une présentation flatteuse de VB.Net, ni à un encouragement à migrer de VB vers VB.Net plutôt que vers un autre langage...

Si la question était maintenant posée différemment, les réponses seraient sans doute elles-mêmes différentes...

Non, il ne va pas de soi que quitter VB implique d'aller vers VB.Net.

Que la question soit donc ainsi posée (hors tout ce qui finirait par paraître une invite, voire de la publicité) :


Comptez-vous continuer à développez sous VB et, si non :
1) pourquoi ?
2) vers quel langage de développement comptez-vous vous tourner ?

[bidou]

Certes, et tu as répondu à la question posée ce dont je te remercie. Cependant le but est justement de pouvoir discuter de ce qui est légitime comme interrogation et de ce qui tient de la légende/propagande/idée préconçue. Et comme nous sommes sur un forum technique, c'est bien d'arguments techniques dont il s'agit.

Je n'impose à personne ni de migrer vers VB.NET, ni de migrer sur autre chose, je ne touche pas d'argent de Microsoft sur les ventes de VB.NET.

Maintenant, quand on me présente des arguments légèrements fallacieux ou carrément mensonger, je démontre leurs faussetés. Il me semble quand même possible d'arriver à discuter technique dans une communauté de technicien sans avoir à employer des méthodes douteuses dont la bouffée paranoïaque dont tu m'as gratifié dans ton précédent message. Maintenant, si tu veux discuter d'autre chose avec moi, nous pouvons soit ouvrir un sujet ici s'il s'agit de technique, soit utiliser des mp s'il s'agit de problèmes personnels, ceci afin de maintenir ce sujet propre.

[DarkVader]

.../... VB.NET permet des choses qui ne sont pas accessibles en VB6, donc le débat ne peut se réduire simplement à la performance.

Je n'ai pas suffisamment pratiqué .net pour avoir une idée précise de ce que tu suggères ici -
tu peux fournir quelques exemples ?

[bidou]

Sans aborder les limitations du à l'aspect non objet de VB6, tu ne peux pas écrire un composant pouvant identifier la provenance de son code appelant.
tu ne peut pas générer de code à la volée.
Tu ne peux pas rendre persistant tes objets.
Tu ne peux pas te désabonner d'un évènement.
etc....

[bidou]

Je vais un peu développer mon propos précédent. La plupart des limitations du langage VB6 ne sont que partiellement pénalisantes, et en l'occurrence il y a de nombreux cas ou les nouvelles fonctionnalités de VB.NET ne sont pas nécessaires. Dans ces cas là, on peut facilement les considérer uniquement comme une facilité de développement, ce qui a mon sens n'est quand même pas négligeable. Il existe aussi un certain nombre de désavantages qui existent dans VB6 et qui persistent dans VB.NET, je rangerai les performances dans cette catégorie là puisqu'il m'est arrivé de nombreuses fois et qu'il m'arrive encore d'écrire des fonctions C quand les performances l'exigent.

Il n'en demeure pas moins vrai qu'il existe aussi des limitations VB6 que VB.NET ne connait pas. Je pense que le choix de se lancer dans un langage managé n'a pas été seulement dicté à Microsoft par la volonté de concurrencer JAVA, mais par le constat que les environnement managés présentent des avantages en termes de sécurité et de fiabilité que les langages natifs n'obtiendront jamais, et que dans un futur assez proche, la plupart des logiciels seront des codes managés.

Dans un domaine en permanente évolution comme le développement informatique, je ne saurais dire si cette analyse est bonne. Cependant je constate que la stabilité des applications, la vitesse de développement, l'approche objet dans certains cas rendent VB.NET tout à fait intéressant, d'autant que contrairement à l'idée reçu générale, la migration est assez facile.
Je reste par contre dubitatif quand à la nécessité de migrer les codes existant dès lors qu'on n'a pas besoin de les faire fortement évoluer, si ce n'est l'aspect "travaux pratiques" qui peut être formatrice.
Je ne cherche pas à bruler ce que j'ai adoré, j'ai utilisé les versions COM de VB avec satisfaction pendant des années et ce ne sera certainement pas moi qui dénigrerais VB6, mais de toute façon l'évolution des machines et des standards forcera chaque développeur VB6 à changer de langage tôt ou tard. Il n'existe certainement pas de réponse universelle à cette évolution, mais pour ma part je crois qu'il n'est jamais bon d'attendre le dernier moment pour affronter les obstacles.

[DarkVader]

Ces précisions sont très intéressantes - il semble toutefois que l'inverse existe aussi -
j'ai par exemple à l'esprit un domaine supporté par VB6 qui (sauf erreur) ne l'est plus sous .net, c'est la gestion DDE.

La technologie est ancienne mais très utilisée dans les applications financières pour délivrer aux applications tierces des données en streaming.