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

Salut,

Pour ma part, je programme en VB.NET car je viens du VB6 donc...

Bien que VB.NET soit très différent de VB6 je le trouve beaucoup plus clair et simple que le C++, Java ou C# où il y a trop de syntaxe lourdingue comme == {} ou autre délimiteurs dans ce genre.

C'est déjà pas simple de comprendre les mécanismes implémenter dans .NET alors pourquoi s'emcombrer d'une syntaxe lourde..

C'est mon avis mais je pense qu'il faut développer avec un langage avec lequel on est à l'aise.

Et la politique d'une plate forme multi langages me plaît bien.

Voilà

[fusionné à ce thread avec les deux réponses suivantes par abelman]

Oh pourquoi ça ??Peut-être parce que le vb6, et même vb.net est beaucoup moins stricte.. Alors forcément on aime bien, on peut oublier certain truc sans qu'il n'y ai de problèmes.. Langage très laxiste on dira (je sais pas si c'est un terme qu'on peut employer dans ce contexte mais enfin :P)..
C'est sur que ça parait lourd au départ la syntax c# qui est commune à énormément de langages du reste (c, c++, java, php pour ne citer qu'eux..) mais quand on y est habitué je peux te dire qu'on n'a vraiment plus envie de revenir au vb.net, enfin je parle ne mon nom :P

La syntaxe est lourde mais c'est pour votre bien :twisted: :twisted:

Bon, je vais tout de même donner mon avis, mais ça serait bien qu'on évite de partir en Troll

Tout d'abord, il est vrai que la synthase du VB est très légère comparée à d'autres langages, il est vrai que c'est plus souple à programmer

Il est vrai que C# est plus lourd au niveau sythaxique.

Ensuite lecture du code, qu'est-ce qui est le plus lourd ?

Code:

---

If Then Else End if

---

ou

Code:

---

if { } else { }

---

??

ensuite, il existe des fois où une assignation fait office de test (pour certaines boucles de type while par exemple) comment transcrire ceci en VB ?

Il y a un problème : en C# facile : == : comparaison d'égalité, = : assignation... mais en VB ????

On peut trouver également beacoup d'autres exemples qui vont dans les deux sens !!

Chacun choisi le langage qui lui convient le mieux !
(Langages dispo en .NET : C#, J#, C++.Net et VB.Net; on peut pas dire qu'on manque de choix !!!!)
De plus, le .NET permet de Développer une appli dans plusieurs langages sans qu'il y ait de problème quels qu'il soient !
Cette plateforme présente donc des avantages indéniables, ensuite, il y a également des inconvénients, comme pour tout !!!

[....][édité par abelman]

Swoög...

Ben disons que quand tu as:

If {} Else {}

ça va mais quand ça deviens

If {{{{}}}} Else {{{{}}}}

C'est tout de suite moins sympa !!

avec en plus des retour à la ligne au milieu.

et en VB.NET y a pas besoin de recourir à = !!!

Il y a dans tout les objets une méthode Equals().

Donc beaucoup plus simple car

If a = b Then

deviens alors

If a.Equals(b) Then

Mais bon.

dotnet74 avant de t'avancer sur des terrains glissants, renseigne toi bien.
equals n'est en rien reservé au seul VB.NET

C'est une méthode de la classe Object du Framework .NET. Elle est donc disponible pour tous les langages .NET y compris C#

et puis je ne comprend pas ceci If {{{{}}}} Else {{{{}}}}.
ce n'est pas une expression C# valide.
Exprime toi mieux.

Je n'ai pas dit que c'était réservé au VB.NET :)

et les {{{}}} font références à des bouts de codes que j'ai rencontrés

et dans lesquels la lectures devient aussi fastidieuse ( voir plus ) que des
End If

Voilà

1) ceux qui disent que la syntaxe du VB est légère et celle du C lourde, faudra m'expliquer ce que veulent dire les mots 'léger' et 'lourd' dans vos dictionnaires hein :)

