Discussion :

[sambarbas]

pourquoi c# est un mauvais langage objet .... rapidement:
C# conserve le mot clef "virtual" qui est une abérration pour un langage objet moderne, qui est en plus basé sur une VM ... Cette scorie est tellement enorme que cela descend le langage et ses concepteur: soit ceux qui ont fait le langage ne comprennent rien à l'objet et ont fait n'importe quoi (peu probable) soit c'est le marketing qui à dit au développeurs de faire un langage "comme C++" (qui lui était déja un trés mauvais langage objet, mais il pouvait ce defendre dans l'esprit par lequel il se voyait: tous sacrifier pour une execution rapide.). C# est basé sur une VM, donc conserver toute les disgrétion de C++ est nul.

Il y à d'autre exemple (mais je ne pourrais tous les expliquer précisement et rapidement) mais rien que celui-ci fait qu'il ne faut pas promouvoir ce langage.
Java avait à l'époque fait un grand pas avec son (preque)tout référence, son garbage collector, ses interfaces, sont typage statique .... il à amener quelque chose de plus qu'il fallait conserver. C#, pour un nouveau langage, reprend les défaut les plus criticable de ses prédécesseur ... pourquoi alors l'utiliser ?

Oulah ! faut faire un peu attention à ce qu'on dit parfois... J'avais zappé ce morceau de choix. Pour coder régulièrement dans les 2 langages, je me dis souvent l'inverse. Java n'est pas un bon langage objet.

Si tu parles du mot clé virtual, ne pas l'implémenter me parait une abération complète. De même pour override bien sur. Je n'arrive pas à comprendre ce choix, cad la possibilité d'étendre, voire même modifier le comportement d'une méthode parente sans qu'elle soit autorisée ni même déclarée. Je serai une classe je crierai au viol !

D'ailleurs il me semble que ce genre de comportement a été ajouté en 1.6, à confirmer mais dans ce cas thecat revoit ton point de vue sur le sujet

[adiGuba]

Si tu parles du mot clé virtual, ne pas l'implémenter me parait une abération complète. De même pour override bien sur. Je n'arrive pas à comprendre ce choix, cad la possibilité d'étendre, voire même modifier le comportement d'une méthode parente sans qu'elle soit autorisée ni même déclarée. Je serai une classe je crierai au viol !

En Java toutes les méthodes sont virtual (sauf les méthodes private), et il est possible d'empêcher toutes redéfinitions en utilisant le mot clef final. Perso je ne vois pas vraiment l'intérêt du mot-clef virtual...

La principale différence à mes yeux c'est qu'en C++ il est possible de déclarer dans une classe fille une méthode avec la même signature qu'une des méthodes de la classe parente, sans qu'elle ne la redéfinisse (lorsqu'elle n'est pas virtuel) : les deux méthodes sont totalement distinctes bien qu'elles aient le même nom et les mêmes paramètres...

D'ailleurs il me semble que ce genre de comportement a été ajouté en 1.6, à confirmer mais dans ce cas thecat revoit ton point de vue sur le sujet

Le final est présent depuis toujours... mais tu veux peut-être parler de l'annotation @Override qui est apparut avec Java 5.0 pour "signaler" les redéfinitions de méthode ?

a++

[Deadpool]

La principale différence à mes yeux c'est qu'en C++ il est possible de déclarer dans une classe fille une méthode avec la même signature qu'une des méthodes de la classe parente, sans qu'elle ne la redéfinisse (lorsqu'elle n'est pas virtuel) : les deux méthodes sont totalement distinctes bien qu'elles aient le même nom et les mêmes paramètres...

Par contre, tu fais ça en C#, ça compile mais ça balance un warning.

[sambarbas]

Par contre, tu fais ça en C#, ça compile mais ça balance un warning.

Oui comme en delphi

[davcha]

En Java toutes les méthodes sont virtual (sauf les méthodes private), et il est possible d'empêcher toutes redéfinitions en utilisant le mot clef final. Perso je ne vois pas vraiment l'intérêt du mot-clef virtual...

Franchement, c'est pareil.

Entre java où tout est virtual, sauf si tu précises final ou c# où tout est "final" sauf si tu précises virtual....

voilà quoi...

La seule différence est philosophique.

[adiGuba]

