Que choisir ? C# , VB.NET, C++, Delphi ? pourquoi ? [Débat]

**Maniak** · 14/07/2005, 20h19

Envoyé par doccpu

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** · 10/08/2005, 16h18

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** · 11/08/2005, 09h59

Envoyé par verre d'eau

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** · 11/08/2005, 15h22

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** · 11/08/2005, 15h30

ouf !!
Me voici soulagée !

Merci

**Floyd** · 25/08/2005, 08h45

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


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



<Math:Graphe ... />

</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** · 01/09/2005, 14h14

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** · 05/09/2005, 15h05

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** · 05/09/2005, 16h39

Envoyé par Kaktus

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 :)

Envoyé par Kaktus

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 :)

Envoyé par Kaktus

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** · 05/09/2005, 16h47

Envoyé par 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 !

**Maniak** · 05/09/2005, 17h49

Envoyé par Yorglaa

Envoyé par 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** · 05/09/2005, 21h07

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** · 05/09/2005, 23h07

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** · 06/09/2005, 08h51

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** · 06/09/2005, 11h18

Envoyé par Yorglaa

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

Ben le typage :)

Envoyé par Yorglaa

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** · 13/09/2005, 10h38

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.

**Kikos31** · 13/09/2005, 12h30

Envoyé par Dnx

Quel langage mettre dans le CV a part VB6?

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

Salut,

D'un point de vue professionnel à mon avis vaut mieux connaitre les 2 (VB.NET et C#). Tu peux te spécialiser dans celui que tu préfère mais ca fait pas de mal de faire de temps en temps un petit projet dans l'autre.

De toute façon, pour un boulot, au bout d'1 ou 2 semaine de dev, si tu connais bien le FrameWork, les petites différences du nouveau langage seront vite acquise.

**neguib** · 13/09/2005, 13h13

Ben en regardant les votes, il ne faudrait pas trop oublier le troisième larron Delphi.Net

, je m'y suis mis depuis quelques temps et j'y prends goût
- propreté absolu
- simple de manipulation une fois pigé l'architecture
- l'encapsulement d'une grande partie de la framework par la VCL, augmentant pas mal les possibilités
- pas autant de soucis de migrations que le vb6
j'avoue que pour l'instant je n'ai pas prêté attention à des désavantages

**neo.51** · 13/09/2005, 15h00

Je pense qu'on recommencera le sondage avec l'arrivée de .NET 2.0 car certains argumentaires deviendront obsolètes

Concernant delphi .NET ce qui me chagrinne le plus c'est que delphi .NET aura toujours semble t'il une guerre de retard sur la dernière version du framework. Et quand on voit les énormes nouveautées de la V 2.0 : http://lgmorand.developpez.com/dotnet/framework2/ on peut pas conseiller à quelqu'un qui veut se mettre au developpement dotnet d'utiliser un langage qui utilise un framework "obsolète".

L'interet de delphi vient à mon avis de la compatibilitée avec les versions antérieures de delphi car borland à trés bien réussit la migration en douceur contrairement à microsoft...