Discussion :

[laffreuxthomas]

Meme avec .NET, on programme en Visual
Basic ou c# (ce dernier �tant plus une politique commerciale qu'une aide au d�veloppeur).

D'apr�s moi, la plate-forme .Net h�rite de Java et Delphi.

Donc non, C# n'est pas un langage commercial. Il est destin�s au programmeurs Objet, alors que VB.Net est plus utilis� par des d�veloppeurs proc�duraux (m�me si les 2 langages sont �quivalents). C'est un tr�s bon langage qui corrige plusieurs d�fauts de Java :

* Impossible de r�cup�rer plusieurs valeurs en sortie d'une m�thode en Java (ie passage par r�f�rence de type de base)
* Nommage : les noms des accesseurs sont standardis�s, et v�rifi�s par le compilateur (ce sont les "propri�t�s")
* Lors de l'impl�mentation de plusieurs interfaces, Java ne g�re pas le cas de deux m�thodes qui ont la m�me signature (2 m�thodes homonymes peuvent signifier des choses diff�rentes)
* En C#, on utilise des pointeurs de fonctions pour les �v�nements. C'est contestable, mais �a �vite une instanciation suppl�mentaire qui a lieu pour les classes anonymes, avec souvent une unique m�thode dedans...

Voili voilo. Je ne donne pas les inconv�nients de la plate-forme .Net car ils sont d�j� cit�s. Mais je n'ai pas rencontr� d'inconv�nients majeurs sur le langage C# proprement dit.

Thomas

[grishka]

Je m'apercoit que le d�bat aurait du �tre plutot entre c# et java : en gros
pourquoi avoir proposer c# si on a d�j� java?
1-c# apporte r�ellement de nouvelles fonctionnalit�s. Donc Sun a oubli� des choses dans java qui �taient r�ellement indispensables (sinon pourquoi?) J'attends des r�ponses car apr�s tout c# a tout � fait le droit d'�tre meilleur que java (et la concurrence est b�n�fique)
2-pour r�cup�rer les programmeurs java
3-Ou les deux.

* Impossible de r�cup�rer plusieurs valeurs en sortie d'une m�thode en Java (ie passage par r�f�rence de type de base)
peux-tu pr�ciser et donner un exemple stp?

* Nommage : les noms des accesseurs sont standardis�s, et v�rifi�s par le compilateur (ce sont les "propri�t�s")

En java quel est la diff�rence entre attribut et propri�t� d'une classe? c'est du vocabulaire propre aux JavaBeans. Un attribut est une propri�t� si il propose un moyen d'acc�s par get/set. En c# cela veut donc dire que tout les attributs sont des propri�t�s? ou est pass�e l'encapsulation alors?

* Lors de l'impl�mentation de plusieurs interfaces, Java ne g�re pas le cas de deux m�thodes qui ont la m�me signature (2 m�thodes homonymes peuvent signifier des choses diff�rentes)

Je ne vois pas vraiment l'int�r�t et en plus cela induirait des incoh�rences de mod�lisation. En effet une interface peut mod�liser le comportement d'un type d'obet. Donc si il existe une interface Fichier avec la m�thode close() et une interface Fenetre avec aussi la m�thode close(), est-il sens� de cr�er une classe qui impl�mente Fenetre et Fichier? Un objet qui se comporte comme une Fenetre et un Fichier, ca n'aide pas vraiment � bien programmer objet. Il existe peut �tre un probl�me moins naif que celui que je donne(dans ce cas exposez-le). En tout cas en programmation objet, la r�utilisation passe aussi par la d�l�gation et pas seulement par l'h�ritage

* En C#, on utilise des pointeurs de fonctions pour les �v�nements. C'est contestable, mais �a �vite une instanciation suppl�mentaire qui a lieu pour les classes anonymes, avec souvent une unique m�thode dedans...

d'accord � priori

d'autres diff�rences � exposer?

[laffreuxthomas]

