Que choisir ? C# , VB.NET, C++, Delphi ? pourquoi ?

Citation:

---

Envoyé par Keihilin

Plutôt moins que plus.

---

Perso j'utilise VBCommenter et je trouve que le seul truc qui lui manque c'est la prise en compte de l'intellisense sur les solutions à multiple projets.
Je m'explique : J'ai une Librairy de composant en VB.NET, un projet Winform qui utilise cette library. J'utilise VBCommenter pour generer les commentaires dans un fichier XML. Si dans ma solution je mets les deux projets et que j'ajoute la librairy comme référence "projet" à mon projet Winform, alors là je ne vois pas les commentaires des focntions dans l'intellisense. Mais si j'ajoute la librairy comme reference fichier (j'ai donc un seul projet dans ma solution) là j'ai bien les commentaires dans l'intellisense

Citation:

---

Envoyé par abelman

Si tu prends la classe SqlConnection par exemple, faire un using sur une instance de cette classe veut dire que tu n'appelles pas explicitement le Close dessus une fois que tu a finis de l'utiliser.
Je préfère vérifier la symétrie des appels Open /Close que de me dire que le "using sous entend que le Close sera appellé automatiquement".

---

Bip bip biiiiiip. using appelle Dispose. Close est appelé automatiquement dans le cas de SqlConnection, et encore rien ne l'oblige. Techniquement c'est un peu logique, mais dans tous les cas, using == Dispose. Point barre.

Quand je fais un Open, je tiens aussi à avoir le Close dans le code. Dispose c'est un peu différent. Avec using, on retrouve le principe des variables qui sont directement détruites quand on sort du bloc dans lequel elles sont déclarées. Et c'est un principe avec lequel je suis très à l'aise :)

Citation:

---

Envoyé par abelman

De plus l'utilisation du Using n'entraine t elle pas une identation en plus ?

---

Yup. Et si tu as une fonction avec tellement de niveaux d'indentation qu'elle en devient incompréhensible, c'est un des symptômes qui indique le besoin de l'éclater en plusieurs :)

Citation:

---

Envoyé par abelman

qu'en est il si tu dois utiliser plusieurs using sur des dans la même fonction ? tu identes à chaque fois ?

---

Si ça se fait au même moment, tu peux déclarer plusieurs variables dans un seul using (virgule-powered). Si c'est en cours de route parce qu'une variable ne sert que pendant une petite partie d'un using 'parent', ça fait un nouveau niveau d'indentation oui. Et on retombe sur ce que je dis plus haut : trop d'indentations indique qu'il faut faire plusieurs fonctions. using peut notamment permettre de clairement voir les blocs qui peuvent être extraits d'une fonction pour en faire une autre. Que du bonheur :)

Citation:

---

Envoyé par Maniak

Donc bon. Là on en est à VS.NET 2003, avec du 2002 qui traine encore un peu, autant s'en tenir à ça pour les discussions. Whidbey sera peut-être tout beau tout neuf avec plein de trucs en plus qui changeront la donne, mais il est encore loin, donc en gros : on s'en tape. Les décisions à prendre pour les projets de là, maintenant, sont à prendre par rapport à la situation là, maintenant.

---

Grosse nuance, tu t'en tapes. :)

Ensuite, même si using n'est pas présent dans VB.NET tu peux très bien travailler sans. Pour moi, il n'y a rien d'éliminatoire à utiliser VB.NET.

Donc tu peux faire un projet VB.NET 2003 parfaitement viable.

Citation:

---

Envoyé par bidou

Grosse nuance, tu t'en tapes. :)

---

Je m'y intéresse pour avoir une idée de ce qui va arriver, mais pour les projets actuels, oui, je m'en tape complètement :)
En quoi est-ce que les futures nouveautés de Whidbey sont pertinentes pour les projets actuels ? :)

Citation:

---

Envoyé par bidou

Ensuite, même si using n'est pas présent dans VB.NET tu peux très bien travailler sans. Pour moi, il n'y a rien d'éliminatoire à utiliser VB.NET.

Donc tu peux faire un projet VB.NET 2003 parfaitement viable.

---

Ça j'ai jamais dit le contraire :) Tu noteras que je n'ai quasiment rien dit contre VB.NET jusque-là :)

Je trouve using plus propre, ça délimite mieux les blocs de code (-> refactoring & co) et ça simplifie le code tout en soulageant le développeur de toutes les questions de libérations de ressources (du moment qu'il est rigoureux, qu'il implémente bien IDisposable sur tous les objets ayant des membres implémentant eux aussi cette interface et qu'il utilise aussi using pour tous les objets implémentant IDisposable au sein d'une même méthode).

