Discussion :

[doccpu]

...
j'ai du mal a voir ce qu'apporte vraiment le .net en vous lisant. Il (C#+VB) n'est portable que sous windows contrairement a delphi que je connais un peu et au c/c++/java au je connais deja un peu mieux. J'ai plus une vague impression de récupération de développeur Java grâce à une vitesse d'execution plus rapide mais pour une portabilité réduire à un environnement (certes très répandu)

Je ne suis pas un expert du developpement mais quand certains parlent de portabilité, je crois savoir que Microsoft n'a pas tout donné et que les projets dotgnu et mono doivent recourir a un gros boulot pour voir les appels passés en mémoire.

Par contre, si j'avais eu a choisir, j'aurais pris ni VB .NET ni C# mais plutot Delphi ou C++.

Je suis pour un langage ouvert, non prorietaire... et portable. Le .net est une bonne chose et rationnalise je pense le dev quel que soit le langage sous windows. Je reste plus pour un langage qui soit independant de la plateforme comme le C++ qui permet de faire des applis sous Linux ou Windows. développer en .Net apporte rien de plus a priori ou de revolutionnaire par rapport à ce qui existaient deja chez les autres si ce n'est que cela sort estanpillé par Microsoft ( ce qui n'est pas forcement un mal).

t'a bu, t'est miro ou quoi ?

1-mono fonctionne sous linux!
2-vb.net est plus contraignant que C# (dim a chaque fois, end ..., le gros mot "GOTO", et le type "sale' : "Variant")
3- tu trouve que C++ ou delphi est "ouvert" ?

4-DOTNET fonctionne sous Apple MAC OS

[ulysse31]

t'a bu, t'est miro ou quoi ?

1-mono fonctionne sous linux!
2-vb.net est plus contraignant que C# (dim a chaque fois, end ..., le gros mot "GOTO", et le type "sale' : "Variant")
3- tu trouve que C++ ou delphi est "ouvert" ?

Bonjour Doccpu

je ne veux pas troller et j'apporte un avis sur le topic. Par contre, je voudrais pas que cela tourne comme au début des avis avec Maniak et Moonheart dont le premier etait particulierement agressif ce qui ne fait pas avancer le debat. Donc je ne suis pas Miro et je n'ai pas bu (sans me mouiller surement moins que toi vu que je n'aime pas l'acool) et un peu de respect stp.

Pour repondre a tes propos
1)Mono fontionne sous Linux : oui je sais et je l'ai essayé sous tux dans ses débuts mais on ne peut pas tous faire et cela reste un travail ardue pour porter un truc proprietaire MS sous un systeme Libre respectant des standard posix
2)Delphi n'est pas "ouvert" mais fait preuve d'ouverture en permettant un developpement sous la plate forme de son choix
3)le C++ est un langage standard comme le C (en respectant la norme ANSI). Tu le prend et tu compiles sous win (avec wxwindows st ou gtk si tu utilises des formes) ou sous tux et ca roule. C'est ce que j'appelle être "ouvert", tout du moins bien plus que .Net, bien sur cela reste mon avis uniquement ce qui etait le but premier de mon propos.

Pour faire suite aussi a un de tes messages precedant comme quoi vbnet fait moins professionnel c'est une vue restreinte a ton ideal. J'ai cru pour 'un miro' comprendre que tout etait traduit dans l'IL, alors vbnet ou C# quelle difference pourvu que chacun y trouve son compte.

[Maniak]

je voudrais pas que cela tourne comme au début des avis avec Maniak et Moonheart dont le premier etait particulierement agressif ce qui ne fait pas avancer le debat.

Mmh ? Qu'est-ce que je viens faire là-dedans ? :)
Et je ne me souviens pas avoir été "particulièrement agressif".

Particulièrement dur avec l'héritage de VB6 par contre, ça oui :)

