Discussion :

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

[Keihilin]

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

- Commentaires XML
- Mot-clé using
- Surcharge d'opérateurs
- Types non-signés
- Code unsafe
- Interfaces explicites

Je ne veux pas me (re)lancer dans un débat sur les qualités ou l'utilité de ces fonctionnalités...Je note juste que VB en était dépourvu à la sortie de .NET

[Maniak]

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

Ah ben j'ai failli rater ton PS :)
J'étais justement en route pour ajouter ça au dernier post de Keihilin :

Je ne veux pas me (re)lancer dans un débat sur les qualités ou l'utilité de ces fonctionnalités...Je note juste que VB en était dépourvu à la sortie de .NET

Heureusement avec 2005, VB.NET a une super nouvelle fonctionnalité.
C'est pas tout de conserver des termes et fonctionnalités qui auraient dû disparaitre au passage en orienté objet, mais maintenant on réintègre le concept de variables globales accessibles en deux lettres depuis n'importe où. Même plus besoin d'apprendre les singletons.

Ça va simplifier la vie de ceux qui se demandent comment passer des valeurs d'un formulaire à l'autre ou comment accéder aux autres fenêtres.

Ça va compliquer la vie de tous les autres, ceux qui devront repasser derrière et essayer de mettre un peu d'ordre.

C'est un grand pas en avant, si on considère que reculer de 10 (allez, 15) ans est un grand pas en avant.

[Kikos31]

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.

Oui je sais ( j'ai bien appris mes leçons moi aussi ). Maintenant toutefois on a du recul aprés plusieurs années de POO. On est pas obligé de considérer que tout est parfait. J'en veux pour preuve l'héritage multiple passé à la trappe en dotnet. On est pas obligé de tout sacraliser, l'immobilisme est suprenant en informatique. Je considère qu'il n'y a rien de sacré, le vocabulaire comme le reste.

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

Ben oui moi je trouve ca super. Je trouve qu'un mot clé inherits et implements c'est bien plus parlant que ":". D'ailleurs en IL c'est des mots clés qui sont utilisés ( extends et implements ).

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

Tu as raison, ca oblige. Moi personnellement je prèfère programmer sans flingue sur la tempe. Tu reconnaitra que malgré ça, en C# on peut quand même faire n'importe quoi dans le nommage de ses membres/propriétés. Le fait d'être CaseSensitive n'empeche rien du tout si tu veux faire du travail de cochon. Comme le fait de ne pas l'être n'empêche pas d'être rigoureux. Ca dépend tu programmeur pas du langage.

[indexer]Pour ça qu'on peut en avoir plusieurs

Autant pour moi. Jusqu'a l'astuce de merlin :

feed://blog.developpez.com/xmlsrv/rss2.php?blog=41

J'ai toujours été obligé d'utiliser les accesseurs get / set. Je suis curieux de voir un exemple.

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.

Ca s'appelle C# pour des raisons de marketing. Aprés si tu préfère les ; le respect de la casse et les : et que tu les trouve plus clair libre a toi. Mais c'est une question d'apprécition c'est pas un fait. Je considère moi que c'est des survivance du passé c'est mon droit également.

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

Ouaip bien sur ca c'est facile . Je pense qu'on peut faire une distinction entre la grosse bibliothèque pour nostalgique qu'est Microsoft.VisualBasic et le langage lui même.

Quand je dis bonne base je pense à la rupture qui a été faite par rapport à VB6 pour en faire un vrai langage DotNet.

Quand je dis moderne, je parle d'un vocabulaire et d'une structure dépoussièrée par rapport au C/C++

Quand je dis puissante, c'est parceque tout ce qui est important à été integré depuis .NET2.0. ( Si c'est pour faire du Unsafe, faut pas déconner je préfère rester en C++ non managé ).

Et quand on regarde l'avenir je vois que LINQ est développé à la fois pour C# et pour VB.NET ( d'ailleur la syntaxe VB est encore une fois bien meilleur )

Bref, cher Maniak que tu ne sois pas d'accord je te l'accorde mais je maintien mon point de vue.

[neguib]

- Commentaires XML
- Mot-clé using
- Surcharge d'opérateurs
- Types non-signés
- Code unsafe
- Interfaces explicites
...Je note juste que VB en était dépourvu à la sortie de .NET

ok donc je confirme dans ta liste
- Mot-clé using
- Code unsafe
Pour le reste il me semble que VB2005 est à jour. de l'info