bah non, ton intervention �tait tr�s bonne et ce d�bat est int�ressant. :o) Ct juste pour �largir un peu le sujet.

en gros
pourquoi avoir proposer c# si on a d�j� java?
1-c# apporte r�ellement de nouvelles fonctionnalit�s. Donc Sun a oubli� des choses dans java qui �taient r�ellement indispensables (sinon pourquoi?) J'attends des r�ponses car apr�s tout c# a tout � fait le droit d'�tre meilleur que java (et la concurrence est b�n�fique)
2-pour r�cup�rer les programmeurs java
3-Ou les deux.

.Net est un projet que Microsoft a commenc� quand il s'est fait virer par Sun de Java (on sait pourquoi). C'est donc une r�ponse � Sun. Il n'est pas franchement innovant, mais il est aussi bien. Moins mature mais avec quelques am�liorations, dans les grandes lignes. Le but est uniquement d'arr�ter de perdre des parts de march�. Comme tu le soulignes, c'est une bonne chose que la concurrence.

plusieurs valeurs en sortie

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
  float res; int ech;
  calcule(out res, out ech, 2, 3);
// ...
  private void calcule(out float resultat, out int echelle, int val1, int val2)
  {
    echelle = 10;
    resultat = (float) val1 * val2 / echelle;
  }

Nommage et accesseurs
En Java :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
    System.out.println(monObjet.getNumero());
  // ...
  public int getNumero() { return numero; }

En C# :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
    Console.WriteLine(monObjet.Numero);
  // ...
  public int Numero { get { return numero; } }

C'est la m�me chose sauf que en C# le compilateur peut v�rifier la syntaxe. Ca ne s'appelle pas un accesseur mais une propri�t�, en C#.

