Discussion :

[neguib]

Merci bien

Mais vos conseils perso concernant mes premières orientations à prendre et décisions....

- Delphi.NET ou C# ?
- Que faut t-il faire de mieux ou est conseillé pour débuter

merci encore

A première vue je te conseillerai C# puisque tu débutes, je m'explique
D'abord te familiariser avec la framework MS.Net (Delphi propose en plus la VCL.Net)
Comme tu t'inities apparemment à la POO, prevoit également d'apprendre à séparer dans ta conception la couche graphique, la couche métier et la couche des données. Donc je te suggères d'aborder en premier lieu la création de bibliothèque de Classes (Projets Win et Web et librairie de Contrôles pourront être abordés plus tard pour les aspects purement graphiques), pour tester tes classes tu peux créer un projet Console. Decouvre ainsi les espaces de noms tels que System.IO, System.Text, System.Collections ...

[NicolasG]

Alergie aux pointeurs: en object tout est pointeur...

Et en .NET, ils sont tous gérés via des références + GC peu importe le langage. C'est un argument pour .NET (ou Java d'ailleurs , mais pas pour VB.NET spécifiquement

C'est un argument pour les débutants, pas pour des vieux briscard comme nous 8) .
Plus sérieusement les pointeurs, y'en a qui s'en servent encore ! Je ne connais pas de meilleur moyen d'accéder à la mémoire. (Qui fait du traitement d'image sans pointeur ?)
Encore quelque années de travail et les compilateurs seront peut être suffisament puissants pour supprimer l'intéret du pointeur par rapport aux références.
[edit] je dois signaler que C# gère aussi les pointeurs dans certaines conditions (pinnig)

[spilliaert]

je débute dans ce domaine, mais d'apèrs ce que j'ai pu lire, c# est le language .net. De plus, comme je viens de java, je ne suis pas trop dépaysé

[pataphysicien]

Je vote pour c#.

Bien sur chaqu'un a ses affinitées avec chaqu'un des langages. Et certains on peut être été dégouté par les pointeurs en c et en c++. Alors pour eux le c# ca sonne mal . Alors que l'on a plus a s'en soucier en c#.

Je ne code pas en VB.net, mais VB a gardé la réputation d'être un langage moins rigoureux que le C. C'est donc 1 point pour C#, sous reserve que VB.net soit devenut plus rigoureux que ne l'était son prédécesseur.

Théoriquement tout les langages se valent sur la .net puisque lors de l'assemblage visual les convertit en CIL (Common Intermediate Langage). Et il ne devrait donc pas être plus ou moins rapide lors de l'execution. Cependant, c# reste (un peu plus) priviligié. C'est naturel car c'est le langage qu'utilise majoritairement microsoft pour ses projets, donc il évolue un peu plus vite que les autre langages de .net.

Alors, je vote c#.

[spiderdrick]

Oué, de toute façon .net est fait pour recevoir tous ces languages (et d'autres en plus....) donc c'est à nous pauvres développeurs de faire notre mix avec les spécificités de tous ces languages...

@++

[NicolasG]

C#... c'est le langage qu'utilise majoritairement microsoft pour ses projets...

Quelles sont tes sources ?

[ArHacKnIdE]

Salut,

Bien moi pour tout vous dire je commence complètement avec Visual Studio. J'ai choisis C# parce qu'il me semblait mieu, avec des syntaxes plus organnisées à mon goût, mais aussi parceque dans ma version de Visual Studio 2005 Express, bien avec le C# c'est beaucoup plus facile d'apprendre puisqu'il y a plus d'aide et surtout l'aide à la saisie avec le menu déroulant s'affichant automatiquement Le petit truc qui me plaît bien, c'est l'affichage en "Design", utile je trouve Voilà les raisons de mon penchant vers le C# !

[orelero]

Moi je viens du java, et je trouve c# trés séduisant de par les nombreux tutoriaux sur le net, et la facilité d'utiliser du code non managé. La syntaxe est pratiquement la meme qu'en java. Par contre dommage que le seul ide pour c# (csharpdevelop) soit si peu depourvu de doc, mais bon ça n'est qu'un cap à passer, aprés c'est plu un probleme .

[FremyCompany]

Pour moi ces 2 langagues sont similaires niveau performances, mais pas au niveau du temps de developpement.

Je viens du BASIC et j'ai appris VB .Net à une vitesse fulgurante.
Un jour j'ai découvert un livre .Net particulièrement intéressant codé en C#. Contrairement à mes attentes, je n'ai eu aucune difficulté avec C# et j'ai pu aisément tout transposer en VB .Net

Alors je me suis vaguement dit que ca ne valait pas la peine de tergiverser sur la question, c'est comme parler de mes pommes et celle de mon voisin, c'est les même :-)