[Kikos31]

- Commentaires XML
- Mot-clé using
- Surcharge d'opérateurs
- Types non-signés
- Code unsafe
- Interfaces explicites

Je ne veux pas me (re)lancer dans un débat sur les qualités ou l'utilité de ces fonctionnalités...Je note juste que VB en était dépourvu à la sortie de .NET

C'est des vieux arguments ça. Il n' y a que le code unsafe qui ne soit pas intégré au VB2005. Et franchement on s'en fout. La plupart des gens qui mettent ca en avant ne l'utilise jamais.

Moi j'en ai eu besoin une ou 2 fois au boulot ( communication indus ). J'ai fait une classe en C# et puis voilà. Pour le reste si je veux de la rapidité ( graphisme ) : C non managé.

Neguib : Si si using a été intégré en VB2005

[neguib]

Salut Kikos31
je crois que tu oublies qu'il n'est pas possible d'utiliser le using en local comme le fait C# pour contrôler la durée de vie d'une instance le temps d'une opération. Enfin je ne vois pas quel serait l'equivalent en VB.Net Eclaires moi

[Kikos31]

Salut Kikos31
je crois que tu oublies qu'il n'est pas possible d'utiliser le using en local comme le fait C# pour contrôler la durée de vie d'une instance le temps d'une opération. Enfin je ne vois pas quel serait l'equivalent en VB.Net Eclaires moi

Si tu pense à ca :

Code :

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

1
2
3
Using b As New SolidBrush(Color.Beige) 
      e.Graphics.FillRectangle(Brushes.Beige, 0, 0, 10, 30)
End Using

Ca fait partie des nouveautés VB2005

[Scorpyosis]

J'ai une formation Java, et je dois dire que C# c'est blanc bonnet et bonnet blanc sur beaucoup d'aspect, mais C# a ses caractéristiques propres. Donc pour moi C# est le langage .NET, ce qui est d'ailleurs la politique de Microsoft .

[neguib]

...
Ca fait partie des nouveautés VB2005

Merci Kikos31

Je viens du coup de trouver la doc MSDN2 concernée, suis-je bête
Using Statement (Visual Basic)

Par contre pas d'equivalent de yield (nouveauté uniquement C#) pour les génériques tu confirmes :

[Kikos31]

Merci Kikos31

Je viens du coup de trouver la doc MSDN2 concernée, suis-je bête
Using Statement (Visual Basic)

Par contre pas d'equivalent de yield (nouveauté uniquement C#) pour les génériques tu confirmes :

Ouaip pas d'équivalent pour Yield et les méthodes anonymes.
Franchement je survirerai sans ça .


Allez, je retourne programmer un peu .

[Keihilin]

C'est des vieux arguments ça. Il n' y a que le code unsafe qui ne soit pas intégré au VB2005. Et franchement on s'en fout. La plupart des gens qui mettent ca en avant ne l'utilise jamais.

Ben pas si vieux que ça...Il y a juste quelques mois que ces différences sont comblées.

Encore une fois, je ne veux pas savoir si ces fonctionnalités sont utiles ou si elle ont été ajoutées dans la version 2005. Je remarque juste que VB.Net partait déjà dans une autre voie dès le début.

La version 2005 remet un peu les compteurs à égalité ? Tant mieux...mais trop tard ! Que les raisons soient subjectives importe peu : C# est nettement plus présent en entreprise et reste le langage préféré des professionnels. Et ce n'est pas le "fabuleux" nouveau My de VB qui va renverser la vapeur.

[neguib]

La version 2005 remet un peu les compteurs à égalité ? Tant mieux...mais trop tard ! Que les raisons soient subjectives importe peu : C# est nettement plus présent en entreprise et reste le langage préféré des professionnels. Et ce n'est pas le "fabuleux" nouveau My de VB qui va renverser la vapeur.

Bien sûr puisque çà ne concerne que ceux qui developpe en VB.Net
Il est vrai que le titre du sujet

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

laisser entendre un simple listing ouvert et argumenté. Cependant la première phrase de lancement fût

Allons y lançons le débat. Quel est le meilleur langage pour .NET ?

