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

Bonjour,

�tant d�butant en .Net je ne me prononcerai pas sur quel est le meilleur langage entre C# et VB.Net.

Cependant, je me demandais une chose : qu'en est-il de C++ ? Y-en a t'il encore certains d'entre vous qui continue � d�velopper en C++ avec VS .Net ?

En effet, bien qu'il est toujours possible de d�velopper en C++ avec Visual Studio .Net, j'ai l'impression que peu l'utilise au profit de C# ou VB.Net. La preuve le fait d'avoir omis C++ dans le d�bat.

Je me trompe ?

Sans le cast en effet �a compile, mais j'ai des soucis de fonctionnement par la suite (je parle du Drag & Drop d'objets et non la soluce � Microsoft qui consiste � passer une chaine de caract�res).


Pour ce qui est du C++, tu peux programmer avec pour avoir un gain de perfs dans les zones critiques, ou bien si tu as besoin de faire faire du code non manag�. Sinon autant pass� � C#.

Ben sans d�tenir LA r�ponse, je dirai que VB.NET a toutes les corrections syntaxiques que j'attendai.
Ce n'est peut �tre pas le langage le plus rapide, mais il a au moins l'avantage d'�tre un des plus simple.
Je crois que ces langages comblent � eux deux l'emprise qu'a JAVA depuis un certain temps dans le milieu professionnel (il suffit de regarder les offres d'emploi pour s'en convaincre)
C'est d'ailleurs tr�s similaire dans l'approche du Framework.
C sharp sonne "C" ou "C++" donc pro, VB.NET sonne le RAD par excellence, (j'exorcise volontairement Delphi qui est � mon sens trop "BORLANDISE" pour connaitre un r�el �lan professionnel)
Donc je dirai : VB.NET r�cup�re les d��u du VB qui passe � DELPHI
C sharp r�cup�re les pros et recolle les morceaux des loup�s J++ et visual C++.
En tout cas, je sais que ca va en d�friser plus d'un, mais je trouve que VB.NET est une �volution plus que bien pens�e du VB

Pour ma part je ne fais comme personne (c'est a dire que je ne fais ni de VB .NET (j'expliquerai plus loin pourquoi) ni de C# (je suis toujours perdu dans les m�andres du C++, alors pas le temps). Mais je crois que d�s que je me serais d�p�tr� du C++, il y a de fortes chances que je migre vers le C#. En effet ce language a l'air de pr�senter de nomreux avantage, comme d'etre clairement "fait sur sur mesure" pour windows (qu'on m'arrete si je me trompe), et en plus la syntaxe me plait assez (car proche des language issus de C).
Quand a VB... Je ne sais pourquoi, je n'ai aucune atirance pour ce language... D'abord pour une question de sintaxe que je trouve assez d�plaisente.
Et au final j'�mets une reserve vis-a-vis de .net et de la programation sous windows en g�n�ral. En effet je ne suis pas convaincu que cela ne soit pas lassant a la longue de sans arret changer de vertions et de voir les bibliotheques �voluer...
Br�f...

Comme on la dit: que soit VB.Net ou C# on passe par le language intermediaire.
Les librairies qu'on attaque sont les memes: celles du framework.

Donc performance, structures des algos, possibilit�s sont a "un chouillat pr�s" les memes non?

Apr�s on rentre dans la subjectivit� d'appr�ciation de la synthaxe. La, chacun ses gouts. et a mon avis, une fois maitris�, le passage de l'un a l'autre c'est assez facile si on est un peu rigoureux.(contrairement au passage VB pur et dur a VB.Net)

par contre l'argument de Neo sur "l'ouverture" du C# est peut etre la clef.

Il y a quelques ann�es j'ai d�couvert par erreur Visual Basic 2.0... j'ai fait quelques programmes et j'�tais content.

Niveau perf c'�tait pas cela, appeler les diff�rentes DLL �tait un cauchemard. Puis ensuite j'ai arr�t� de programmer pendant plus de 2 ans pour passer ma maturit� (le BAC fran�ais)

Apr�s j'ai repris la programmation � l'EPFL (www.epfl.ch) avec de l'ADA95, un langage sur-chiant au niveau du typage, mais relativement plaisant au niveau de la qualit� du code qui d�coule de ces contraintes.

Parall�lement je me suis mis au C, puis C++, les perfs �taient au rendez-vous, mais �crire du code "propre" sans fuites m�moires demandait une discipline de fer.

J'ai du faire quelques sites Webs dynamiques et la j'ai touch� � deux technologies : ASP avec VBScript qui ressemble fortement � VB et PHP avec un syntaxe proche du C.

Recemment j'ai commenc� � ressentir le besoin d'un framework complet pour d�velopper des applications Web, et deux framwork ont retenu mon attention : J2EE de Sun Microsystems et .Net de Microsoft.

Apr�s une �tude des deux framework et d�veloppement d'un application sosu J2EE il est apparu que J2EE demandait une infrastructure trop importante pour �tre impl�ment� correctement, et que les serveurs d'application n'�taient pas tous parfaitement compatibles entre eux.

Bon alors .Net... la le choix du langage se pose ! Je suis � l'aise aussi bien avec l'une et l'autre syntaxe. Je constate que C# est relativement proche de la syntaxe du C++ et que pour VB. Net les incoh�rences de syntaxes sont corrig�es et que les op�rateurs du genre &= ont �t� ajout�s. Donc pas tellement de pr�f�rence pour l'un ou l'autre.

Bon alors je me penche sur les perfs... c'est un peu du pareil au m�me, pas non plus un crit�re de choix.

Finalement j'ai quand m�me opt� pour VB.Net, pour une seule raison, je trouve que la syntaxe est plus proche du langage naturel...

If [condition] Then est, � mon avis, plus parlant que if ([condition]) {}

Pour ma part, je fais du C++ et du Java en cours. J'ai fait aussi du VB6, de fa�on autonome. Maintenant, je me suis lanc� dans le C# et J#, mais pas encore dans le VB.Net, alors difficile d'en dire quelquechose de construit. Alors voil� ce que j'en pense. Je trouve la plateforme de microsoft, tres bien foutu (c'est g�nial d'utiliser les m�mes classes quelque soit le langage !) Je ne peut donc faire un comparatif qu'entre C# et J#. Et bien ma r�ponse va �tre tr�s simple, je suis plus a l'aise avec J#, parceque j'ai appris la notion d'objet avec Java, et pas C++, donc je navigue plus ou moins en terrain connu avec le J#. Par contre en faisant du C#, il est clair qu'il est d'une grande facilit� d'utilisation, m�me pour les non initi�s. Concernant, VB, au temps de VB6, �a a �t� tres bien pour moi qui n'avais aucune base en programmation, cependant pour avoir lanc� VB.Net une ou deux fois, les choses ont l'air de bien avoir chang�es. donc pas trop d'opinion pour l'instant.

Au final, pour l'instant je reste sur le J# (j'aime beaucoup Java :) )