l'impl�mentation de plusieurs interfaces
Ton exemple est bon. Si tu en veut un plus coh�rent, bah imagine que tu cr�es les interfaces de plusieurs �v�nements qui ont chacun une action par d�faut (une m�thode defaultAction(...), par exmple . Enfin c'est vrai que �a ne m'est pas encore arriv�. Mais c'est concevable.

Thomas

[grishka]

En java, tout est pass� par valeur. La seule solution en java pour ton exemple si on veut faire exactement comme en c# :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
  float[] res = new float[1]; int[] ech = new int[1]; 
  calcule(out res, out ech, 2, 3); 
// ... 
  private void calcule(float[] resultat, int[] echelle, int val1, int val2) 
  { 
    echelle[0] = 10; 
    resultat[0] = (float) val1 * val2 / echelle; 
  }

ce qui est moins bien car qui m'empeche de faire echelle[1] = 10?

les classes Float et Integer ne r�solvent rien si je me trompe pas car ce sont des value-object, ie leur valeur est d�finie � l'instanciation. Et comme on peut pas faire echelle = new Integer(10)....

l'impl�mentation de plusieurs interfaces proposant la m�me m�thode
oui � mon avis ca ne doit pas arriver tout les jours alors peut �tre que ca n'est pas vraiment utile surtout si ca permet des trucs d�lirants.

[grishka]

pour en revenir aux pbl des interface �voqu� plus haut :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public interface VehiculeRoulant {
 public avancer();
}
...
public interface Bateau {
 public avancer();
}
...
public class Hovercraft implements VehiculeRoulant, Bateau {
 public avancer() {
 }
}
...............
Hovercraft h = new Hovercraft();
VehiculeRoulant v = h;
Bateau b = h;

->en c#, si je veux, l'ex�cution de v.avancer() peut �tre diff�rente de h.avancer().

Un hovercraft n'avance pas de la m�me facon sur terre et sur l'eau, c'est sur, mais cette distinction ne doit-elle pas �tre g�r�e de mani�re cach�e dans l'impl�mentation de la classe Hovercraft ? L'objet est une boite noire pour l'utilisateur (principe d'abstraction par encapsulation).

Comment on ferait en java?
On peut s'attendre � ce qu'un objet VehiculeRoulant roule et ne flotte pas et inversement pour un objet Bateau. Il suffit d' une entit� qui d�tecte l'environnement dans lequel �volue l'objet Hovercraft et fasse en sorte que les autres objets du mod�le le voient en tant que VehiculeRoulant ou Bateau. Si j'ai une liste de VehiculeRoulant et une liste de Bateau, un hovercraft peut tr�s bien passer de l'une � l'autre quand il change de milieu.

Bref, c# n'apporte pas ici quelquechose qui pourrait �tre r�solu par analyse objet.

[laffreuxthomas]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public interface VehiculeRoulant { void PreparerAAvancer(); } 
public interface VehiculeVolant { void PreparerAAvancer(); } 
 
public class Ovni : VehiculeRoulant, VehiculeVolant { 
  void VehiculeRoulant.PreparerAAvancer() {
    RentrerElice();
    SortirRoues();
  }
  void VehiculeVolant.PreparerAAvancer() {
    RentrerRoues();
    SortirElice();
  }
  private void RentrerRoues() {	Console.WriteLine("RentrerRoues"); }
  private void RentrerElice() {	Console.WriteLine("RentrerElice"); }
  private void SortirRoues() {	Console.WriteLine("SortirRoues"); }
  private void SortirElice() {	Console.WriteLine("SortirElice"); }
} 
 
// ...
 
  private void PiloterVehiculeRoulant(VehiculeRoulant v) {
    v.PreparerAAvancer();
  }
  private void PiloterVehiculeVolant(VehiculeVolant v) {
    v.PreparerAAvancer();
  }
 
// ...
 
    Ovni ovni = new Ovni();
    PiloterVehiculeRoulant(ovni);
    Console.WriteLine("---");
    PiloterVehiculeVolant(ovni);

et voil� ! Et il y a m�me plus fort : on peut aussi d�cider, quand on �crit une m�thode, si elle surcharge ou non celle de la classe m�re. Ca permet d'�viter les fautes de frappes (en Java, une petite faute de frappe et c'est la m�thode de la classe m�re qui est appel�e !). Et �a permet d'�viter les effets de bords si l'on modifie � post�riori la classe m�re sans conna�tre toutes les classes filles.

Mais je suis d'accord, c'est rare d'avoir des conflits de noms.

[laffreuxthomas]

Comment on ferait en java?
On peut s'attendre � ce qu'un objet VehiculeRoulant roule et ne flotte pas et inversement pour un objet Bateau. Il suffit d' une entit� qui d�tecte l'environnement dans lequel

Oui, c'est une fa�on de faire. Mais la solution dans mon post pr�c�dant n'est pas moins objet. Et C# permet de faire les deux.

La fonctionalit� de versions de m�thodes est plut�t sympa. :o)

a+

[laffreuxthomas]

Autre diff�rence : l'instanciation sur la pile
C# r�-utilise le mot-clef "struct" avec un nouveau sens : une structure est une classe dont toutes les instanciations seront faites sur la pile. Ca signifie que :
* le passage d'une instance de structure en param�tre se fait par valeur.
* pas d'allocation dynamique
* interdiction d'affecter 'null' � une variable de type struct

Tr�s pratique pour les petites classes simples. Exemple : Color, Point sont des structures.

Les types built-in
... et par la magie du compilateur, un type 'int' est vu comme une structure. On n'a donc plus la dualit� int / Integer , float / Float, etc..
Exemple :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
      int nb = 2;
      ArrayList lst = new ArrayList();
      lst.Add(nb);
      Console.WriteLine(lst[0] + " " + nb.ToString());

En r�alit� la distinction entre l'entier physique et sa classe est tout de m�me g�r�e par le compilateur. Donc ce code n'est pas plus rapide � l'ex�cution que l'�quivalent en Java. Mais il est vraiment plus simple � �crire !