Perso, je trouve que c'est une des instructions les plus utiles de .NET. Et son arrivée dans VB.NET est une très bonne nouvelle. Il ne restera plus qu'à ce que les développeurs VB.NET changent à nouveau leurs habitudes pour l'utiliser, quand Whidbey sera sorti et que les entreprises se seront mises à jour :)

Citation:

---

Envoyé par Maniak

Je m'y intéresse pour avoir une idée de ce qui va arriver, mais pour les projets actuels, oui, je m'en tape complètement :)
En quoi est-ce que les futures nouveautés de Whidbey sont pertinentes pour les projets actuels ? :)

---

En rien. Mais pour ma part, et je suis loin d'être une exception, mon travail en DotNet est plus de l'auto formation que de la véritable production. Car à l'heure actuelle, mes projets sont encore du code natif.

Or celui qui se pose la question que choisir entre VB.NET et C# n'est pas encore au point pour la production, ou alors il y a un os dans le potage

Citation:

---

Envoyé par bidou

Or celui qui se pose la question que choisir entre VB.NET et C# n'est pas encore au point pour la production, ou alors il y a un os dans le potage

---

Pour la prod non, pour le début du développement, les premiers prototypes, tout ça, c'est autre chose :)
Et dans tous les cas, celui qui se pose la question VB.NET vs C# n'est peut-être pas en train de bosser sur un projet en ce moment-même, mais il a des chances de le faire avant l'arrivée de Whidbey dans son enterprise :)

Donc autant qu'il évite de trop se baser sur ce qui ne sera pas présent quand il devra mettre la main à la pâte. Pour l'auto-formation et se préparer à la suite, ça ok, faut juste pas tout mélanger. Et surtout ne pas utiliser des évolutions futures et encore lointaines comme poids dans la balance VB.NET vs C# de maintenant.

La réponse à l'objet de ce débat, donnée par un membre de l'équipe de développement de C# :

Citation:

---

Envoyé par Jon Skeet

The choice between C# and VB.NET is largely one of subjective preference. Some people like C#'s terse syntax, others like VB.NET's natural language, case-insensitive approach. Both have access to the same framework libraries. Both will perform largely equivalently (with a few small differences which are unlikely to affect most people, assuming VB.NET is used with Option Strict on). Learning the .NET framework itself is a much bigger issue than learning either of the languages, and it's perfectly possible to become fluent in both - so don't worry too much about which to plump for. There are, however, a few actual differences which may affect your decision:

VB.NET Advantages :

- Support for optional parameters - very handy for some COM interoperability

- Support for late binding with Option Strict off - type safety at compile time goes out of the window, but legacy libraries which don't have strongly typed interfaces become easier to use.

- Support for named indexers (aka properties with parameters).
Various legacy VB functions (provided in the Microsoft.VisualBasic namespace, and can be used by other languages with a reference to the Microsoft.VisualBasic.dll). Many of these can be harmful to performance if used unwisely, however, and many people believe they should be avoided for the most part.

- The with construct: it's a matter of debate as to whether this is an advantage or not, but it's certainly a difference.
Simpler (in expression - perhaps more complicated in understanding) event handling, where a method can declare that it handles an event, rather than the handler having to be set up in code.

- The ability to implement interfaces with methods of different names. (Arguably this makes it harder to find the implementation of an interface, however.)

- Catch ... When ... clauses, which allow exceptions to be filtered based on runtime expressions rather than just by type.

- The VB.NET part of Visual Studio .NET compiles your code in the background. While this is considered an advantage for small projects, people creating very large projects have found that the IDE slows down considerably as the project gets larger.


C# Advantages :

- XML documentation generated from source code comments. (This is coming in VB.NET with Whidbey (the code name for the next version of Visual Studio and .NET), and there are tools which will do it with existing VB.NET code already.)

- Operator overloading - again, coming to VB.NET in Whidbey.