Voil�, cependant peut etre que dans deux mois j'aurais chang� d'avis :lol: .

@+

sady

Bonjour,

C# : � choisir si on conna�t C/C++ ou Java. C'est mon cas et c'est donc logiquement que j'ai choisi C# pour d�velopper mes applications web en ASP.NET avec WebMatrix. Si je me mets au d�veloppement d'applications Windows avec .NET, je ne choisirai pas C++ .NET mais C#. Ce langage est tellement g�nial qu'il faudrait �tre fou pour ne pas l'adopter :). Bien entendu tout d�pend du contexte, quand on repart de z�ro, autant prendre le petit nouveau sous son aile :)

VB.NET : je m'essaie � VB.NET car c'est une �volution majeure de VB. J'aime la POO et VB.NET me contente tout � fait ! Sans compter que VB, VB.NET, VBA... tous ces petits gars sont li�s en quelque sorte et il vaut mieux les suivre de pr�s. Plus important je pense que VB.NET est id�al pour les d�butants ou les d�veloppeurs interm�diaires. Il est simple et puissant, sa syntaxe est plus logique pour un novice car elle est plus litt�raire que celle de C# ou C++. Pas besoin de ;, de {} et autres :)

Donc le choix que l'on fait d�pend du contexte, de son niveau, des projets sur lesquels on a travaill�, on doit travailler... Ils ont chacun des avantages et des inconv�nients. VB.NET est id�al pour s'initier � la programmation alors qu'un d�veloppeur confirm�, souvent avec un background C/C++, choisira C#, logiquement.