Franchement, c'est pareil.

Entre java où tout est virtual, sauf si tu précises final ou c# où tout est "final" sauf si tu précises virtual....

Oui c'est bien ce que je dis. Je répondais à sambarbas qui critiquait l'absence du mot-clé virtual en Java...

Perso la seule chose qui me chiffonne c'est de pouvoir définir une méthode avec la même signature qu'une méthode non-virtuelle de la classe parente, sans que ce soit une redéfinition. Mais puisque C# affiche un warning c'est déjà bien moins gênant

Après comme tu le dis c'est plutôt philosophique et cela révèle une approche un peu différente de la POO... mais on final on retrouve les mêmes mécanismes !

a++

[Akanath]

J'ai entendu dire que Microsoft serait interessé de racheter Adobe et aussi d'incorporer des nouvelles technologies qui remplaceront le Flash, et il y aura la possibilité de tout faire sous dotnet....

L'avantage de Microsoft .NET, c'est la societé MICROSOFT qui est perène...à savoir si tout celà est légitime... débat à suivre

[rberthou]

L'avantage de Microsoft .NET, c'est la societé MICROSOFT qui est perène...à savoir si tout celà est légitime... débat à suivre

Microsoft est bien une societé perène mais cela ne l'empèche pas d'enterrer plusieur de ces anciens choix technologique ( VBX, J++, VB, DCOM, ..)

[Keihilin]

J'ai entendu dire que Microsoft serait interessé de racheter Adobe et aussi d'incorporer des nouvelles technologies qui remplaceront le Flash, et il y aura la possibilité de tout faire sous dotnet...

Microsoft ne compte pas racheter Adobe...Il y a confusion avec la sortie de SilverLight qui est une technologie concurrente de Flash.

[Garulfo]

Sans vouloir briser votre élan à tous, vous rendez vous compte à quel point un tel sujet est forcément stérile ?

Que ce soit C++/Java, C#/Java, C++/C# ou encore Goldorak/Albator, aucun n'est meilleur... C'est comme de poser la question Français vs Anglais.

La question est : dans tel contexte, en ayant ces ressources, quel langage devrait être choisi...

Alors ça pourrait s'appeler plutôt élément de comparaison entre Java et C#, mais là, la plupart s'évertue à essayer de montrer que le langage qu'ils connaissent bien parce qu'ils développent la dedans, ou l'ont découvert en premier est le meilleur -_- Je ne dis pas qu'aucun élément de cette discussion n'est intéressante, mais bon c'est un peu perdu dans toute cette incroyable volonté de croire qu'il ne peut exister qu'un seul bon langage.

[Jedai]

L'article cité par Sieldev est d'une faiblesse affligeante, en gros il dit sans jamais entrer dans les détails que C# sait faire plus de chose que Java ou rend certaines choses plus facile qu'en Java et que donc il est moins bien (parce que soi-disant ça inciterait les programmeurs C# à coder comme des porcs... j'ai personnellement déjà lu des programmes en Java codés par des membres de la famille porcine, c'est pas beau à voir non plus). Certaines des critiques peuvent être pertinentes dans un certain contexte mais l'exposé est vraiment creux...
La seule critique que je retiens c'est celle des risques dû aux brevets de Microsoft, là encore pas assez développée par l'article.

Bref, quoi qu'il en soit cet article n'apporte rien, inutile de le lire si vous cherchez un avis constructif dans ce débat.

--
Jedaï

[Garulfo]

L'article cité par Sieldev est d'une faiblesse affligeante,[...]
--
Jedaï

Je confirme. C'est un peu une illustration de ce que je dis dans mon précédent message -_- Sa remarque sur les goto semblent dire qu'on ne peut que faire des goto en C#. Celle sur la surcharge d'opérateur est très douteuse. La discussion est loin d'être achevée et c'est son avis (que je partage partiellement cependant).

En gros, c'est assez nul oui

[sinok]