Mais en réalité, il y a une différence majeure :
Développer en VB va beaucoup plus vite qu'en C#
Deplus, je propose au developpeur C# de regarder l'espace de nom Microsoft.VisualBasic. Il contient un nombre très impressionnant de fonctions qu'on ne trouve pas en C#
De même l'espace de nom My de VB .Net 2.0

Alors même si VB fait moins sérieux, est moins "commercial", il permet dans de nombreux cas d'éparger un temps précieux de codage inutile et ennuyeux. Le fait qu'i ne soit pas Case-Sensitive est aussi, il me semble un atout majeur.
Je crois que c'est à chacun de décider, mais franchement, moi je préfère VB.
Fremy

[Keihilin]

Mais en réalité, il y a une différence majeure :
Développer en VB va beaucoup plus vite qu'en C#

Pas d'accord ! L'intellisense compense un peu l'incroyable lourdeur de VB, mais ça ne rend pas le développement plus rapide qu'en C#.
Malgré ma nette préférence pour C#, je développe aussi en VB (quand j'y suis forcé), et je ne vois pas une différence majeure en terme de rapidité.

Deplus, je propose au developpeur C# de regarder l'espace de nom Microsoft.VisualBasic. Il contient un nombre très impressionnant de fonctions qu'on ne trouve pas en C#

Encore heureux qu'on ne les trouve pas en C# !!
Cet espace de nom contient tout ce qu'il faut pour persister dans les mauvaises habitudes que donne VB.
C'est juste un reliquat utilisé pour que les développeurs habitués aux versions précédentes de VB ne soient pas trop dépaysés.

Le fait qu'i ne soit pas Case-Sensitive est aussi, il me semble un atout majeur.

Un confort peut être, mais plus proche de l'inconvénient que de l'atout majeur...

[FremyCompany]

Peut-être que tu as raison, mais en tout cas pour un jeune développeur de 14 ans, ta réaction paraît pour le moins étrange...

J'ai moi même testé et je vais plus vite en VB .Net.
Cela s'explique peut-être par le fait que je suis plus dans mon élément.
Mais j'estime aussi que le code VB est plus lisible que le C# qui n'est au final qu'un enchevêtrement d'acolades, de paranthèses et de points-virgues inutiles (if, for, ...). Ses mots-clés sont aussi moins compréhensible. NotOverridable je comprends très vite, mais final, ca n'a pour moi aucun sens.
De même Const <--> final, Sub <--> void, ...

Alors peut-être en effet qu'un programmeur expérimenté n'y verra pas de problèmes, mais un débutant aura nettement plus facile avec VB qu'avec C#.
Fremy

PS : Je n'avais jamais fait de VB et j'utilise pourtant l'espace de nom VisualBasic qui contient des fonctions très intéressantes malgré tout ce qu'on peut en dire

[Maniak]

Peut-être que tu as raison, mais en tout cas pour un jeune développeur de 14 ans, ta réaction paraît pour le moins étrange...

C'est peut-être que les points de référence ne sont pas les mêmes :)

J'ai moi même testé et je vais plus vite en VB .Net.

Ce qui est normal quand on est habitué à VB au départ (ou Basic dans ton cas :). De la même façon, quelqu'un qui est habitué à la syntaxe C (probabilité légèrement plus grande vu la quantité de langages qui piochent dedans) aura tendance à aller plus vite en C# qu'en VB.NET.
Après c'est une question d'habitude et de pratique.

Aussi, si tu abuses de Microsoft.VisualBasic (autrement dit si tu t'en sers ne serait-ce qu'une fois), ça fait peut-être aller plus vite, mais ça fait aussi rester 10 ans en arrière, en plus de faire durer/prendre de (très) mauvaises habitudes.

Mais j'estime aussi que le code VB est plus lisible que le C# qui n'est au final qu'un enchevêtrement d'acolades, de paranthèses et de points-virgues inutiles

Justement non.
Si du code C# se retrouve n'être qu'un enchevêtrement d'accolades, de parenthèses et de points virgules, c'est qu'il est mal foutu (le code, pas le langage :)

Du code propre, bien organisé, n'a rien d'un enchevêtrement de quoi que ce soit. Et à la comparaison de séries de code propre, VB est... comment dire... légèrement plus chargé en nombre de caractères à l'écran, sans que ça aide à la lecture. Et si ça n'aide pas, c'est que ça encombre :)