JM. Molina

<Petite parenth�se>
Je suis ulc�r� de lire - bien que cela soit en partie vrai � la base - que VB est un langage "de d�butant", "d'amateur". Je pratique le VB depuis la version 2.0 et je connais des applications cons�quentes d�velopp�es en VB qui tournent sans le moindre bug (logiciels de comptabilit� utilis� dans des centres de gestion agr��s : d'un autre niveau que les Ciel et autres EBP, je peux vous le dire... ; logiciel de gestion commerciale tournant dans plus de 1500 magasins en France, etc...)
Tout est question de discipline. Ce n'est pas le langage qui fait la qualit� du produit final, c'est bien le programmeur (sous-entendu un mauvais programmeur sera toujours plus mauvais qu'un bon programmeur, qqsoit le ou les langages utilis�s)
Evidemment il est exclu - � mon humble avis - d'utiliser VB (ancienne g�n�ration) pour autre chose que des outils de gestion au sens large. Exit les jeux 3D et autres logiciels de calcul intensif... Il existe des outils mieux adapt�s � ce genre de chose !
</Petite parenth�se>

J'utilise aujourd'hui essentiellement VB.NET. Pas par passion mais tout simplement parce que c'est la syntaxe � laquelle je suis le plus habitu� (disons que mes doigts trouvent plus vite les touches du clavier quand je code du VB :lol: ). De plus certains m�canismes propres � Intellisense ne fonctionnent pas en C# (sauf erreur de ma part) et ils apportent pourtant des gains de productivit� appr�ciables (je suis un inconditionnel de l'autocompl�tion)

Mais j'utilise aussi C#, par n�cessit�. En effet, la majorit� des exemples de codes que l'on trouve sur le Net sont en C#. Il a donc �t� essentiel pour moi de m'impr�gner au mieux de sa syntaxe (je connais le PHP et j'ai pratiqu� - comme beaucoup - le C/C++ lorsque j'�tais �tudiant : cela m'a aid� mais j'avoue que je n'ai encore jamais �crit d'application compl�te en C#...) car il est plus productif d'adapter et d'int�grer des biblioth�ques C# dans une solution que de les traduire en VB.NET.

Pour conclure et donner un avis objectif : quel int�r�t pour le d�veloppeur VB de perdre du temps � apprendre la syntaxe de C#, comme quel int�r�t pour le d�veloppeur C/C++ � changer de syntaxe pour se mettre � VB.NET ?... Le ma�tre mot est "productivit�" et si l'on s'�clate avec son langage de pr�dilection, il n'y a pas de raison pour en changer !

Comme l'a justement expliqu� Vincent, pour r�pondre � cette question, il faut comprendre l'architecture du FrameWork.
Un premier test c'est �videmmment de d�compiler avec ildasm.exe : quel que soit le langage utilis�, c'est le m�me IL � 99 % (les diff�rences sont triviales, cher mod�rateur) qui est compil� � la vol�e et ex�cut�. DOnc quand qqn vous dis: "moi qui connais .NET, je code en C# parce que c'est plus rapide � l'ex�cution", vous pouvez �tre s�r qu'il n'a rien compris � .NET ! Second test: pr�-compiler (pre-JIT) votre code et chronom�trez...
C#, VB.NET, etc. : tout d�pend de quel monde on vient, des go�ts de chacun, etc. Mais ceux qui continuent � dire "tout ce qui commence par C, c'est mieux que VB" sont en fait frustr�s de ne plus conserver les avantages du C++ sur VB 6.0.

d'accord sur les a prioris C/VB qui n'ont plus lieux d'etre.

Maintenant, sur les performances, les compilateurs de chaques languages n'ont pas les memes settings par d�faut et il existe donc des diff�rences de performances suivant les languages et les applications.
Bien sur on peut parametrer la compilation, pour obtenir le meme MIL...
mais si personne n'est la pour dire qu'il existe des diff�rences de perf, personne n'ira toucher aux settings des compilateurs. :wink:

attention, les diff�rences de performances ne seront sensibles que dans certains types d'applications. Plus d'info en cherchant dans cet article en anglais :wink:

je programme en vb net et

Citation:

---

le module de g�n�ration de documentation est tr�s pratique

---

c'est annonce pour la version future de vb net 2004 (net 2.0)

J'ai essaye C# que je trouve trop esoterique avec les }}} on sait jamais ou ca finit

j'ai programm� en vb 4 et vb 6 avant puis vb script (asp)

je voulais me mettre au C# simplement a cause de l'impression que j'avais que microsoft allait laisser tomber vb ... ca n'a pas l'air d'etre le cas

j'active toujours option strict et option explicit , c'est donc strict et explicit si on veut ....

Citation:

---

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.

---

moi pareil et en plus susceptible a la casse ! ca me les casse
si tu ecris string c'est pas String


je ne veux plus entendre parler de C#

Pour relancer un peu le d�bat, j'ai un exemple simple qui fait que je risque de ne jamais basculer vers C# (m�me s'il m'arrive d'en faire un peu de temps en temps pour le fun :lun:)

