Discussion :

[CinErarY]

Je tient a spécifier qu'un programme java est portable sur toute les plate-formes car le même .class interprété sur différente plate-forme est interprété par la JVM de la plate-forme. Comme le C# n'utilise pas de machine virtuelle, le code sera portable, mais devra être compilé sur chaque système avant d'être qualifié de portable. Je tient aussi a souligner que go-mono veut implémenter C# pour unix, mais comme l'a si bien spécifié ClémentCunin, il y a bien d'autres plate-formes que windows et unix. Alors, à quand la véritable portabilité de C#?

La portabilité n'est pas un argument car C# sera bientôt portable? Alors, nous pourrions aussi dire que la rapidité non-plus: ne croyez-vous pas que Sun travaille sans-cesse a améliorer la rapidité de ses JVM? Nous ne pouvons argumenter sur ce qui n'existe pas déjà, car nous entrerions dans un autre débat: Microsoft fera-t-il du meilleur travail que Sun durant la prochaine année?

[Traroth]

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.

Quelques questions, à ce propos :

-Quel est le degré de maturité de cet IDE (Csharpdevelopp ) ? Peut-on faire du travail "serieux" avec (càd en entreprise) ?
-Quels sont les impacts de la nouvelle politique de brevet de Microsoft sur ce type d'initiative (en particulier Mono) ? Est-ce que Microsoft est en train de se couper de la communauté Open-Source ? Si oui, je pense que .Net, malgré ses qualités techniques eventuelles (c'est pas moi qui vais trancher ce débat ) n'a pas beaucoup d'avenir face à Java, largement soutenu par le monde Open Source et Libre

[Traroth]

Question un peu annexe au débat : que valent les initiatives "d'intégration" de Java dans .Net de Microsoft, style J# ou JLCA ?
Pour J#, si c'est vraiment un langage .Net à part entiere, je suis etonné qu'un en parle aussi peu. Ca permettrait aux developpeurs Java de se diversifier, le cas echeant, voire de faire une approche "par la bande" de .Net...

[Clement Cunin]

Pour faire une conversion de Java à C#... Le langage en lui meme ne pose pas de problème, a 2-3 mots clé pres c'est la meme chose... Ce qu'il faut réapprendre, c'est l'api dotNet. Donc très peu d'interret dans l'absolu pour J#

voire de faire une approche "par la bande" de .Net...

Je pense pas que la communauté libre soit vraiment sencible a se genre d'arguments...

[Clement Cunin]

JLCA = Java Language Conversion Assistant

Un utilitaire pour convertir un programme java en c#...
http://msdn.microsoft.com/vstudio/downloads/tools/jlca/default.asp

Quelqu'un a-t-il testé la chose ?

[Traroth]

Je pense pas que la communauté libre soit vraiment sencible a se genre d'arguments...

La communauté libre ? La question n'est pas seulment là. Ca peut interesser des professionnels, cherchant à developper leurs competences dans un nouveau domaine, sans avoir à tout réapprendre à zéro, à condition d'etre pleinement fonctionnel. Si J# n'est qu'un gadget, ça n'interessera effectivement personne.
Pour JLCA, la question est différente. Si c'est vraiment efficace (j'avoue etre sceptique...), ça pourrait etre un moyen de diminuer les frais d'un portage de Java vers .Net (j'enfonce une porte ouverte, là, non ? )

[thecat]

c# c'est biens le langage qui à conserver le "virtual" explicite de c++ non ?
Ce fait même devrais le banir des langages objets moderne. Devoir spécifier le mot clef "virtual" est une abération pour un langage objet moderne. Donc le promouvoir est une absurdité.