Maintenant on peut préférer voire trouver ça plus clair. Chacun son truc.

(if, for, ...). Ses mots-clés sont aussi moins compréhensible.

Parce qu'il y a une grosse différence entre "if" et "If" ou entre "for" et "For" ?

NotOverridable je comprends très vite, mais final, ca n'a pour moi aucun sens.

Wai, si tu n'a jamais fait de POO avant, peut-être :)
Quand tu connais l'OO, utiliser 'abstract' pour définir une méthode/classe abstraite est nettement plus clair que se taper des "MustInherit" et autre "MustOverride". Idem pour les méthodes virtuelles déclarées "virtual" et pas "Overridable".

De même Const <--> final,

Essaye 'Const' vs 'const' plutôt :)

Sub <--> void

C'est sûr qu'il est plus pratique de faire plusieurs mots-clefs pour déclarer une méthode, quand la seule chose qui distingue une 'Sub' d'une 'Function' est la valeur de retour.
Encore un truc hérité de l'origine purement procédurale du VB. Une méthode est une méthode. Qu'elle renvoie une valeur ou non.
La distinction sous-routine/fonction, c'est assez loin de l'OO... et assez loin de 2006 :)

Alors peut-être en effet qu'un programmeur expérimenté n'y verra pas de problèmes, mais un débutant aura nettement plus facile avec VB qu'avec C#.

Que VB soit plus accessible aux débutants que C# n'est probablement pas très discutable. Ce qui est plus discutable est qu'il est plus accessible parce qu'il permet plus facilement d'adopter de mauvaises pratiques (cf description du Côté Obscur par Yoda :)
Notamment quand on utilise Microsoft.VisualBasic...

PS : Je n'avais jamais fait de VB et j'utilise pourtant l'espace de nom VisualBasic qui contient des fonctions très intéressantes malgré tout ce qu'on peut en dire

Il ne contient rien qui ne soit pas faisable sans.
Il ne contient rien non plus qui ait sa place dans un environnement orienté objet.
Plus généralement, il ne contient rien qui justifie son existence, et il n'y a aucune bonne raison qui justifie son utilisation.

Maintenant tu fais ce que tu veux :)

[Piotrek]

Plus généralement, il ne contient rien qui justifie son existence, et il n'y a aucune bonne raison qui justifie son utilisation.

Maintenant tu fais ce que tu veux

Voila qui résume bien

Il n'y a aucune difference fondamentale entre Vb.Net et C#; a part peut etre que certaines personnes ne peuvent supporter que d'autres ont a leur disposition un language qui fait aussi bien que le leur

[Keihilin]

Mdr ! Je savais que Maniak allait nous pondre une tartine. Il faut dire que dès que quelqu'un encense un peu VB, sa température monte de 7 degrés

J'ajouterais juste une chose concernant la "rapidité" de VB.NET :

Moi aussi au tout tout début de .Net, j'avais supposé que la productivité devait être un chouïa supérieure en VB à cause de l'intellisense beaucoup plus présent et de la compilation à la volée en background. Mais dans la pratique, pour peu qu'on ne soit pas handicapé des doigts, la différence est inexistante.

Quant à la lisibilité des langages, j'ai remarqué qu'autours de moi tous les développeurs "seniors" et ceux qui sont passés par polytechnique ou autre grande école (bref, ceux qui ont connus autre chose que VB6 avant .NET) ont une nette préférence pour C#...
De là à y voir une des raisons pour lesquelles C# fait plus pro...il n'y a qu'un pas.

[Maniak]

Mdr ! Je savais que Maniak allait nous pondre une tartine. Il faut dire que dès que quelqu'un encense un peu VB, sa température monte de 7 degrés :wink:

Surtout quand ce sont les parties à jeter qui se font encenser, en particulier Microsoft.VisualBasic :)
(pi ça fait longtemps qu'il n'y a plus eu d'activité sur ce topic :)

[Kikos31]

Quant à la lisibilité des langages, j'ai remarqué qu'autours de moi tous les développeurs "seniors" et ceux qui sont passés par polytechnique ou autre grande école (bref, ceux qui ont connus autre chose que VB6 avant .NET) ont une nette préférence pour C#...
De là à y voir une des raisons pour lesquelles C# fait plus pro...il n'y a qu'un pas.

Allez, j'y vais de mon pti mot .

Je suis absolument pas d'accord. Je ne suis certainement pas passé par polytechnique ( d'ailleur je savais pas qu'on y formait des geeks là bas ). Moi j'ai commencé à programmer sur Amstrad puis ATARI ( vive l'assembleur et les démos ) puis enfin sur PC ( Masm, Watcom C ) puis VS C++. Professionnelement, avant DOTNET, j'ai du faire majoritairement du vb6 tout en utilisant VS en prog perso ( soir et week-end).

Même si on a une préfèrence je pense qu'il ne vaut mieux pas s'enfermer dans un seul langage. Qui sait si demain il n'y aura autre chose qui va tout casser. Un langage c'est rien, au bout de quelques mois à 8h par jour on est rodé. L'important c'est la logique, la clarté de ce que l'on écrit et savoir trouver dans une doc ce que l'on cherche.

Je pense qu'il y a plusieurs raisons pour lesquels les gens préfèrent C# :

- Y a ceux qui ont tellement l'habitude de C/C++ qu'ils vont naturellement au C# ( rien à dire c'est normal vu que c'est à ces langages qu'on est formé à l'école, normalement ils sont assez connaisseur pour savoir qu'en terme de possibilité c'est kifkif )

- Y a les débutant qui ne connaissent absolument rien mais qui ont entendu que VB c'est nul donc => C# ( on entend tellement de connerie sur VB que je peux les comprendre )

- Y a ceux qui ont un certain niveau mais qui en ont marre qu'on ne les prennent pas au sérieux en VB.NET et donc qui se tournent vers C#.

- Y a ceux qui pensent (avec raison ) qu'il y a plus de boulot avec C#.

- Y a ceux qui viennent de (feu ?) Delphi et qui préfèrerai se couper une main que de toucher à un produit qui s'appelle VB. ( raah VB6 l'ennemie juré )

- Et il y a beaucoup de gens pour qui il s'agit d'un mélange de tout ça.

Moi, depuis que je suis passé à DOTNET franchement quand j'ai le choix je programme en VB.NET ( même si le C# ne me pose aucun problème ).

Je respecte le point de vue de Maniak :

Quand tu connais l'OO, utiliser 'abstract' pour définir une méthode/classe abstraite est nettement plus clair que se taper des "MustInherit" et autre "MustOverride". Idem pour les méthodes virtuelles déclarées "virtual" et pas "Overridable".

Mais moi je considère que c'est s'attacher a notre cher passé. Et je pense au contraire que MustInherit et Overridable c'est bien plus parlant. Je pense qu'en info il ne faut pas être rétrograde et c'est qui me gène un peu avec le C#.

Les accolades OK ( y a du pour et du contre ) mais le point-virgule et le CaseSensitive ca me fait un peu de mal de ce trainer ça en 2006. La limitation à un indexeur par classe aussi.

J'ai la désagreable impression que même si le Dotnet est à la pointe de ce qui se fait de mieux ( ramasse miettes, référence plutot que pointeur, serialisation auto, génériques ... ) on a gardé des vieilleries dans C# pour de mauvaises raisons : Ne pas effaroucher le vieux briscar habitué au C++ et qui a ces bonnes vielles habitudes.

Je reste persuadé que sans les apprioris négatifs beaucoup plus de gens donneraient leur chance au VB.NET.

Voilà, mon point de vue est qu'au moins avec VB.NET, la réforme a été brutale ( y'en a beaucoup qui ont pleuré ) mais qu'au moins on est repartie sur de bonnes bases, moderne et puissante.

[Maniak]

Quand tu connais l'OO, utiliser 'abstract' pour définir une méthode/classe abstraite est nettement plus clair que se taper des "MustInherit" et autre "MustOverride". Idem pour les méthodes virtuelles déclarées "virtual" et pas "Overridable".

Mais moi je considère que c'est s'attacher a notre cher passé. Et je pense au contraire que MustInherit et Overridable c'est bien plus parlant. Je pense qu'en info il ne faut pas être rétrograde et c'est qui me gène un peu avec le C#.

J'ai dû mal m'exprimer (pourtant c'est pas faute d'avoir essayé de mettre du gras où il faut :)

Le fait qu'une méthode s'appelle une méthode, qu'une méthode abstraite s'appelle une méthode abstraite, qu'une méthode virtuelle s'appelle une méthode virtuelle... c'est pas un attachement au passé. C'est le vocabulaire de la POO.

C# le respecte. VB.NET invente le sien. Super.

le CaseSensitive ca me fait un peu de mal de ce trainer ça en 2006.