en asp.net, avec vb.net on g�re les �v�nements de la fa�on suivante :

Code:

---

Public Sub rechercher_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles rechercher.Click

---

Handles permet d'associer l'�v�nement rechercher.Click � ma proc�dure rechercher_Click

Donc quand je d�clare ma proc�dure, en 2 mots j'y associe un �v�nement d'un webform.

En C# c'est pas tout � fait pareil :

Dans mon InitializeComponent() je dois d�clarer toutes mes proc�dures et y associer les �v�nements.

Code:

---

this.DataGrid1.ItemCommand += new System.EventHandler(this.DataGrid1_ItemCommand);

---

et c'est apr�s que je peux faire ma proc�dure :

Code:

---

1 2 3

public void rechercher_Click(System.Object sender, System.EventArgs e) { }

---

Alors c'est peut-�tre moi qui n'ai pas su trouver un moyen d'associer un proc�dure � un �v�nement "� la vol�e" mais je trouve la syntaxe C# assez g�nante et bien moins claire que celle du VB.NET sur ce point l�.

Citation:

---

Envoy� par neo.51

Alors c'est peut-�tre moi qui n'ai pas su trouver un moyen d'associer un proc�dure � un �v�nement "� la vol�e" mais je trouve la syntaxe C# assez g�nante et bien moins claire que celle du VB.NET sur ce point l�.

---

Sur ce point-l�, oui. Sur ce point-l� unikement :)
'Handles machin' est un raccourci pour associer les m�thodes g�rant des �v�nements dans la m�me classe, �a c'est bien. Par contre si on veut associer une m�thode � un �v�nement d'ailleurs, faut passer par un

Code:

---

AddHandler événement, AddressOf gestionnaire

---

plut�t similaire � la version C# :)

Sinon, pour rester dans les comparaisons de syntaxe, un autre exemple totalement au hasard :

C# :

Code:

---

1 2	public string Toto { get { return _toto; } }

---

VB.NET :

Code:

---

1 2 3 4 5

Public ReadOnly Property Toto() As String Get Return _toto End Get End Property

---

Kand on a bcp de classes avec chacune son lot de propri�t�s, �a devient rapidement bien plus lourd k'une ligne de plus aux kelkes endroits ki associent des m�thodes � des �v�nements :)

Autre comparaison, pas vraiment li�e � la syntaxe cette fois :
C# :

Code:

---

1 2 3

uint toto = 0; if ( toto == 0 ) DoSomething();

---

VB.NET :

Code:

---

1 2 3 4

Dim toto As UInt32 If toto.Equals( Convert.ToUInt32( 0 ) Then DoSomething() End If

---

Si kkn connait un moyen de faire comprendre � VB.NET ke les entiers non-sign�s ne sont pas des bestioles import�es d'amazonie et ke les comparer � des constantes n'est pas anormal, je suis preneur.

Dans le m�me genre :
C# :

Code:

---

1 2 3

uint toto = 0, titi = 1; if ( toto == titi ) DoSomething();

---

VB.NET :

Code:

---

1 2 3 4 5

Dim toto As UInt32 = 0 Dim titi As UInt32 = 1 If ( toto.Equals( titi ) ) Then DoSomething() End If

---

Car bien s�r, l'op�rateur de comparaison entre UInt32 et UInt32 n'existe pas.


Je passe sur l'absence de clause using tr�s, tr�s pratike pour une gestion de ressources propre. Tout laisser trainer dans un coin en attendant ke le garbage collector daigne faire le m�nage, c'est pas terrible. Appeler Dispose � la main partout est mieux, plus lourd, et pas garanti, exceptions obligent. Plus g�n�ralement, using permet de simuler l'ex�cution automatike de code kand un objet passe 'out of scope' (ce k'on peut faire en C++ avec les destructeurs, mais pas en .NET vu k'on n'a aucun contr�le sur le moment o� les destructeurs sont appel�s). Bien pratike aussi, et pas ke pour la gestion de ressources (ie pour se faire un traceur ki analyse des blocs de code particuliers).