- Language support for unsigned types (you can use them from VB.NET, but they aren't in the language itself). Again, support for these is coming to VB.NET in Whidbey.

- The using statement, which makes unmanaged resource disposal simple.

- Explicit interface implementation, where an interface which is already implemented in a base class can be reimplemented separately in a derived class. Arguably this makes the class harder to understand, in the same way that member hiding normally does.

- Unsafe code. This allows pointer arithmetic etc, and can improve performance in some situations. However, it is not to be used lightly, as a lot of the normal safety of C# is lost (as the name implies). Note that unsafe code is still managed code, i.e. it is compiled to IL, JITted, and run within the CLR.

Despite the fact that the above list appears to favour VB.NET (if you don't mind waiting for Whidbey), many people prefer C#'s terse syntax enough to make them use C# instead.

---

Comme quoi, on a bien fait le tour des arguments...


La page d'origine :

http://msdn.microsoft.com/vcsharp/team/faq/vb/

Citation:

---

Envoyé par Keihilin

La réponse à l'objet de ce débat, donnée par un membre de l'équipe de développement de C# :

---

Ce que j'aime bien, c'est que dans les 7 'avantages' donnés pour VB.NET, 3 posent des problèmes et 2 peuvent compliquer la compréhension du code selon les gens :)

Par contre ils ne parlent pas de using pour VB.NET dans Whidbey. Oubli ?

Citation:

---

Envoyé par Maniak

Par contre ils ne parlent pas de using pour VB.NET dans Whidbey. Oubli ?

---

Ben je sais pas...Je ne lis pas régulièrement le Blog dont est issue cette page...Mais à mon avis, il y a de fortes chances pour que using soit disponible dans VB avec Whidbey.

Il semblerait qu'on aille dans la direction d'une convergence de langages, ce qui devrait rassurer ceux qui s'inquiètent de l'avenir de VB, et rendre le choix entre C# et VB encore plus subjectif.

Je me demande d'ailleurs ce que je vais bien pouvoir choisir lorsque j'attaquerai mes premiers développement avec Whidbey...
Je suis aussi à l'aise avec les deux langages, et c'est les commentaires XML qui me font pencher vers C# la plupart du temps... :wink:

Oubli
http://download.microsoft.com/download/1/1/B/11B54B37-7B64-4F06-AD6A-D7BA081BF1D0/TLS300.ppt

Diapo 24 "Using statement"

Je vous conseille d'utiliser Delphi, tout simplement...
Syntaxe agréable, compatibilité ascendante, portage d'anciens composants assez facile, etc.
Programmation en mode VCL.NET bien plus agréable que les WIndows Forms, mais aussi possibilité d'utiliser les Windows Forms tout aussi nativement.
Mise à disposition du BDP qui simplifie énormément l'utilisation de ADO.NET en permettant notamment de changer de base de données sans tout réécrire (sous ADO.NET, passer de SQL Server à Oracle par exemple impose de modifier toutes les classes utilisées...).
Etc.

Il n'y a donc pas que le langage qui compte mais tout ce qui va autour. Avec Delphi on dispose de beaucoup de choses.
Sinon, côté langage stricto sensu, C# est très agréable et malgré ce qu'on lit ici ou là, C# est bien plus proche de Delphi que de C++.
Rappelons que c'est le père de Delphi qui a écrit C#, quelqu'un qui n'a donc jamais vraiment aimé C++.
De fait on ne retrouve dans C# aucun des bricolage typique de C++, les propriétés des objets sont traitées comme dans Delphi, etc.

Enfin, sous .NET tous les langages sont compilés en MSIL et ils sont donc tous égaux.
Autant sous Win32 utiliser Delphi c'est faire de la résistance (il faut le vouloir.. traduire les hearders C etc) autant sous .NET qui justement intègre la pluralité de langage dans ces principes fondateurs, Delphi est un excellent choix.
D'ailleurs Delphi est bien mieux intégré à la plate-forme .NET qu'il ne l'est à Win32...

Autant de raison de préférer Delphi et son environnement donc.

Je suis vraiment malheureux de lire un tel façon d'aborder la programmation quel quel soit...

L'important, c'est d'arrêter de penser que l'on est seul a programmer, c'est bien beau de programmer n'importe comment mais j'ai déjà lu "Qu'un programme qui fonctionne n'est pas nécessairement un bon programme"

Alors pour ceux qui désire devenir de vrai programmeur, suivez ce conseil, faites en sorte de choisir un language qui vous plait, un language en demande et surtout une fois que vous l'aurez choisi, programmez de facon intelligente, vous n'êtes pas seul a travailler dans le monde de la programmation, lorsque vous lisez un programme conçu par une autre personne, vous allez apprécier de savoir si la variable est un caractère ou un nombre entier ou une valeure avec point décimal, sinon comment comprendre ce que le programmeur qui vous précédait voulais vraiment faire avec son code.

J'espère que ces quelques conseils feront en sorte de vous éviter de devenir des programmeurs négligeant et sans la moindre conscience est autre programmeurs qui vous entourent.

Jeff
Programmeur analyste
Tech-Control Inc.

Citation:

---

Envoyé par MonPierrot

pour ma part je recommande vivement vb à ceux qui ne sont pas des purs et durs du C++ et qui veulent GAGNER DU TEMPS

Ce qui suit va faire hausser des épaules les "gros bras du C++", mais j'insiste pour leur dire que je ne vois aucune "virilité" a s'emmerder avec un langage complexe (et source d'erreurs).

Et pour moi C# ne va pas assez loin, il veut trop ressembler a C++.
Il nous emmerde encore avec sa gestion des types, ses accolades, ses point virgule et j'en passe.
Je viens encore de passer 2 ans vec 1 projet ATL/com/C++...ahh les conversions (chaines...), unicode, et j'en passe...que de temps perdu.

L'interet d'un programme n'est pourtant pas du tout là !!

VB ne faisait pas sérieux quand il s'agissait de parler performance, pas fiabilité.
De plus il etait (trop) restrictif en termes de librairies natives et imposait un recours a des passerelles + ou - contaignantes vers les lib win32.
Enfin il etait trop limité ( pointeurs, heritage...) a force de faire simple.

Franchement, moi j'en ai rien a faire d'une gestion stricte des types, et ça fait des années que je m'emmerde avec ça !
Que de temps perdu avec les chaines de caracteres, les pb de conversion, l'Unicode, et j'en passe !

Alors C# pour quoi faire ?
On peut supposer justement que la gestion stricte des types optimise un peu les perfs...Il y a d'autre differences ( cf MSDN ).

Mais vive les langages "modernes" et à bas les contraintes !!

---

C# herite du monstre JAVA c le meilleur:
-syntaxe
-performances
-possibilté d'evolutivité
-apprentissage
-précision
:x

Bonjour,

Pour moi, Delphi s'impose de fait. Et j'avoue avoir été subjugué (au depart, derouté aussi) par la nouvelle interface de delphi 8. Mais on s'y fait.

Car même si je n'ai pas encore developpé de gros projet en .NET (nous developpons en mode Win32, et multiplateform via la librairie CLX, et infidélité à Delphi, les application WEB en JAVA qui pour nous aura tjs l'avantage par rapport à .NET pour les Appli intra/internet).

Et voila...

Cordialement

Citation:

---

Envoyé par ptitbob

et infidélité à Delphi, les application WEB en JAVA qui pour nous aura tjs l'avantage par rapport à .NET pour les Appli intra/internet).

---

pourquoi forcément java pour le Web ? qu'entends-tu par Java ? des applets ? tu as essayé ASP.NET ? Il se trouve que c'est justement pour le Web que les gains de .NET sont souvent les plus flagrants.

Bonjour,

Applet bien sur, mais aussi JSP et Servlet... Le tout pour tourner sur un serveur Tomcat intégré sur un serveur Apache en tant que module et tournant sur Linux...

Excuse moi, mais le couple Apache/Linux me convient bcp mieux au niveau fiabilité et securité que le couple IIS/Win2003 par exemple (ou IIS/Win2k ou autre serveur Win...)

Et ce n'est pas l'actualité des patch MS ainsi que les stat des serveur present sur la toille qui me donneront tort :wink: ....

Il est vrai que la presentation de LongHorn par Mr Dick Lantim m'a impressioné et que le dev rapide qu'il a fait sous D8 d'un site avec interaction avec une base a fait blemir certains de me collegue... Mais ton asp.net en remplaçant des applet, comment se comporte t'il sur un poste MacOS ou Linux ?... J'avoue ne pas avoir tout suivit là :roll:

Cordialement

Je viens de VB6, lorsque le Visual Studio Net est sorti j’ai pensé que le mieux pour moi serais bien sûre de m’orienter vers le VB Net, mais au début j’étais tellement désorientée parce que le VB Net a vraiment changé la façon de faire beaucoup de choses. Spécifiquement je parle de la programmation bases données. Donc attention aux ceux qui pensent que la transition de VB6 to VB Net sera automatique !

D’autre part, je dois avouer que maintenant que je fais mon début dans le Java je regrette de n’avoir pas choisi le C# sur le VB Net. Donc, mon avis serais de choisir le C# pour la similitude de syntaxe avec le Java.

Merci
Carmen

Venant de Delphi lorsque je suis passé à .NET je me suis mis tout naturellement à C# et cela dans la continuité de Delphi.
Je n'ai vu beaucoup de différence et pour cause le père de C# est celui de Delphi (débauché de Borland par Miscosoft).
Le "garbage collector" du C# est quand même très pratique et évite de nombreuses fuites mémoires!
Je ne sais pas si c'est Visual Studio qu ifait ça mais développez en C# sans formation fut une évidence (après avoir fait du Delphi), et comparé à VB .NET (pseudo POO) il n'y a pas photo!
@+

Citation:

---

Envoyé par sorcer1

..., et comparé à VB .NET (pseudo POO) il n'y a pas photo!
@+

---

ça ne veut strictement rien dire pseudo POO. En VB.NET tu as le choix de faire de la POO ou pas. A quelques très rares exceptions prêt (et encore qui ne touche pas à la POO) tu peux faire en VB.NET tout ce que tu peux faire en C#.
C# c'est très bien et POO, VB.NET est aussi POO

Je me suis peut être mal exprimé!
Mais comme VB a tellement tardé à devenir un langage POO que maintenant j'ai du mal à le considérer comme tel, pourtant aujourd'hui c'est effectivement le cas.
Désolé!