petite translation ambigüe qui provoque je trouve l'exploration d'impasses.
Pour ma part, je ne conteste en rien les choix des uns et des autres. Tous les arguments m'interresse et je cherche à les comprendre. De là à vouloir influer sur le choix d'autrui que nenni. J'en ai ni la compétence, ni même l'envie Je codes C# quand çà m'arrange et VB.Net quand çà me plait et Delphi.Net quand çà m'amuse

PS Maniak à moi la 22ième page

[Kikos31]

Zut j'ai pas pu m'empecher de jeter un coup d'oeil .

La version 2005 remet un peu les compteurs à égalité ? Tant mieux...mais trop tard ! Que les raisons soient subjectives importe peu : C# est nettement plus présent en entreprise et reste le langage préféré des professionnels. Et ce n'est pas le "fabuleux" nouveau My de VB qui va renverser la vapeur.

La version 2005 ne remet pas seulement les compteurs a zero mais elle intègre tout ce qu'apporte le FrameWork 2.0. Je vois pas en quoi c'est trop tard. Au contraire, avant il y avait quelques arguments techniques en faveur de C#, maintenant il ne sagit plus que d'une question de gout.

Le my n'as rien a y voir ce n'est qu'un gadget ( qu'on aime ou pas ) comme le yield du C# n'est qu'une grosse macro.

Le fait que le C# ai la cote ne veux pas dire que sera toujours le cas. Fut un temps on ne jurai que de JAVA.

J'arrive pas a comprendre cet esprit 'supporter' pour un langage. Neguid est dans le vrai quand il dit :

Pour ma part, je ne conteste en rien les choix des uns et des autres. Tous les arguments m'interresse et je cherche à les comprendre. De là à vouloir influer sur le choix d'autrui que nenni

Je pense que c'est l'attitude intelligente a avoir.

Le VB.NET je le préfère, pour le moment, au C#. J'ai essayé de dire pourquoi. Mais si dans 5 ans je trouve mieux, je le laisserai tomber comme une vieille chaussette ( la maintenabilité n'est pas vraiment un problème dans mon secteur d'activité ).

Ce qui m'ennerve c'est que ce langage soit toujours descendu en flêche à tord et a travers.

[Maniak]

La version 2005 ne remet pas seulement les compteurs a zero mais elle intègre tout ce qu'apporte le FrameWork 2.0.

Pour ce qui est du framework, tous les langages sont égaux de toute façon.
Là où on fait les distinctions, c'est sur la syntaxe et les petites fonctionnalités spécifiques.

La syntaxe c'est une question de goût (on a le droit d'aimer les trucs lourds et nuls :), les fonctionnalités c'est déjà plus facile à discuter :)

Le my n'as rien a y voir ce n'est qu'un gadget ( qu'on aime ou pas ) comme le yield du C# n'est qu'une grosse macro.

Les deux n'ont rien à voir, ça oui :)
yield n'est qu'une facilité pour éviter d'avoir à se taper une classe pour une méthode. Ça ok. C'est pas la nouveauté à laquelle j'accroche le plus.
Mais au moins, ça ne favorise pas les mauvaises pratiques, comme My. Ou Microsoft.VisualBasic. Ou la redéfinition des termes orientés objets.

Le fait que le C# ai la cote ne veux pas dire que sera toujours le cas. Fut un temps on ne jurai que de JAVA.

Et ça continue pour un paquet de monde :)

Pour ma part, je ne conteste en rien les choix des uns et des autres. Tous les arguments m'interresse et je cherche à les comprendre. De là à vouloir influer sur le choix d'autrui que nenni

Je pense que c'est l'attitude intelligente a avoir.

Y a deux approches différentes qu'une même personne peut tout à fait appliquer en même temps :)
Côté boulot, on utilise ce qu'on doit utiliser. S'il faut faire un choix, on choisit ce qui correspond le mieux aux besoins et aux capacités des gens. Peu importe les préférences perso.
Hors boulot, si on préfère une syntaxe et qu'on en vomit une autre, y a aucun problème non plus :)
Faut juste pas mélanger les deux :)

( la maintenabilité n'est pas vraiment un problème dans mon secteur d'activité ).

Tu as beaucoup de chance. Essaye de ne surtout pas changer de secteur alors, parce que sinon ça peut être plus douloureux :)