Pour faire suite aussi a un de tes messages precedant comme quoi vbnet fait moins professionnel c'est une vue restreinte a ton ideal. J'ai cru pour 'un miro' comprendre que tout etait traduit dans l'IL, alors vbnet ou C# quelle difference pourvu que chacun y trouve son compte.

C'est pas sur du MSIL qu'on bosse, mais sur le langage choisi. C'est là qu'il peut y avoir des complications :)

Maintenant l'important c'est que les projets soient faits, fonctionnent et que le client soit content, dans la durée. Le reste est accessoire.

Sinon un petit détail :

2-vb.net est plus contraignant que C# (dim a chaque fois, end ..., le gros mot "GOTO", et le type "sale' : "Variant")

VB.NET n'est plus contraignant que C# que si on fait du VB.NET 'propre' (Option Explicit+Strict, Try/Finally pour tous les objets implémentant IDisposable, ce genre de choses).

Je ne suis juste pas sûr que ça corresponde à la majorité des développeurs VB.NET. Mais il y en a, ça je n'en doute pas, et on peut faire du code tout aussi crade en C#, Delphi ou n'importe quel autre langage. C'est peut-être juste plus facile/tentant en VB :)

[doccpu]

Je ne comptais pas troller non plus mais t'a mal pris ma boutade domage ulysse. au fait coment vas penelope ?

Sinon un petit détail :

2-vb.net est plus contraignant que C# (dim a chaque fois, end ..., le gros mot "GOTO", et le type "sale' : "Variant")

VB.NET n'est plus contraignant que C# que si on fait du VB.NET 'propre' (Option Explicit+Strict, Try/Finally pour tous les objets implémentant IDisposable, ce genre de choses).

Je ne suis juste pas sûr que ça corresponde à la majorité des développeurs VB.NET. Mais il y en a, ça je n'en doute pas, et on peut faire du code tout aussi crade en C#, Delphi ou n'importe quel autre langage. C'est peut-être juste plus facile/tentant en VB

Je ne consoit pas de faire du code "sale" (autant que possible) car qui dit code sale dit mauvaise lecture ce qui entraine a dire mauvaise maintenance ! Maintenant si tu comte juste faire un code qui t'afiche bonjour sur un click de bouton tu le fais un peu comme tu veux ....

[Maniak]

Je ne consoit pas de faire du code "sale" (autant que possible) car qui dit code sale dit mauvaise lecture ce qui entraine a dire mauvaise maintenance !

On est d'accord. Maintenant, je peux te sortir des trouzaines d'exemples de 'gens' (je ne peux pas les qualifier de développeurs, même s'ils sont payés pour ça) que ça ne gêne absolument pas. Ça leur simplifie la vie, peu importe si ça complique les choses plus tard. C'est plus tard.

Et je crains d'avoir croisé beaucoup plus de 'gens' avec cette approche que de dévs qui se préoccupent vraiment de la qualité de leur code.

Ça, c'est un problème de plus haut niveau que le choix du langage. Quoi qu'on choisisse, le langage seul ne suffit pas à obtenir du bon code ou une espèce de bouillie inutilisable. On peut faire du très bon et du très mauvais code avec n'importe quel langage. Là où on peut commencer à faire des distinctions, c'est si tel ou tel langage a plus ou moins de barrières pour pousser les développeurs à faire du code de qualité.

Le fait que VB.NET permette de s'affranchir du typage et des déclarations de variables et surtout le fait que ce soit essentiellement utilisé par fainéantise (et/ou incompétence) du développeur, c'est ce que j'ai principalement contre ce langage.

Au final, ce n'est pas tellement le langage qui me gêne (les préférences syntaxiques sont purement subjectives, c'est uniquement matière à troll, je vais éviter ça pour ce post :), mais ceux qui utilisent les libertés qu'il permet pour se simplifier la vie et compliquer celle des autres.

Donc à choisir, quand il y a des doutes sur le sérieux et/ou les capacités des dévs, autant prendre un langage qui permet moins de 'simplifications' de ce genre. Ou former les dévs pour qu'ils n'en abusent pas, en espérant qu'ils écouteront. Partant de là, le choix du langage importe peu :)