Synth�se des am�liorations de C# par rapport � Java
Le gros travail de Microsoft a �t� de r�duire au maximum le nombre d'allocations m�moire sur le tas. Les param�tres en sortie, les pointeurs de fonctions pour �v�nements, les structures avec allocation sur la pile, servent � se servir de la pile au maximum. Ce qui donne un avantage intrins�que � dot-Net en mati�re de rapidit� d'ex�cution.

La gestion des versions de m�thodes lors de l'h�ritage permet plut�t de g�rer au mieux les probl�mes de fusions de biblioth�ques.

Tout petit d�faut de c#
Sinon j'ai trouv� un petit d�faut � C# : la visibilit� d'une propri�t� (ie accesseur) est forc�ment la m�me pour un get et un set. Alors qu'on a souvent besoin d'un set protected ou internal (ie package) avec un get public. Dans ce cas on est donc oblig� de revenir � l'ancienne mani�re pour un des deux :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
  internal void SetNom(string nom) { this.nom = nom; }
  public string Nom { get { return nom; } }

Au fait tout ce que je dis est valable pour C#, mais �videmment aussi pour tous les autres langages de dot-Net.

Thomas

[2000]

il me semble que s'il y a des details techniques (je suis plutot �pat� par vos commentaires) la difference reside surtout au niveau economique et politique. par ailleurs, heureusement que C# comporte des ameliorations compar� � Java sinon ou serait son avantage ? Malgr� tout je ne le vois que comme une tentative maladroite de MS d'endiguer l'engouement pour java.

On peut developper de grandes applications en java avec un environnement completement gratuit et de fait � moindre couts. Que ce soit au niveau des IDE (Eclipse), des serveurs Web (Tomcat) ou des serveurs d'applications (JBoss). Et puis il y a la philosophie "write once, run everywhere". Enfin, entre Windows, Office et I.E nous sommes suffisament pieds et poings li�s � Microsoft pour l'�tre encore avec le d�veloppement.

Dans notre equipe nous avons migr� de l'environnement ASP/VB pour java en diminuant nos frais de developpement ce n'est certainement pas pour passer maintenant a la plateforme .Net. Et je peux vous dire que ce genre d'arguments importent bien plus � mon project manager que toutes les ameliorations techniques apport�es par C#.

[neo.51]

On peut developper de grandes applications en java avec un environnement completement gratuit et de fait � moindre couts.

Csharpdevelopp est un IDE C# enti�rement gratuit, et pour ce qui est du choix de la plateforme, le projet go-mono avance � pas de g�ant : on a d�j� tout ce qui est asp.net qui marche avec apache. Je pense que d'ici 1 ans on pourra d�velopper des solution .NET sous linux de mani�re fiable.

[Clement Cunin]

Ce n'est pas parce que ca marche sous apache que c'est portable comme java...
Le C aussi est portable, en principe.... Mais dans la pratique ce n'est pas le cas. Java n'a plus rien a d�montrer dans ce dommaine alors que dotNet n'en est qu'a ces d�buts...

Comment dotNet et le projetgo-mono compte faire pour proposer une interface graphique portable ?
-> Une interface graphique entierement �crite en dotNet, entierement portable... et donc aussi lente que Swing ?
-> Une interface graphique bas� sur une librairi graphique portable... comme SWT (avec les probl�me que l'on connait de gestion m�moire) ?
-> Le portage de l'Api windows sous linux ?
Ou alors le projet go-mono ne vise qu'a porter la plateforme sans de couche graphique (chose dont on a pas besoin pour de l'asp a priori ) ?

Et une fois que ca marchera sous linux, il reste plus qu'a le porter vers MacOs, Solaris, etc ...

[Nightfall]

Les winforms de go-mono sont bas�es sur gtk il me semble.

[neo.51]

Pour ce qui est de la portabilit� de .NET sur linux, je ne dis pas que quand le framework.net sera port� sur linux �a sera du java, je dis que quand .NET sera port� sur linux, l'argument de la portabilit�e en faveur de java ne sera plus valable. Par cons�quent �a ne sert � rien de d�battre en posant des arguments qui seront obsol�tes dans moins d'un ans !