Parce que peut-être qu'après avoir eu à faire de la maintenance sur des projets C# et des projets VB.NET, tous bancaux et exploitant les facilités de chaque langage pour produire des immondices, tu te dirais que *même* si au niveau du framework c'est pareil, *même* si niveau perfs c'est pareil, *même* si quand on fait du bon code c'est similaire, *même* si on peut faire de la merde avec n'importe quel langage, VB(.NET) donne des facilités à faire des horreurs qui sont largement suffisantes pour expliquer certaines réactions de rejet.

Ce qui m'ennerve c'est que ce langage soit toujours descendu en flêche à tord et a travers.

On vire Microsoft.VisualBasic, on met des mots-clefs qui correspondent aux concepts de la POO, on vire Option Explicit, on vire Option Strict, et là peut-être qu'il y aurait bien moins de raisons de descendre ce langage.

Bien manié, pas de problème. Mal manié, que ce soit par des débutants qui ne connaissent rien à l'OO ou par des branleurs qui sautent sur la moindre solution de facilité plutôt que d'utiliser deux neurones, je choisirai *toujours* la maintenance d'une appli C# mal foutue avant celle d'une appli VB.NET mal foutue. Et j'ai eu largement l'occasion de faire la comparaison :)

[Kikos31]

La syntaxe c'est une question de goût (on a le droit d'aimer les trucs lourds et nuls

Parfaitement d'accord je te renvoi ton argument : on a le droit d'aimer les trucs vieux et lourd

Ça ok. C'est pas la nouveauté à laquelle j'accroche le plus. Mais au moins, ça ne favorise pas les mauvaises pratiques, comme My. Ou Microsoft.VisualBasic. Ou la redéfinition des termes orientés objets.

J'te rassure le my ca m'excite pas vraiment non plus.

Allez, comme suis masochiste je te donner un argument dans ton sens :
J'ai été horrifié de voir qu'il y a une instance par défaut pour pouvoir acceder a une autre fenêtre sans l'instancier (depuis vb2005). Ca c'est vraiment une connerie et ca n'a aucun sens. En VB2002 je l'aurai compris ( ca m'aurait enervé et tout et tout mais j'aurai compris ) mais maintenant les VB6istes ont eu le temps de se faire une raison ( et rentrer dans le droit chemin ). Voilà pour moi c'est le truc débile.

Y a deux approches différentes qu'une même personne peut tout à fait appliquer en même temps
Côté boulot, on utilise ce qu'on doit utiliser. S'il faut faire un choix, on choisit ce qui correspond le mieux aux besoins et aux capacités des gens. Peu importe les préférences perso.
Hors boulot, si on préfère une syntaxe et qu'on en vomit une autre, y a aucun problème non plus
Faut juste pas mélanger les deux

A mon avis tu présente les symptomes d'une allergie aïgue . Là il n'y a plus rien a faire ( un marabou peut-être ?).

( la maintenabilité n'est pas vraiment un problème dans mon secteur d'activité ).

Tu as beaucoup de chance. Essaye de ne surtout pas changer de secteur alors, parce que sinon ça peut être plus douloureux

Je suis d'accords. De toutes façons les rares fois ou je suis passé derrière quelqu'un autre ca m'a quand même énervé. Parce que indépendament du langage c'était pas fait à ma façon ( la seule a être parfaite ).

Parce que peut-être qu'après avoir eu à faire de la maintenance sur des projets C# et des projets VB.NET, tous bancaux et exploitant les facilités de chaque langage pour produire des immondices, tu te dirais que *même* si au niveau du framework c'est pareil, *même* si niveau perfs c'est pareil, *même* si quand on fait du bon code c'est similaire, *même* si on peut faire de la merde avec n'importe quel langage, VB(.NET) donne des facilités à faire des horreurs qui sont largement suffisantes pour expliquer certaines réactions de rejet.

Je suis catégorique, il s'agit bien d'allergie.
Plus sérieusement je te comprends mais j'ajouterai un bémol :
Je suis pas certain que la rigidité/permissivité d'un langage joue tant que ça. Moi j'ai une autre théorie : Avant les gens qui faisaient notre métier étaient des passionnés, ils ont grandis avec l'informatique. Maintenant il sort des écoles des tas de developpeurs pour qui ce n'est qu'un métier et ils ne vont certainement pas se casser la tête a chercher le moyen de faire propre. Ils s'en foutent, ils veulent juste pisser de la ligne jusqu'a que la journée soit fini.