Wai, ça oblige à être cohérent dans ses conventions de nommage, c'est nul :)

La limitation à un indexeur par classe aussi.

Pour ça qu'on peut en avoir plusieurs :)

on a gardé des vieilleries dans C# pour de mauvaises raisons : Ne pas effaroucher le vieux briscar habitué au C++ et qui a ces bonnes vielles habitudes.

Marrant, c'est le commentaire général sur VB.NET :)
C'est quoi ces vieilleries ? La syntaxe C ? Ça ne s'appellerait plus C# si ce n'était pas le cas. C'est pas du Ruby, mais pour une vieillerie elle se défend quand même bien.
Le point-virgule ? Détail.
Le respect de la casse ? Même s'il n'était pas obligatoire, la moindre règle de cohérence dans les conventions de code impliquerait de le faire.
Des mots-clefs qui correspondent aux termes de la POO ? C'est juste à la fois plus précis, clair et correct que la version VB.NET. Mineur.

Voilà, mon point de vue est qu'au moins avec VB.NET, la réforme a été brutale ( y'en a beaucoup qui ont pleuré ) mais qu'au moins on est repartie sur de bonnes bases, moderne et puissante.

Sub/Function/Microsoft.VisualBasic
Bonnes bases, modernes et puissantes ? :)


(oh chouette ça y est, ça a changé de page :)

[Keihilin]

Voilà, mon point de vue est qu'au moins avec VB.NET, la réforme a été brutale ( y'en a beaucoup qui ont pleuré ) mais qu'au moins on est repartie sur de bonnes bases, moderne et puissante.

Sub/Function/Microsoft.VisualBasic
Bonnes bases, modernes et puissantes ?

C'est bien là le problème avec VB.Net ! Non seulement on a fait entrer l'OO à coup de massue dans un langage existant, mais en plus on en a profité pour inventer de nouveaux termes alors que le vocabulaire existait déjà !

Je ne sais pas oû en est VB dans la version 2005, mais je rappelle quand même que ce langage était déjà mal parti à l'origine car amputé d'excellentes fonctionnalités présentes dans C#.

Quoi qu'il en soit, je pense sincèrement que maintenant le virage est définitivement pris et que tout dirige vers C#. Les "parts de marché" de VB.Net vont continuer à fondre au fur et à mesure de l'implantation de .NET dans les entreprises, j'en suis convaincu.
Même chez MS la préférence est visible...Allez faire un petit tour sur MS Research; vous verrez qu'il y a visiblement beaucoup d'avenir pour C# mais que l'on parle très peu de VB...

[neguib]

Je ne sais pas oû en est VB dans la version 2005, mais je rappelle quand même que ce langage était déjà mal parti à l'origine car amputé d'excellentes fonctionnalités présentes dans C#

Bonjour Keihilin

VB2005 poursuit ce qui a été fait dans les versions precédentes, c'est à dire son particularisme Microsoft.VisualBasic , donc rien de plus qui ne peut être fait normalement en C#.
Excepté bien sûr quelque anciens mots clés sans réel impact de programmation, exemple : With.
Par contre ce qui est nouveau c'est quà présent apparaît en C# des facilités de codage (je pense aux itérateurs génériques notamment avec yield) qui ne peuvent être transposés directement en VB.Net.
Je comprends que pour les uns VB.Net soit perçu comme verbeux, tandis que les autres le trouve explicite. C'est de mon point de vue, une simple difference culturelle. Ceci est dû à la légitime irrationalité de l'humain et n'a que peu avoir avec le judicieux du Concept ou de la Norme.

Pour information personnelle, pourrais-tu Keihilin nous décrire plus en détail ceci

... car amputé d'excellentes fonctionnalités présentes dans C#

Je ne vois pas à quoi tu fais référence sous .Net

[FremyCompany]

C'est vrai et c'est bien cela ma désolation, abandonner un si beau langage pour des rumeurs, un passé moins glorieux, quel gachis !
Mais je ne desespère pas.
Un jour les choses changeront (peut-être), les gens arrêteront de penser "abstrait" et verront un autre aspect des choses, ignoré aujourd'hui...

De toute facon, il faudra s'adapter avec son epoque, en informatique, rien n'est jamais établi, tout se construit. On verra peut-être un langage sorti de nulle part voler la vedette au .Net, et la, il faudra s'adapter ... ou périre :-)

Le temps nous apportera la réponse, moi pas.
Fremy

PS : on a tout de même escamotté l'espace de nom My de la discussion !!!