Pour ce qui est du portage de l'interface graphique, c'est en effet le probl�me majeur auquel se heurte le projet mono. Pour l'instant le portage de l'interface graphique se ferait avec GTK#...

Je pense que si DrQ passe dans le coin il pourra surement nous en dire plus.

Il n'emp�che qu'avancer syst�matiquement le fait que java est moins couteux que .NET et que c'est portable sont des argument qui ne sont pas valable !!!

1)Acheter 3 licences windows et 3 licences VS.NET pour un projet qui se chiffre en milliers d'euros, je ne pense pas que l'on puisse parler d'un cout qui p�nalise un projet.
2).NET sera portable dans moins d'un ans au moins sur linux
3)Il existe des outils enti�rement gratuits pour d�velopper en asp.
net, VB.NET ou C#


Alors si on fait un d�bat C# VS JAVA, parlons plutot de rapidit� de d�veloppement, des possibilit�s qu'offre un langage et pas l'autre, du d�ploiement, de la maintenance, enfin bref les vrais argument qui joue en faveur de chacun de ces deux langages !

[Geronimo]

Deux liens int�ressants en rapport avec le sujet :

- Qu'est-ce que C# :
http://msdn.microsoft.com/vstudio/te...sharpintro.asp
- Comparatif C#/Java/C++ : http://genamics.com/developer/csharp_comparative.htm

[okeefe]

Pour ce qui est de la portabilit� de .NET sur linux, je ne dis pas que quand le framework.net sera port� sur linux �a sera du java, je dis que quand .NET sera port� sur linux, l'argument de la portabilit�e en faveur de java ne sera plus valable. Par cons�quent �a ne sert � rien de d�battre en posant des arguments qui seront obsol�tes dans moins d'un ans !

Pour ce qui est du portage de l'interface graphique, c'est en effet le probl�me majeur auquel se heurte le projet mono. Pour l'instant le portage de l'interface graphique se ferait avec GTK#...

Je pense que si DrQ passe dans le coin il pourra surement nous en dire plus.

Il n'emp�che qu'avancer syst�matiquement le fait que java est moins couteux que .NET et que c'est portable sont des argument qui ne sont pas valable !!!

1)Acheter 3 licences windows et 3 licences VS.NET pour un projet qui se chiffre en milliers d'euros, je ne pense pas que l'on puisse parler d'un cout qui p�nalise un projet.
2).NET sera portable dans moins d'un ans au moins sur linux
3)Il existe des outils enti�rement gratuits pour d�velopper en asp.
net, VB.NET ou C#


Alors si on fait un d�bat C# VS JAVA, parlons plutot de rapidit� de d�veloppement, des possibilit�s qu'offre un langage et pas l'autre, du d�ploiement, de la maintenance, enfin bref les vrais argument qui joue en faveur de chacun de ces deux langages !

m�me si mono est l�, je vois pas pourquoi j'irais foutre du ms dans un syst�me linux... on choisie linux par choix, c'est certainement pas pour apporter les bug ms avec nous

[Clement Cunin]

m�me si mono est l�, je vois pas pourquoi j'irais foutre du ms dans un syst�me linux... on choisie linux par choix, c'est certainement pas pour apporter les bug ms avec nous

Attention a ne pas partir sur un troll � 2 euros ...

Le fait est que le code de l'api de dotNet n'est pas ouvert, ce qui est difficilement acceptable par un linuxien

Alors si on fait un d�bat C# VS JAVA, parlons plutot de rapidit� de d�veloppement, des possibilit�s qu'offre un langage et pas l'autre, du d�ploiement, de la maintenance, enfin bref les vrais argument qui joue en faveur de chacun de ces deux langages !

Pour la rapidit� de developpement, c'est pas les langages, mais les IDEs qu'il faut comparer.