Par exemple : moi le dataset typé avec tout son bordel a l'interieur kejesaismêmekeskiyadedans j'ai jamais pu me resoudre a l'utiliser. Mais plein de gens s'en contre foute et en use et en abuse (et celà aussi bien en C# qu'en VB.NET).

On vire Microsoft.VisualBasic

pourquoi pas c'est redondant et ca facilite pas la conversion VB.NET=>C#.

on met des mots-clefs qui correspondent aux concepts de la POO

Pas d'accord moi j'aime mieux comme ça.

on vire Option Explicit, on vire Option Strict

Parfaitement d'accord et le test de débordement de tableau aussi par la même occasion.

et là peut-être qu'il y aurait bien moins de raisons de descendre ce langage.

je dirais il ne resterai plus de raison pour ne pas ce jeter sur ce langage .

Et j'ai eu largement l'occasion de faire la comparaison

Et apparament ca a laissé des traces .

[Maniak]

Côté boulot, on utilise ce qu'on doit utiliser. S'il faut faire un choix, on choisit ce qui correspond le mieux aux besoins et aux capacités des gens. Peu importe les préférences perso.
Hors boulot, si on préfère une syntaxe et qu'on en vomit une autre, y a aucun problème non plus :)

A mon avis tu présente les symptomes d'une allergie aïgue :lol: . Là il n'y a plus rien a faire ( un marabou peut-être ?).

Non non, j'ai aucun problème vis-à-vis du VB.NET quand c'est bien fait :)

De toutes façons les rares fois ou je suis passé derrière quelqu'un autre ca m'a quand même énervé. Parce que indépendament du langage c'était pas fait à ma façon ( la seule a être parfaite :wink: ).

Ça, c'est autre chose :)

Plus sérieusement je te comprends mais j'ajouterai un bémol :
Je suis pas certain que la rigidité/permissivité d'un langage joue tant que ça.

J'ai pas de preuve à apporter non plus. C'est juste la conclusion que je tire à l'instant T basé sur ce que j'ai vu jusqu'à présent :)
Je suis peut-être mal tombé, qui sait :)

Moi j'ai une autre théorie : Avant les gens qui faisaient notre métier étaient des passionnés, ils ont grandis avec l'informatique. Maintenant il sort des écoles des tas de developpeurs pour qui ce n'est qu'un métier et ils ne vont certainement pas se casser la tête a chercher le moyen de faire propre. Ils s'en foutent, ils veulent juste pisser de la ligne jusqu'a que la journée soit fini.

Ah, les écoles. Grand sujet à débat ça aussi :)

Pas grand chose à ajouter à ta théorie, je partage l'avis :)
Si ce n'est que la situation n'est pas si récente que ça. C'est pas 'maintenant' que les écoles produisent des bidouilleurs qui croient (ou essayent de faire croire) que leur bout de papier veut dire quelque chose.
(et ça fait un bout de temps qu'à peu près tout le monde grandit avec l'informatique :)

Perso, avant de chercher à déterminer le langage ultime, je préfèrerais qu'on commence par déterminer comment décourager ceux qui cherchent juste un filon facile, en compliquant la vie des autres, et comment former correctement ceux qui auraient la motivation mais ne savent pas où aller.

S'il n'y avait que des gens compétents, le langage importerait peu.

Par exemple : moi le dataset typé avec tout son bordel a l'interieur kejesaismêmekeskiyadedans j'ai jamais pu me resoudre a l'utiliser. Mais plein de gens s'en contre foute et en use et en abuse (et celà aussi bien en C# qu'en VB.NET).

Amen.

on met des mots-clefs qui correspondent aux concepts de la POO

Pas d'accord :wink: moi j'aime mieux comme ça.

Ah, le glisser au milieu de la liste n'a pas été assez discret :)

et là peut-être qu'il y aurait bien moins de raisons de descendre ce langage.

je dirais il ne resterai plus de raison pour ne pas ce jeter sur ce langage :wink:.

Il en resterait une : c'est du VB, et il y a du C juste à côté :)
(quitte à se jeter sur un nouveau langage, autant aller voir du côté de Ruby :)

Et j'ai eu largement l'occasion de faire la comparaison :)

Et apparament ca a laissé des traces :lol: .

T'as pas idée :)
Et encore, je me suis modéré depuis le temps. Doit y avoir des posts dans les 10 premières pages du topic où j'étais moins tendre :)


PS: neguib, tu as peut-être eu la 22è page, mais c'est pas toi qui la remplira le plus. NA :)