2) imbriquer 50 blocs (ce qui finit donc par arriver à des {{{{{{{{ comme indiqué) n'est pas plus limité au C que .Equals est limité à VB.NET. Quelqu'un qui code comme un pied en C le fera aussi en VB. Et le laxisme de VB est bien plus apte à former de mauvais développeurs. Genre ceux qui disent que le typage ne sert à rien, au hasard.

Mais quitte à rester dans des comparaisons à deux balles sans intérêt, une petite question bête et sans intérêt :
Entre {{{{{{{{ }}}}}}}} et If Then If Then If Then If Then If Then If Then If Then If Then End If End If End If End If End If End If End If End If, c'est quoi le plus lourd ? :)

Citation:

---

Envoyé par DotNET74

Donc beaucoup plus simple car

If a = b Then

deviens alors

If a.Equals(b) Then

---

rassurer moi a

Code:

---

a == b

---

et

Code:

---

a.equals(b)

---

ca n'a pas le même sens !! 8O
y'en a un qui compare l'adresse mémoire d'objet (==), l'aute qui compare les attributs de l'objet (equals)

Citation:

---

Envoyé par j0hnmerrick

rassurer moi a

Code:

---

a == b

---

et

Code:

---

a.equals(b)

---

ca n'a pas le même sens !! 8O
y'en a un qui compare l'adresse mémoire d'objet (==), l'aute qui compare les attributs de l'objet (equals)

---

C'est exactement la même chose, à moins que les objets en question soient mal faits.

L'opérateur == est censé comparer le premier objet à null, puis passe la main à la méthode Equals, et l'opérateur != renvoit l'inverse de ==.

Ces 3 méthodes sont censées être implémentées en groupe. Si tu en redéfinis une, tu redéfinis les deux autres.

Citation:

---

Envoyé par Maniak

Citation:

---

Envoyé par j0hnmerrick

rassurer moi a

Code:

---

a == b

---

et

Code:

---

a.equals(b)

---

ca n'a pas le même sens !! 8O
y'en a un qui compare l'adresse mémoire d'objet (==), l'aute qui compare les attributs de l'objet (equals)

---

C'est exactement la même chose, à moins que les objets en question soient mal faits.

L'opérateur == est censé comparer le premier objet à null, puis passe la main à la méthode Equals, et l'opérateur != renvoit l'inverse de ==.

Ces 3 méthodes sont censées être implémentées en groupe. Si tu en redéfinis une, tu redéfinis les deux autres.

---

ah ouaie c'est vrai en plus :roll: c'es pas comme en java du coup....
comment fait on du coup pour comparer si 2 objects identiques (cad s'ils ont la même adresse mémoire ?)

Code:

---

Object.ReferenceEquals(obj1, obj2)

---

Le titre du forum est Que choisir ? C# , VB.NET, C++, Delphi ? pourquoi ?. Or pratiquement aucun mot sur la version 8 de Delphi. Qu'est-ce à dire ?

1) que les développeurs C# et VB.NET se sont simplement appropriés le forum (dans des discutions un peu stériles il faut bien le reconnaître) ?
2) que Delphi 8 est tellement mauvais pour .net qu'il ne vaut même pas la peine d'en parler ?
3) autre ?

JJ

1) il y a eu tres peu de questions sur le forum, mais bon a mon avis il n'y a pas de problemes si les delphistes se mettent a poster :)

les discution pour comparer vb.net / c# / delphi et autres seront de toute facon steriles. Leur differences au niveau de la programmation pro de tous les jours sont negligeables. Le debat ne sera de toute facon qu'une querelle de clocher.

2) heu je sais pas, je connais pas delphi, je sais c'est pas bien :(

3) Hum.... que peu de developpeurs delphi se sont mis a .net ? :P

pour preuve de ma bonne foi je vais meme faire un post pour delphi.net tiens

Personellement, j'ai choisi VB.NET tout simplement parce que je connais Visual Basic depuis la version 1.0, mais je ne dénigre absolument pas C# (encore faurdrait-il le connaitre pour être objectif).

Tous deux me semblent très bien !

En plus de tous les avantages/incovénients qu'on pourrait lui trouvé, je prefere le C# pour des raisons "marketing".
En effet, même si VB(.NET) est le bébé de Microsoft, le C# est la nouvelle direction que Microsoft aimerais "imposer"... (passer d'un "vieux" jouet pour un nouveau a toujours l'air plus cool :wink: )

Du coup, la plus part des tutoriaux/exemples/libraries sont d'abord réalisé en C# (avant d'être éventuellement porté au VB.NET).

moi je suis pour VB.net mais pour moi C# est aussi bien
je trouve juste le code plus clair sous vb.net
mais il est vrai que C# reste super puisant mais faut faire attention a bien expliquer sont code et etre tres attentif

plus clair ? le VB ?

Pourtant le code n'est pas vraiment délimité en blocs, je vois pas comment on peut un code contenant que des mots peut-être plus lisible qu'un code avec des accollades !

:wink:

Salut!

Je compte me former en DoNet simplement pour progresser en développement... Je connais pour l'instant PHP, SQL, HTML, CSS, Javascript et Delphi (version 6)... Peu importe la synthaxe du language, je pense m'adapter assez facilement.
J'aimerai bien savoir dans quels outils de développement (si possible gratuits) dois-je m'orienter selon vous? Sachant que c'est surtout pour élargir mes connaissances, développer quelques projets utiles, pouvoir participer au forum DoNet et éventuellement ajouter ces expériences sur mon CV...

Pour le moment, j'ai téléchargé SharpDevelop et le FrameWork 1.0... :koi:

Merci infiniment pour vos conseils!
Très cordialement, sub0

Salut,

Vu que c'est que pour de la formation, tu pourrais presque attaquer directement sur le framewok 2.0 (béta)
http://www.developpez.net/forums/viewtopic.php?t=217167

Sinon en IDE gratuit t'as C#builder édition personnelle aussi :)

Je pense qu'une maitrise d'un IDE borland ou microsoft sera un plus sur un CV, et vu que tu ne comptes pas faire de projets "commerciaux"...

Merci neo.51! :ccool:

J'ai trouvé grâce à ton lien, quelques articles très intérressants! Je crois que pour compléter et valoriser mon CV (étant un autodidacte sans diplômes en programmation informatique), je dois apprendre à développer en C... Probablement parce-que c'est un language très répandu et très utilisé par les sociétés de développements informatiques, et parce ce language m'est inconnu et que cela m'intérresse beaucoups du coups! Je suppose que C#builder correspond à cet objectif, non? Qu'en pensez-vous?

Mon projet (à moyen / long terme) est de devenir développeur indépendant, de créer ma société... Je suis actuellement en train de suivre un stage ANPE pour évaluer mes compétences et la faisabilité de mon projet... Je pense aussi, par la suite, suivre des stages en développement si nécessaire. Reste à choisir le language et l'environnement le plus approprié au marché actuel et futur...

Merci beaucoups pour tous vos conseils!

Très cordialement, sub0