Cepandant la plateforme .Net à quelques avantages indéniable sur la seule JVM. (le fait de pouvoir utiliser des classes d'autres langages par exemple ....)

Comme le dit des post precedent, penser que .Net pour Linux serra operationel d'ici un ans c'est être trés optimiste ou complètement taré. Les gars qui developpent ca le font, en parti, à coup de reverse engenering, donc pour une stabilité normale de production on repassera. Enfin je ne parle même pas des brevet de Microsoft sur .Net qui est une epée de Damocles sur la tête de chacun.

Bref NON! Il ne faut pas utiliser le langage C#.
Mais je n'ai pas dit de ne pas utiliser .Net, bien que je sois contre son utilisation quand même.

Quand les gars du marketing ne donnerons pas leur avis sur un langage de programation, deja on aurra fait un grand pas.

[Twofy]

Cepandant la plateforme .Net à quelques avantages indéniable sur la seule JVM. (le fait de pouvoir utiliser des classes d'autres langages par exemple ....)

Sans vouloir affirmer quoique ce soit, je crois que la Java Native Interface est faite pour ça : importer du code d'un autre langage. Je me souviens d'un exemple avec du c++... Je ne suis même pas sûr que cela s'appelle JNI...

[thecat]

Avec .Net tu peut hériter de classes qui n'ont pas étaient écrite avec le même langage, et çà, je ne pense pas que cela soit possible avec JNI ...

C'est un trés bon point pour la plateforme .Net, avec le recul on à compris l'interet de l'interoperabilité des langages, mais on à oublié en chemin celui des plateforme !! (Microsoft oblige)

Donc une bonne idée noyé dans une réécriture plus ou moins mal faite de ce qui éxiste déja ..., pas d'autre évolution au niveau langage ... non je ne vois aucun autre interet à utilisé .Net

[Traroth]

Sans vouloir affirmer quoique ce soit, je crois que la Java Native Interface est faite pour ça : importer du code d'un autre langage. Je me souviens d'un exemple avec du c++... Je ne suis même pas sûr que cela s'appelle JNI...

Ca n'est pas vraiment la meme chose. Avec JNI, ton code C ou C++ ne tourne pas dans la machine virtuelle, mais s'execute dans l'OS de ta machine, puis balance ses resultats à ton programme Java, en gros. A l'inverse, comme .Net est une plateforme multilangage, tu peux "mixer" dans une meme application des classes en C#, en C++, en VB, en J#, etc.
Il existe toutefois es approches de ce genre en Java, comme Jython, par exemple.

[Traroth]

C'est un trés bon point pour la plateforme .Net, avec le recul on à compris l'interet de l'interoperabilité des langages

Dans une certaine mesure, oui. Mettons que c'est vrai pour VC#, VB, VC++, VJ# pour les produits Microsoft, ainsi que pour Delphi et eventuellement les tentatives de Cobol .Net, permettant de "recycler" des developpeurs Cobol pour faire du .Net. Mais je ne pense pas qu'on va commencer à developper des applications d'entreprise en Haskel ou en Modula sous pretexte que c'est possible avec .Net. Là, ça ressemble quand meme furieusement à un gadget, meme si c'est interessant, d'un strict point de vue technologique (une curiosité, quoi...)

[thecat]

Ce n'est pas vraiment une curiosité, car on commence enfin à différencier la plateforme (VM + des petits trucs) du langage

On c'est appercu que l'on aurrais jamais un seul langage, mais qu'il fallait qu'il soit interoperable, donc c'est une trés bonne chose.

Comme autre langage tu à EIFFEL avec Eiffel#

Par contre NON, cela ne justifie pas l'utilisation de .Net car il n'avance pas asser pour devoir "s'arreter sur lui" . Mais les futures plateforme devrons s'en inspirer ....

[Traroth]

Oui, c'est à peu près ce que je disais : Technologiquement, c'est un interessant, mais à peu près inutile en entreprise (sauf les cas precedemment cités. D'ailleurs, meme là, on pourrait s'en passer). On peut quand meme signaler que ça introduit une complexité supplémentaire dans les projets informatiques. Quand on prend un projet informatique moderne, on a deja facilement un truc du genre :

-SQL pour la couche stockage de données
-Java/C++/Perl/PHP ou autre pour la couche applicative
-HTML+Javascript pour la couche présentation
-XML pour plein de trucs (des fichiers Ant jusqu'à une couche de présentation XML/XSLT, en passant par de l'EDI...)
-Cobol et/ou Abap pour integrer l'application dans le process de l'entreprise

Ca fait deja beaucoup. Mais si la couche applicative est faite avec plusiseurs langages, ça va pas tarder à devenir ingerable, amha...

[neo.51]

On peut quand meme signaler que ça introduit une complexité supplémentaire dans les projets informatiques.

je ne suis pas tout a fait d'accord avec toi sur ce point car les différents langages sont étroitement liés :

je travaille sur une petite applis de gestion. je code principalement en VB.NET.

Je peux récupérer des classes open source en C# ou en VB.NET et les intégrer sans aucuns problèmes à mon application.
J'ai créé une bibliothèque de fonction que je peux utiliser sur la partie client/serveur de mon applis (en VB.NET) et aussi sur le site qui propose diverse stat et qui est fait en ASP.NET.

C'est là tout l'avantage de l'interopp des langages. Je ne trouve pas que celà amène de la complexité dans un projet informatique, car les différentes couches dont tu parle sont plus étroitement liés avec .NET

[Traroth]

Je peux récupérer des classes open source en C# ou en VB.NET et les intégrer sans aucuns problèmes à mon application.

C'est un avantage qui tourne un peu en rond : s'il n'y avait qu'un langage .Net, on ne ferait de classes Open-Source que dans un seul langage, et ça serait finalement plus simple, non ?

[neo.51]

Je peux récupérer des classes open source en C# ou en VB.NET et les intégrer sans aucuns problèmes à mon application.

C'est un avantage qui tourne un peu en rond : s'il n'y avait qu'un langage .Net, on ne ferait de classes Open-Source que dans un seul langage, et ça serait finalement plus simple, non ?

c'est vrai que d'un autre coté t'as pas tord

Mais l'interet est que quelqu'un qui a fait que du VB6 devient productif en VB.NET en quelques semaine et pareil quelqu'un qui a fait du java ou du C++ avec le C#.

[Tifauv']

J'ai parcouru le débat et il semble qu'il y ait un consensus général qui rejette Swing. Certes c'est pas super rapide, mais l'interface est réellement portable (et belle à mon goût). Si je choisis Java pour mes projets, c'est souvent parce que je souhaite développer une IHM non réservée aux utilisateurs Linux ou Windows. Je n'ai pas envie de devoir passer 2 fois plus de temps à créer deux interfaces, une pour Windows et une pour Linux. Pour moi Swing est donc une bonne solution. Si la même chose est possible en C#, bravo aux développeurs de Mono !

Cela dit, le projet Mono ne pourra arriver à son but car MS a déclaré qu'elle poursuivrait toute implantation libre des APIs sur lesquelles MS a déposé des brevets. On ne poura donc pas avoir in fine les mêmes APIs donc le code ne sera plus vraiment portable.

De plus, qu'on ait un framework sous Linux ne rend pas du code C# portable sous d'autres systèmes. Ce n'est pas parce qu'on pourra exécuter des applis C# sous Linux que le code est portable. Il faut pour cela un bien plus grand nombre de plateformes supportées.

Enfin, au niveau de JNI (utilisation de code écrit dans un autre langage que Java), cela permet d'avoir un moteur ou des fonctions de clacul coûteuses en C/C++ portable et rapide, et une interface d'utilisation en Java portable elle aussi. En effet, comme le code étranger n'est pas exécuté dans la JVM, il garde ses caractéristiques de vitesse notamment.

[Clement Cunin]

Le fait d'avoir plusieurs langages a l'interieur d'un meme projet me semble vraiment un parie a très haut risque... Lors de la phase de conception, ca ne devrait pas possé trop de problème.. 2 developpeurs C#, 1 developpeur VB.net et 1 developpeur cobol.net... plus 1 pour le site en ASP

C'est la phase de maintenance qui risque de devenir beaucoup plus compliqué... et donc beaucoup plus cher... C'est deja pas marrant de faire une trace d'execution, alors si en plus a chaque appel de fonction on change de langage, je souhaite un bon courrage a celui qui devra debuggé ...
D'autant que les 5 developpeurs initiaux qui ne voullait pas apprendre une nouvelle syntaxe ... c'est le gas de la maintenance qui devrat en apprendre 4... Merci microsoft


En Java, comm la fait remarqué Traroth, on a 1 langage... avec on fait :
-> des applications
-> des applets
-> des Jsp
-> des Servlets
-> des applications pour telephone portable
Un seul langage, une seul api, et toutes les bibliotheques existante en 3 click !

L'argument des multiple langage n'en est pas un a mon sens !

et il semble qu'il y ait un consensus général qui rejette Swing.

Non, pas du tout, ce n'etait pas le sens de mes propos... Swing est une bibliothque 100% Java, très bien implementé... et largement assez rapide pour faire des applications, surtout depuis la JVM1.4. Certe, c'est pas encore recommandé pour coder des jeux d'action, d'autre bibliotheque font leur apparition pour cela.

Cela dit, le projet Mono ne pourra arriver à son but car MS a déclaré qu'elle poursuivrait toute implantation libre des APIs sur lesquelles MS a déposé des brevets.

Oh les vilains !

[Traroth]

Swing c'est bien et c'est pas bien : C'est affreusement lent, et c'est quand meme très complexe, au niveau du Framework. Il y a une masse de classes proprement enorme. Bon, on peut tout faire, c'est bien, mais on n'a pas toujours besoin de tout faire, ce qui veut dire que si on a besoin de feire une petite appli avec une fenetre et 3 boutons, il faudrait que ça soit plus simple.
A ce propos, il y a un point qui n'a pas encore été abordé avec Swing : les bugs. Il y en a beaucoup (trop !). J'ai participé à un projet avec Swing il y a quelques temps : simplement en passant du JDK 1.3 au JDK 1.4, plein de petits problèmes ont disparus. Mais ça n'etait pas encore parfait loin de là...
Pour ce qui est des performances, je ne suis pas sûr que Sun ait fait tout ce qui est possible pour les ameliorer (ça n'est qu'une impression, mais parfois ça me parait surréalistement lent)

[thecat]

Oui, Swing est vraiment lent, et même avec les amèliorations faites, il est difficile de récuperer du matériel de plus de 1 ou 2 ans pour lui faire éxécuter une application moyenne.

Le problème vient du fait que Sun voulait une interface identique sur toutes les plateforme. Soit ça serrais joli, mais si on pouvais choisir entre une inteface lourde et lente mais partout identique, et une interface rapide et lègére mais ou les boutons, les scrollbar... soient lègèrement différent, beaucoup choisiraient la deuxieme solution.

C'est deux exemple sont trés extremes mais bon...

Je critique juste le choix trop radical de Sun, ou si vous preferez je trouve qu'ils ont fait un mauvais compromis. Quand on voie une GUI ramer sur un pentium 3, sa fait raler quand meme !

Par contre pour la compléxité, je ne trouve pas que ce soit un endicap. Si tu connait l'API, tu n'a pas de pb, tu fait trés vite ce que tu veut. Si tu ne la connais pas trés bien, il est vrais que tu te retrouve à fouiner dans tous les coins pour avoir la bonne option qui va bien, mais bon, il faut ce qu'il faut non? On ne pourrait pas avoir deux version de Swing: l'une Ligth pour coder rapidement et sans avenir et une réélement compléte.