Discussion :

[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...)

[Bluedeep]

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.

Il n'y pas que Cobol. Il existe aussi par exemple un Fortran pour .Net; le but n'est pas tant de recycler les programmeurs dans ce cas, que de recycler des programmes (de modélisation par exemple) trés complexes à développer et surtout à tester, rendant leur redéveloppment totalement illusoire.
D'autant que ces programmes sont souvent écrits par des gens dont l'IT n'est pas la profession.
Par eemple, j'ai eu récemment sous la main un programme modélisant une dynamique de population de plancton à méso-echelle : 50 000 lignes de code d'une seule traite, un vrai chaos, mais qui marche (bien) : je ne voudrais pas imaginer son portage.

[sambarbas]

Raaaah ces inconditionnels de java ! Que des préjugés et des avis critiques !

Pratiquant les 2 depuis leurs débuts, je vote .net !

Compétition positive ! Eh oui Sun s'efforce de rattraper son retard. Sur les dernières versions les annotations, les enum, les generics, ... Et Tomcat (je déborde) qui en v6 utilise les mêmes méthodes .net (annotations) pour définir un service web. Ms aussi avec l'ajout des nullabletypes, manque grave avant la v2 !

Ya encore du boulot !

En java je réclame :
une strucutre dataset ;
surcharge d'opérateur ;
des classes partiels (intéressant lorsqu'il s'agit d'étendre une classe auto-générée sans risque de verrouiller le modèle par un héritage) ;
un switch avec d'autres types ;
Le virtual (fondamental !), Violent de modifier le comportement d'une méthode d'une classe parente sans que celle-ci l'y autorise ! Ah mais ça va Sun l'implémente en 1.5 (ou 1.6)
Les alias, le using, l'arobase pour les caractères d'échappement...

En c# j'exige :
Types exceptions potentielles dans la signature des méthodes
et qu'ils virent le goto !!! ^^

Sur l'environnement, .net est loin devant dsl...
vs2005 (5 instances et ca tourne pépère ! comparé au gargantuesque eclipse)
Débogage inter instance, du bonheur.
Le typage de dataset, le typage des ressources et le typage des paramètres d'application
La gestion des cultures, avec prise en compte qu'un changement de culture c'est des labels, mais également des tailles et des positions.
Extensions du concepteur (smarttags...).
Le must en dev html/js/css... avec un débogage javascript parfait (espions, points d'arrêts, curseurs...).

Documentation .net = xml (petite feuille xslt et hop ! ^^)
Javadoc = html (bof pour de "l'open" )

.....

Une communauté énorme autour de c#, des portages plus aboutis (nant, cruise control, nhibernate...)

.........

Boite noire le framework .net ? go télécharger reflector ! ^^ Par contre c'est sur on pourra pas modifier grand chose :p

................

Plus sérieusement, j'ai tout une pile d'arguments pour .net, mais dans la réalité c'est plus compliqué, les entreprises actuelles ont un legacy java conséquent, et plutôt que d'entretenir un débat stérile (gagné d'avance par dotnet), il vaut mieux chercher des moyens d'améliorer l'interopérabilité entre les 2.

[kedare]

Personellement ... la seul chose qu'il manque a .NET , c'est un portabilité complete , certe il y a mono , mais pour le desktop c'est pas terrible ... il faudrais un SWT-like , et ca serais parfait

[adiGuba]

il faudrais un SWT-like , et ca serais parfait

Il existe bien GTK#...

a++

[Aurazed]

Plus sérieusement, j'ai tout une pile d'arguments pour .net, mais dans la réalité c'est plus compliqué, les entreprises actuelles ont un legacy java conséquent, et plutôt que d'entretenir un débat stérile (gagné d'avance par dotnet), il vaut mieux chercher des moyens d'améliorer l'interopérabilité entre les 2.

Bravo, je ne vois pas quoi dire de plus! Je partage completement ta vision du sujet!

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