+ la doc automatike (ki arrivera peut-�tre dans VS.NET2004 oui, mais en attendant on est en 2003 et toutes les entreprises ne vont pas se pr�cipiter pour racheter des licences dans kks mois), + tous les petits avantages sp�cifikes � la syntaxe C, ke ce soit les op�rateurs type += ou ++, ou encore le for surpuissant. Toutes ces petites choses ki rendent le code bien plus compact/clair/lisible (pour peu k'on ne colle pas tout comme un gros crade et k'on exploite correctement la coloration de syntaxe), tout en �tant plus performant.


Tout �a pour dire, je peux comprendre k'on trouve la syntaxe VB.NET plus 'claire' (c'est verbeux, y a pas � apprendre le sens de kks op�rateurs, m�me si �a n'a rien de complik�), mais dire ke la syntaxe de C# est plus lourde ke celle de VB.NET en se basant sur un cas particulier, alors ke le reste du temps c'est totalement le contraire (verbeux donc :), l� non :)

Je n'ai jamais dis que la syntaxe C# �tait plus lourde que la syntaxe VB, j'ai dis que la syntaxe VB.NET �tait plus claire.

Pour la g�n�ration de documentation il y a des outils comme Ndoc qui font �a tr�s bien.

Revenons sur tes exemples de syntaxe :

C#

Code:

---

1 2	public string Toto { get { return _toto; } }

---

VB.NET

Code:

---

1 2 3 4 5 6

Public ReadOnly Property Toto() As String Get Return _toto End Get End Property

---

ok il y a plus de ligne de code en VB.NET, mais bon quand on utilise Visual Studio l'argument ne tient plus car rien qu'en d�clarant la property le squellette se fait tout seul.

Mais au niveau lisibilit�e

je trouve qu'un

Code:

---

End Property

---

est plus explicite qu'un

Code:

---

}

---

Quand on a beaucoup de code je trouve que les end de VB rendent le code plus lisible.

Apr�s pour ce qui est de la gestion des type, je suis d'accord avec toi, mais je reste nuanc� :

Code:

---

1 2 3

uint toto = 0, titi = 1; if ( toto == titi ) DoSomething();

---

Code:

---

1 2 3 4 5

Dim toto As UInt32 = 0 Dim titi As UInt32 = 1 If ( toto.Equals( titi ) ) Then DoSomething() End If

---

ok en VB.NET c'est bien moins pratique et �a peu tr�s vite devenir tr�s chiant. Mais on pourra pas reprocher � VB.NET de pas �tre objet :lol:

+= existe en VB.NET, pas ++ :wink:

P.S : maniak arrettes avec tes "k" s'il te plait et lis tes mp

Citation:

---

Envoy� par neo.51

Je n'ai jamais dis que la syntaxe C# �tait plus lourde que la syntaxe VB, j'ai dis que la syntaxe VB.NET �tait plus claire.

---

Et 'assez g�nante', c'est surtout �a ki m'a fait tiker :)

Citation:

---

Pour la g�n�ration de documentation il y a des outils comme Ndoc qui font �a tr�s bien.

---

Notamment kand �a utilise les fichiers XML g�n�r�s automatikement gr�ce aux tags /// du C# :)

Citation:

---

ok il y a plus de ligne de code en VB.NET, mais bon quand on utilise Visual Studio l'argument ne tient plus car rien qu'en d�clarant la property le squellette se fait tout seul.

---

Si tu utilises les assistants peut-�tre. Et en ASP.NET, utiliser les assistants est un choix de vie ki est loin, tr�s loin, d'�tre le mien. Parce ke gagner kks secondes avec ce genre de choses pour en perdre plein d'autres avec toutes les salet�s ke �a pond, c'est pas rentable :)