Les possibilit�s qu'offre les langages sont equivalente, m$ a fait une copi quasi conforme...

La seule vrai difference, c'est la portabilit� perdu au profit d'une meilleur integration a windows...

[Geronimo]

Cl�ment, tu dis qu'il faudrait comparer la diff�rence des IDE, mais l� encore, cela risque de d�pendre de chaque IDE...
Sur le plan vitesse � l'ex�cution, sais-tu si avec C# on garde le (petit) avantage de la vitesse du C/C++ ? (merci de ne pas troller sur Java + ou - rapide que C++, un d�b�t entier y est consacr�)

[Epict�te]

Sur le plan vitesse � l'ex�cution, sais-tu si avec C# on garde le (petit) avantage de la vitesse du C/C++ ?

Cette question est bien connue, mais elle est mal pos�e, la question est qu'en est il de la rapidit� d'ex�cution du code manag� (.NET, n'importe quel langage, y compris C# ou C++) versus le code non manag� (compilateur natif, C, C++ ou Delphi, ...).

La r�ponse est : Ca d�pend.....

Ca d�pend de ce que fait le code, de la taille du code, de la ram dispo, de la machine, et de plein d'autre choses.

Parfois le code non manag� sera plus rapide, et parfois c'est l'inverse...

Mais de dire que l'un ou l'autre est plus rapide est donc faux, parce que cela d�pend de la situation.

Cependant il est �vident que � terme l'avenir est au code manag�, Java ou .NET au choix, pour pleins de raisons...

[Clement Cunin]

Quand je vois tous les probl�mes qu'on a avec les interfaces graphique en Java... alors que le langage est prevus a la base pour etre portable...

R�ussir a porter les interfaces graphiques 100% windows vers une autre bibliotheque corresponds a mon avis a du suicide... AWT, Swing et SWT de java apporte chaqu'une autant de probl�me que de solution

- AWT utilise les librairie native de chaque OS, donc les fonctions se reduissent au plus petit denominateur commum... c'est a dire, pas grand chose de fonctionnel. Le look est plate forme dependant.
- Swing 100% java, est plus lente que des librairies natives. Le look est independant de l'OS.
- SWT le look est a moitier dependant de l'OS, mais on pert le garbage collector -> retoure des fuites de memoire -> la me-merde quoi !

Alors dire qu'on va faire tout ca avec gtk dans mono ... Lol !

Pour moi, dotNet sera portable quand 90% des application dotNet fonctionnerons aussi bien sur windows que sur Linux, sans modification du code...

[2000]

dire que l'argument de la portabilit� n'est pas valable parce que dans un an si tout se passe bien C# sera portable c'est un peu faire preuve d'optimisme orient� � mon sens. Avancerais-tu cela aujourd'hui pour un projet � entamer comme argument � ton manager pour l'infl�chir en direction de C# ? moi non.

d'accord pour dire que d�volepper des IHM avec Java c'est pas la panac�e. Mais aujourd'hui la force de java est plut�t au niveau du serveur et de l'architecture J2EE et aussi du fait de son universalit� : de l'IHM (un peu lourde d'accord) au serveur d'application � la generation de pages dynamiques, la gestion des transactions de la s�curit� et de l'ensemble des activit� de l'entreprise il n'y a qu'un language : Java.

Et puis d'une mani�re bassement pragmatique : la majorit� des d�veloppements d'applications dans l'industrie sont en Java, la majorit� des postes � pourvoir dans le d�veloppement le sont autour des technologies Java / J2EE (un rapport de 1 � 5 entre C# et Java sur jobserve.com le plus gros site d'emploi anglo-saxon) et maintenant que la plupart des entreprises ont migr� vers cette technologie il me semble qu'il va etre d�licat de les faire migrer de nouveau vers C#.

J'imagine plutot qu'il va y avoir une sorte de paix arm�e entre J2EE et .Net gr�ce aux WebServices.