ET puis l'air de rien çà date un chouïa quand même, si tu ressort ce que faisait java à l'époque (même si un grand nombre d'entreprises en sont encore à cette version)

[jerome.fortias]

Au risque de me facher avec les anti-MS (quoi cela n'existe pas) aprés avoir fait et du Java et du C# voila mon petit point de vue de petit chef de petits projets avec de petites équipes.

Sur les aspects clients, portails, pocket PC, je préfère largement C#, qui est plus productif et moins verbeux que Java. Les outils de développement tels que Visual Studio, y compris la version gratuite Express, ou SharpDevelop (gratuit), ainsi que des clients Subversions ou l'utilisation d'outils UML compatible tel que StarUML permette de disposer du meilleur du gratuit et du payant. Le framework .net 3.5 est au passage une merveille et des outils comme MS Workflow Foundation mérite un vrai détour.

Intervenant dans un environnement SAP, là aussi je préfère C# alors même que Java était plus présent des 2002 dessus.

La forcee de C# et de .net c'est que c'est moins confusant, le choix d'outils externes d'haricots étant plus faible et l'offre étant superbe, tels que DUndas pour les charts, ou encore GridEx de Janus... Ce sont tous ces éléments qui font que je préfère C# nettement à Java ou la quantité d'outils fait qu'on se noit trop dans la technique en oubliant l'objectif premier de notre activité : FACTURER et avoir un client heureux.

Par contre dans le domaine du bancaire, de l'assurance côté serveur d'application, là je préfère JAVA qui même si la machine virtuelle est moins performante permet de disposer d'outils particulièrement matures pour des mapping de l'intégration et pour avoir une approche SOA efficace et multi-systemes.

En final, le top c'est l'interopérabilité .net Java...(jusqu'à avoir Eclipse comme EDI sur les compilos MS .net)....

L'article cité en page précédente est plus qu'affligeant...C'est consternant quoiques cela est peu respectueux des sternes....

[npuzin]

Je rentrerai pas dans les querelles d'experts entre la syntaxe du C# et celle du Java, pour moi cela reste de la POO et la petite facilité de langage par ci par la n'est pas un élément de choix stratégique.

Je vous ferez juste part de mon expérience sur ce que je connais tres bien le: .NET avec C#.

Nous avons développé pendant 3 ans à 5 développeurs un ERP complexe en .NET.

Nous avons longuement hésité entre Java et .NET il y a 3 ans, et nous avons consulté 3 consultants extérieurs pour nous aider (qui n'ont pas forcément étaient très impartials puisque je pense qu'ils nous ont préconisé ce qu'ils connaissaient le mieux).

Nous avons choisi .NET principalement car nous avions des interfaces complexes a developper et que nos utilisateurs font beaucoup de saisie et ils veulent qqchose d'ultra rapide.

Il y a 3 ans déjà et ça n'a pas tellement changé, java n'était pas réputé pour sa rapidité au niveau des interfaces, ni pour sa facilité de développement d'interfaces.

C'est pour cette raison que la balance a penché en faveur du .NET.

[jerome.fortias]

Bonjour à tous

Sans vouloir briser votre élan à tous, vous rendez vous compte à quel point un tel sujet est forcément stérile ?

Bien sur qu'il est impossible et illusoire de penser que le sujet c# vs Java va être tranché. Par contre je trouve cette discussion absolument pas stérile, tant certains argumentaires, certaines perceptions sont intéressantes, et interpélent. Si un sujet, même trollesque, amène des argumentaires et même des ressentis, je trouve cela trés constructif

Bien à vous

[kedare]

Pensez vous que le projet mono est assez mature pour commencer a developper serieusement des applications DotNet sous linux ? au niveau de la GUI notament ? qu'en est-il de la portabitilié ? une application GTK# Fonctionnera bien sous windows ?
car personellement je prefere la syntax de C# et l'api DotNet que celle de java
merci

[sebastien.hebert]

Je pense que l'un comme l'autre ont leurs avantages et leurs inconvénients.

Pour des applications de types "Desktop", là où les interfaces graphiques sont importantes, le mieux est C# (plus simple, plus rapide et plus léger). Le projet Mono permet en effet de faire fonctionner des applications Windows .NET sur Linux tant qu'on n'utilise pas de brique spécifique à Windows - je crois qu'il existe notamment un outil livré avec Mono qui permet de vérifier la compatibilité.

Lorsqu'il s'agit d'applications Web, ça se complique. Perso, je trouve ASP.NET plus simple mais je dois reconnaître que JSF (le pendant d'ASP.NET côté Java) a fait d'énormes progrès. Néanmoins, je pense que Java est une meilleure solution dans ce cas car on ne dépend pas de IIS - on a le choix des serveurs applicatifs - et à mon sens IIS est beaucoup moins stable qu'un serveur Glassfish ou WebSphere.

Enfin, j'apprécie le côté serveur de Java plus mature que C# (EJB3 / Spring, frameworks de persistance éprouvés, gestion transactionnelle distribuée, etc.)

Au final, pourquoi ne pas utiliser C# pour développer côté client et Java côté serveur en faisant communiquer le tout via des services Web - surtout avec les progrès réalisés concernant l'interopérabilité grâce à ces technologies (cf. projet Metro).

Il y a 4 ans, je suis intervenu sur un projet client/serveur. Le choix s'était porté naturellement sur C# étant donné l'importance de la partie IHM, etc. Mais nous nous sommes heurtés à des problèmes de montée en charge et de stabilité pour la partie serveur (initialement développée sous la forme de services Web sous IIS). Nous avons alors remplacé la partie serveur par Java à savoir des EJB sessions exposés sous la forme de services Web. De ce fait, nous avons pu bénéficier des possibilités de montée en charge, de stabilité et de la gestion transactionnelle (qui est loin d'être aussi avancée côté C#).

[eclesia]

Pour des applications de types "Desktop", là où les interfaces graphiques sont importantes, le mieux est C# (plus simple, plus rapide et plus léger). Le projet Mono permet en effet de faire fonctionner des applications Windows .NET sur Linux tant qu'on n'utilise pas de brique spécifique à Windows - je crois qu'il existe notamment un outil livré avec Mono qui permet de vérifier la compatibilité.

Lorsqu'il s'agit d'applications Web, ça se complique. Perso, je trouve ASP.NET plus simple mais je dois reconnaître que JSF (le pendant d'ASP.NET côté Java) a fait d'énormes progrès. Néanmoins, je pense que Java est une meilleure solution dans ce cas car on ne dépend pas de IIS - on a le choix des serveurs applicatifs - et à mon sens IIS est beaucoup moins stable qu'un serveur Glassfish ou WebSphere.

Enfin, j'apprécie le côté serveur de Java plus mature que C# (EJB3 / Spring, frameworks de persistance éprouvés, gestion transactionnelle distribuée, etc.)

Au final, pourquoi ne pas utiliser C# pour développer côté client et Java côté serveur en faisant communiquer le tout via des services Web - surtout avec les progrès réalisés concernant l'interopérabilité grâce à ces technologies (cf. projet Metro).

J'ai une question : Pourquoi tout le monde pense que Java c'est du Web avant d'etre du Desktop ?
Je sais qu'a l'origine il n'y avait qu'une partie web mais ca remonte tres loin maintenant. La partie Deskop de Java existe depuis belle lurette et cela avant l'arrivée de C# .

Java est partout, des cartes a puces(JavaCard) aux microcontroleurs(JavaMok) aux telephones et systeme embarqué(JME) aux appli web/desktop(J2SE,J2EE) et aussi sur les clusters(FishFarm et autre).

Personnellement je ne fais que du Desktop Java et cette fameuse stabilité web dont tu parle existe aussi en desktop.

quand a ca "le mieux est C# (plus simple, plus rapide et plus léger)". ce n'est pas objectif comme affirmation

[sebastien.hebert]

Je suis d'accord pour dire que la partie Desktop de Java existe bien et ce depuis plus longtemps qu'avec C# (normal, ce dernier est plus récent !) mais personnellement, je trouve qu'il est plus difficile de faire des applications Java/Swing qui soit plus simp)le/rapide/légère qu'avec C#.

Je n'ai pas dit que Java Desktop est moins stable - tu déformes mes propos - j'ai dit que la partie Web .NET ne l'était pas --> ce n'est pas pareil. Relis bien avant de citer les gens

Pour terminer sur ce dernier point, je suis entièrement d'accord avec toi, la partie Desktop de Java est tout-à-fait stable.

Pour finir, tu dis que mes affirmations ne sont pas objectives. C'est vrai, je croyais juste ici pouvoir émettre un ressenti compte-tenu de mes expériences sur ces deux technologies. Visiblement, ce n'est pas le cas, et c'est dommage...