Citation:

---

Mais au niveau lisibilit�e

je trouve qu'un

Code:

---

End Property

---

est plus explicite qu'un

Code:

---

}

---

Quand on a beaucoup de code je trouve que les end de VB rendent le code plus lisible.

---

Kestion de go�t pour �a. D'habitude aussi probablement.
Perso, les accolades, du moment k'elles sont bien align�es verticalement et ke le code est bien a�r�, �a ne me pose aucun pb de lisibilit�. Au contraire. Tu vois un }, tu remontes les yeux et tu tombes sur le { correspondant. Rapide et pr�cis :)

� condition de ne pas avoir 10 �crans entre une accolade d'ouverture et une de fermeture, mais l� �a rentre dans le principe d'avoir du code propre :)

S'il y a un point sur lekel je ne discuterai pas, c'est bien ke la syntaxe C permet de faire du code vraiment illisible. Mais avec un minimum de rigueur (k'il vaut mieux avoir kand on est d�veloppeur), elle n'a rien � envier � la syntaxe du VB niveau clart�, tout en �tant plus l�g�re.

Citation:

---

Apr�s pour ce qui est de la gestion des type, je suis d'accord avec toi, mais je reste nuanc� :

ok en VB.NET c'est bien moins pratique et �a peu tr�s vite devenir tr�s chiant. Mais on pourra pas reprocher � VB.NET de pas �tre objet :lol:

---

Ben si justement :)
VB.NET a �t� proclam� haut et fort comme �tant orient� objet � fond, au m�me titre ke C++/C#/Java/Whatever. Et kand on veut s'en servir pour faire de l'OO, on tombe sur des couches de lourdeur assez ph�nom�nales.

Donc bon, si on parle de programmation proc�durale, ok, la plupart des inconv�nients de VB.NET par rapport au C# disparaissent. Surtout ke le code C/C# en proc�dural a tendance � �tre immonde. Mais vu ke perso je ne parle ke de programmation objet... :)
(c'est un peu un des principaux int�r�ts de .NET apr�s tout :)

Citation:

---

+= existe en VB.NET, pas ++ :wink:

---

Ah, pas vu pour le +=, my bad :)
Mais �a ne marche pas pour les gestionnaires d'�v�nements :)

Citation:

---

P.S : maniak arrettes avec tes "k" s'il te plait et lis tes mp

---

Vu, mais �a va �tre (tr�s) difficile, c'est g�n�tike, j'ai une sainte horreur des 'qu' coll�s inutilement partout dans cette langue (et mon pseudo n'est pas un hasard). Je n'en mets ke dans les textes 'pro' (et �a n'a rien � voir avec le style SMS ke je ne peux pas voir en peinture. trouve-moi un endroit o� j'ai mis une abr�viation � la con :)

Salut neo,

Citation:

---

Envoy� par neo.51

Par contre, il y a un point qui pour moi est tr�s important qui n'a pas �t� abord�. VB.NET est un langage propri�taire de microsoft donc tous les outils pour programmer en VB.NET seront fournis par microsoft et donc par cons�quent pour .NET.

---

C'est s�r? Pourtant SharpDevelop, qui est en open source, permet de faire du C# ET du VB.Net.

O� peut-on trouver un historique de la cr�ation de C# ? Pour ma part, ce qui m'a �tonn� le plus en d�couvrant .Net ce n'est pas la coexistence de C# et VB, mais celle de C# et C++, deux langages OO h�rit�s de C.

Apparement les choses ont �volu�s :wink:

en tout cas le C# est d�pos� en tant qu'ISO pas le VB.NET.

Pour ce qui est la coexistance de VC++.NET et C# c'est surtout pour faire migrer les codeurs VC++ vers .NET :wink:

Citation:

---

Envoy� par neo.51

Pour ce qui est la coexistance de VC++.NET et C# c'est surtout pour faire migrer les codeurs VC++ vers .NET :wink:

---

Pour �a il y a le managed C++. C# est plut�t pour attirer les d�veloppeurs Java :)

(ki sont semble-t-il particuli�rement t�tus vu k'il a fallu leur faire un J# globalement inutile, juste histoire d'�tre encore plus proche, et c'est m�me pas dit ke �a suffise :)