Si je me retrouve à devoir maintenir une appli dont le code a été bien fait, que ce soit du VB.NET ou du C#, aucune importance, je serai aux anges.
Si c'est une appli faite par un branleur incompétent, VB.NET ou C#, j'aurai envie de me pendre. Mais au moins si c'est du C#, je n'aurai pas à me taper les problèmes supplémentaires causés par l'absence de déclarations et de typage quand celui qui a pondu le code aurait mieux fait de se casser une jambe le jour de son entretien d'embauche :)

[verre d'eau]

quelques différences de performances sont visibles mais rares

J'ai effectivement trouvé un site qui teste différentes techno .net pour les mêmes programmes et qui trouve des différences (au niveau math et I/O) !
Benchmarking Math & File I/O
Résultat pour les tests effectués (il en manque je suis d'accord) : C# va plus vite...
Moi qui croyais que tous les programmes .net donnaient le même code intermédiaire...

[Kikos31]

Résultat pour les tests effectués (il en manque je suis d'accord) : C# va plus vite...

Allez c'est reparti

Comme quoi les gens voient ce qu'il veulent bien voir...
Ce benchmark est justement la confirmation que je cite :

tous les programmes .net donnaient le même code intermédiaire...

Si tu regarde un peu plus attentivement tu verra que le C# et le VB ont exactement les mêmes performance sauf sur les I/O. L'un est un cheveux plus rapide sur les int et l'autre un poil plus rapide sur les long (certainement des imprécisions de mesures).

Visual C# 9.7 23.9 17.7 4.1 9.9 65.3
Visual Basic 9.8 23.7 17.7 4.1 30.7 85.9

Et pour la différence sur les I/O pas de grand mystère y 'a qu'a regarder les sources des benchs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 FileOpen(1, fileName, Microsoft.VisualBasic.OpenMode.Output)
        Do While (i < ioMax)
            PrintLine(1, myString)
            i += 1
        Loop
        FileClose(1)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
StreamWriter streamWriter = new StreamWriter(fileName);
				while (i++ < ioMax)
				{
					streamWriter.WriteLine(textLine);
				}
				streamWriter.Close();

Et oui l'exemple C# utilise la classe I/O native de .net alors que l'auteur du bench a fait le choix discutable d'utiliser les fonctions de fichiers de compatibilité VB6.

Si tu as du temps a perdre tu peux recompiler l'exemple C# avec FileOpen (en ajoutant une ref à la MicrosoftVisualBasicgnagna.dll) ou plus simplement en utilisant dans VB.NET l'objet streamWriter (chose qui aurait du être fait par l'auteur du bench si il avait été sérieux).

A+

[neo.51]

Tout à fait d'accord avec Kikos31 si on utilise pas les mêmes classes on aura pas les mêmes perfs ça c'est sur

Mais bon je crois qu'on ne peux pas sérieusement choisir tel ou tel langage pour des raisons de performances car justement les différences de perf se feront plutôt au niveau du code créé ("propre" ou pas) qu'au niveau du langage

J'ai quand même constaté quelque chouillas de différences entre 2 codes identiques C# et vb.net mais faudrait aussi regarder les options de compilation par défaut de VS.NET qui diffèrent selon le langage utilisé

[verre d'eau]

ouf !!
Me voici soulagée !

Merci

[Floyd]

Salut tous le monde;
Étant nouveau sur developpez.net, je voulais repondre dans le débat “quel language préférez-vous pour le développement web” mais j'ai pas l'autorisation en faite ma réponse est sans hésitation ASP.NET (C#) mais je me retrouve obligé mal heureusement d'utilisé PHP, et voila ma problématique

Je travail sur une référence bibliographique XML-basé, et je suis obligé de faire une double transformation vu les possibilités limitée de XSLT, donc une deuxième transformation est obligé mais là j'ai grand problème car je doit appelée un objet par espace de nom et une méthode de cette objet pour chaque élément du fichier Xml

Exemple
voici un fichier
<!--Déclarations des espaces de noms des DTD et... -->

<PolyCop Name="Introduction en Odontologie-Concervatrice">
<Paragraphe>
L'OC est une <Lien Vers="...">décipline</Lien>...
</Paragraphe>

<!-- Jusque là des balises que je peut transformer en XSLT -->

<Math:Graphe ... />
<!-- Je ne peut pas déssiner un graphique en XSLT -->
</PolyCop>

Donc je doit déssiner le graphe à l'aide d'un language Web dynamique

Vue qu'il y a environ 200 elements pour débuter, je ne vais pas m'amuser a faire
switch(espacedenom){
case "Math":
// ... un autre switch pour les methode de chaque objet
break;


je veut créer ces objets et appelé leur méthodes dynamiques comme je peut faire en Php

$objet->$nomDeLaMethod($tableauDesAttribue);

Si ce n'est pas possible en C#, ce côté Hyper-dynamique du polymorphisme Php doit être plus ilucidé dans la comparaison des languages car ma solution deviens hyper irréalisable si j'utilise des fichiers DLL externe

[Kaktus]

Je crois surtout que dans 90% des projets, utiliser tel ou tel langage ne change pas grand chose, surtout sur cette plateforme qu'est Dot Net.

Sur quoi se base le choix d'un langage ? Eh bien, surtout sur la culture de la boite; le coût; la portabilité ... Les performances venant bien après.
A part sur des projets industriels et très lourd (où la ben C/C++ a la grosse part du gâteau), difficile de trancher objectivement.
Dire tel langage est mieux que celui-là (perso, c'est c++ ) est bien prétentieux et surtout personnel.

L'histoire du "VB c'est pour ceux qui savent pas programmer" est à mon avis faux. Tout repose sur le programmeur lui-même, on peut utiliser aussi des GOTO en C et variant existe ailleurs que dans VB.
La seule différence est que VB tolère plus facilement le mauvais codage avec une profusion de possibilités un peu limites, faut bien le dire, mais qui oblige à les utiliser? Personne.

On peut très bien faire une architecture de classes (avec VB.NET) tout à fait digne d'un javaman, seulement il faut se faire violence car VB.NET ne l'impose pas (en java ou C++ essaie toujours héhé ... ).


Sur VB, l'énorme reproche que je lui fait est la non-compatibilité entre les versions (l'arrêt des up de VB6 cause un sacré bazar ... ), en fait, plus la politique menée que le langage lui-même.
Sur C sharp, malgré tout le tapage fait par microsoft (mm dans le bouquin de Visual c++ lol) en faveur de leur bb, je suis assez suspicieux sur l'avenir de ce langage. La sauce ne prend pas facilement et hormis quelques projets, j'avoue que je ne vois pas grand chose en C# actuellement.


J'ai voté VB.Net (sur DOT NET je précise), il permet de concevoir des projets rapidemment, de façon efficace.
Je ne vois pas l'intérêt de s'embêter avec les MFC (visual C++) - toujours pour les 90% de petits projets je précise-
C# me semble plus commercial que réellement utile actuellement.
Delphi, je ne connais pas.

[Cyr1c]

J'ai programmé avec Vb, VB.NET et C#

Je préfère le C#, principalement pour la lisibilité du code, ce dernier est en effet moins verbeux que VB.NET et plus "clair" à la lecture.
C# a également quelques *petits* avantages : documentation générée, quelques automations avec VS.NET (les /// ). Il est également insensible à la casse ... ce qui quelque part oblige à faire attention aux noms de variables, et c'est pas plus mal !

Seulement, alors que Vb est très immonde, VB.NET n'est juste qu'une traduction litterale du C# ... il y a quelques différences, mais globalement les deux langages sont aussi puissants, ils reposent sur les memes concepts et les memes librairies... Il n'y a donc pour moi aucune différence technique ... le choix ne peut finalement se porter que sur les préférences du\des programmeurs. (venant de java, on penchera surement vers C# alors que les ex-VB viendront plus facilement vers VB.NET ... finalement, ce n'est surement qu'une technique marketing pour attirer le plus de monde à utiliser la technologie .NET !)

[Maniak]

La seule différence est que VB tolère plus facilement le mauvais codage avec une profusion de possibilités un peu limites, faut bien le dire, mais qui oblige à les utiliser? Personne.

Juste la fainéantise de certains. Mais ils sont nombreux, et sont dans les plus rapides à sortir une panoplie d'arguments bidons pour défendre leur choix :)

On peut très bien faire une architecture de classes (avec VB.NET) tout à fait digne d'un javaman, seulement il faut se faire violence car VB.NET ne l'impose pas

Yup. C'est juste dommage de devoir "se faire violence". C'est tellement plus reposant d'être rappelé à l'ordre automatiquement pour la plupart des choses :)

Sur C sharp, malgré tout le tapage fait par microsoft (mm dans le bouquin de Visual c++ lol) en faveur de leur bb, je suis assez suspicieux sur l'avenir de ce langage. La sauce ne prend pas facilement et hormis quelques projets, j'avoue que je ne vois pas grand chose en C# actuellement.

On n'a pas vu les mêmes choses alors. Parce que dans ce que j'ai vu jusque-là, c'est essentiellement du C#, avec VB.NET utilisé essentiellement par ceux qui viennent de VB6 et qui préfèrent jouer la sécurité en restant dans une syntaxe familière. Ainsi que les quelques rares âmes égarées qui connaissent aussi bien la syntaxe VB et la syntaxe C, et qui préfèrent la première :)

Sans compter tous les branleurs en puissance qui préfèrent VB.NET parce que ça leur permet de ne pas se compliquer la vie avec des choses aussi inutiles que le typage et la déclaration des variables :)

[Yorglaa]

...Sans compter tous les branleurs en puissance qui préfèrent VB.NET parce que ça leur permet de ne pas se compliquer la vie avec des choses aussi inutiles que le typage et la déclaration des variables

Ho !!! ça va oui !?
il y a aussi des gens qui codent en VB.NET de manière très propre et professionnelle !

[Maniak]

...Sans compter tous les branleurs en puissance qui préfèrent VB.NET parce que ça leur permet de ne pas se compliquer la vie avec des choses aussi inutiles que le typage et la déclaration des variables :)

Ho !!! ça va oui !?
il y a aussi des gens qui codent en VB.NET de manière très propre et professionnelle !

Lis mieux avant de t'emballer :)
Où tu vois que j'ai dit que tous les devs VB sont des branleurs en puissance ?

Maintenant, si tu veux dire qu'on peut faire du VB.NET de manière très propre et professionnelle en s'affranchissant du typage et de la déclaration des variables, là on ne va pas être d'accord.

Il y a des langages non-typés avec qui ça marche très bien (du moins le non-typage. la non-déclaration des variables c'est autre chose). VB.NET n'est pas un langage non-typé. C'est un langage typé qui a une option pour *masquer* les types et faire des conversions dans tous les sens selon ce que le compilo/runtime juge nécessaire. Rien à voir. Et je vois mal comment on peut faire quelque chose très propre et professionnel de cette façon.

On ne va même pas parler de la non-déclaration de variables, qui est particulièrement crade à la base. Donc pour en faire quelque chose de propre, c'est pas gagné.

Enfin... pour une appli de 10 lignes je suppose que c'est jouable :)


PS: au passage, si le C# avait des équivalents à Option Explicit/Strict, j'aurais tout autant de critiques à son encontre. Et encore plus à l'encontre de ceux qui utilisent ces "possibilités". C'est loin d'être une croisade contre le VB :)

[Yorglaa]

Ok, ok je me suis emballé... désolé !

Mais étant personnellement DBA Oracle avant d'être développeur en VB.NET, j'ai l'habitude du PL/SQL...
Or avec cette habitude, il est (pour moi) EXCLU de ne pas déclarer mes variables, de ne pas typer correctement ou de laisser le système faire du trans-typage... ne serait-ce que pour des questions de performances (le trans-typage TUE les perfs en bases de données)...

D'où ma réaction un peu épidermique...
Une fois encore, excuse-moi de cette envolée bien rapide et au combien maladroite !

[Maniak]

Pas de problème, ça arrive :)
Pi au final on est d'accord, c'est encore mieux :)

Cela dit, SmallTalk, Python et Ruby sont très 'libres' au niveau des types de variables, et ils se portent très bien comme ça. Comme quoi un langage prévu pour fonctionner de cette façon peut être très bien.

Le problème de VB.NET n'est pas tellement qu'on peut faire du code sans typage. C'est que l'absence de typage n'est pas un des fondements du langage. C'est juste une facilité pour programmeurs débutants ou fainéants. Il y a toujours du typage derrière, c'est juste une couche de bidouillage par dessus. Et c'est un peu pour ça que ça pose des problèmes.

Moralité : pour ceux qui n'aiment pas devoir tout typer, utilisez les langages appropriés à ce genre d'utilisation. VB.NET en a peut-être l'apparence, mais il n'en fait pas partie.

Ensuite, à partir du moment où *toute* appli VB.NET est en Option Explicit et Option Strict activés, la différence avec C# est essentiellement syntaxique, donc globalement mineure.

[Yorglaa]

ok pour l'option Explicit je vois bien.
Mais l'option Strict quel est son avantage ?

par exemple, dans une propriété de composant, devoir affecter "boolean.TrueString" au lieu de "True" n'ajoute rien (à mon sens) à la lisibilité pour quelqu'un qui devrait reprendre mon code...

autant j'aime les règles qui "obligent" à respecter une certaine propreté, autant pousser le bouchon trop loin n'est plus très utile (toujours à mon sens)...

mais j'ai peut-être mal capté l'utilité du paramètre Strict...

[Maniak]

ok pour l'option Explicit je vois bien.
Mais l'option Strict quel est son avantage ?

Ben le typage :)

par exemple, dans une propriété de composant, devoir affecter "boolean.TrueString" au lieu de "True" n'ajoute rien (à mon sens) à la lisibilité pour quelqu'un qui devrait reprendre mon code...

C'est quoi TrueString ? :)

Strict On sert surtout à éviter de faire des toto = 0 quand toto est booléen, ou à récupérer une chaîne et s'en servir pour faire des additions avec des entiers (ou pire, des flottants), sans aucun contrôle de validité.

Avec Strict Off, pas besoin d'indiquer les types de variables, pas besoin de caster, toutes les conversions se font automatiquement.

Et VB.NET, comme dit plus haut, n'est pas un language conçu autour du non-typage. C'est juste un déguisement. Et les effets secondaires ont une fâcheuse tendance à causer des bugs très lourds à trouver. Et à rendre le code tout sauf clair.

Dans le cadre d'une librairie, on n'en parle même pas.
Exemple bidon : tu fais un projet en C# qui tape dans une librairie VB.NET. Dans le projet VB, tu veux utiliser une méthode censée renvoyer un entier. Manque de bol, en fait elle renvoit un Object parce que le type de retour n'a pas été indiqué, merci Option Strict On. C'est vrai après tout, pourquoi est-ce que le dév de la librairie se serait fatigué à mettre des types et à valider ses données si tout peut se faire automatiquement ?
Sauf que du coup, c'est toi qui doit recevoir un Object, le valider, le convertir en Int32 si ça marche, gérer les erreurs si ça ne colle pas, et *ensuite* faire ce que tu voulais faire avec au départ.

C'est valable pour les librairies, mais ça l'est aussi pour un seul projet, fait par un autre dév et que tu dois reprendre. Réutiliser des méthodes dont tu n'est pas bien sûr des types de données renvoyés, qui peuvent gérer ou non la validation des paramètres non-typés, ... c'est pas la joie.

Oh et il ne faut pas oublier de mentionner les variables déclarées sans type, avec un traitement 3 pages plus loin qui se base sur leur valeur par défaut. Quelle valeur par défaut ? Ben ça dépend de l'instruction dans laquelle la variable est utilisée en premier. Et c'est pas forcément la même selon l'endroit dans le traitement.

Bien sûr, les conversions automatiques sont censées masquer tout ça et empêcher qu'il y ait le moindre problème. Sauf que non.

Moralité : Option Strict On -> à rendre obligatoire. C'est un peu plus fatiguant pour le dév initial (qui doit faire attention à ce qu'il fait et passer des paramètres valides, mince alors), mais ça évite de gêner le reste du monde ensuite et ça évite aussi pas mal de bugs bien vicieux.

Je trouve très con que VS.NET n'active pas cette option par défaut quand on crée un nouveau projet. Au moins ça active Option Explicit, c'est déjà ça. Mais les deux ont besoin d'être activées pour faire disparaitre les principaux arguments contre VB. Ensuite on peut le comparer aux autres langages "à armes égales".

[Dnx]

bon bon, j'ai mal aux yeux en lisant ce débat... 18 pages que je viens de bouffer, c'est pas rien

Quand j'étais encore aux études supérieures, on nous a appris le C, pascal, C++ et Java et VB6

durant mon stage, la cellule informatique ou je travaillais, programmais encore en VB6 et je vous assure que ce sont des pros VB6 et ce qu'ils ont fait étaient magnifiques!!! jamais je n'aurai imaginé qu'avec ce "vieux" langage, on pouvait faire de telles choses.
pour vous situer, il s'agit d'applications pour l'informatique de diffusion, donc qui font du monitoring pour la diffusion d'un journal télévisé, application de recherches d'archives sur 21 années, application de numérisation, etc... j'en passe et des meilleurs.

alors quand je suis arrivé, ils m'ont proposé de faire du .NET
bon... .NET... C# ou VB.NET (sachant les langages appris à l'école, je m'étais plus penché vers le C#) mais finalement vu que mes maîtres de stages étaient des pros en VB6, je me suis dit qu'ils pourraient m'aider en VB.NET vu que c'est très proche.

c'est alors que pendant 4 mois je n'ai fais que du VB.NET et j'adore ce langage! très facile à apprendre, à manier, lisible, etc...

depuis la fin du stage, j'ai été engagé dans leur cellule et j'ai du me refamiliariser avec le VB6 et je vous assure que quand on repasse du VB.NET au VB.6... C'est pas amusant... c'est comme ci on passait d'une BMW à une renault 5...

bref aujourd'hui je me pose encore la question!
C# ou VB.NET car après les 18 pages du débat, je ne me suis toujours pas décidé!

le C# pour se familiariser, c'est pas dur, vu que j'ai déjà appris le Java, C/C++

mais pour l'instant j'ai envie de migrer vers le C#, pourquoi?

- tout simplement comme l'a mentionné un membre, pour des raisons commerciales. ca fait un "chouïa" plus sérieux dans un CV. MEME si je suis d'accord, cela ne change absolument rien, pour les performances, je m'en fou pas mal, vu que les 2 langages présentent des avantages/inconvénients.

- Beaucoup plus de sources et d'aides dans ce langage C#

- Sécurité pour l'avenir, je m'explique :

mon point de vue est de dire, pour me mettre à l'abri d'un C4 (très optimiste hein!), je préfère migrer vers le C# car tout simplement il est la quasi-copie du JAVA et ressemble très fort au C++
ce qui me permettra de trouver du boulot plus vite en JAVA/C++/C# tandis que le VB.NET... Quel langage mettre dans le CV a part VB6?

et j'ai entendu dire que l'avenir du VB.NET n'est pas très riche car microsoft aurait des tendances à faire du C# LE langage du .NET???


voila j'aimerais connaitre vos avis sur manière de penser.