Discussion :

[pseudocode]

JME/JSE/JEE des frameworks ?
non…, des plate-formes ? oui,
Swing, AWT, WebObjects, JMF, etc. sont des frameworks…

Oui, oui tu as raisons ce sont des plateformes. Voila, ca a grandement fait avancé le débat. (a propos, le framework c'est JFC et non pas swing)

Donc explique précisément en quoi tu trouve par exemple que .Net, Delphi ou autre est "explicitement fait pour simplifier ou faciliter la vie du developpeur" parce que pour l'instant là, c'est du dialogue de sourd.

Parceque ces Frameworks (plateformes, solutions, whatever....) fournissent des Langages (représentations, formats, whatever...) explicitements dédiés aux IHM:
.Net -> XAML
Flash -> MXML
Delphi -> DFM

est-ce qu'il y un intérêt parmi les lecteurs à voir se développer des forums de discussion avec de véritable comparaisons "on the battle field" et non des discussions où s'accumulent les avis subjectifs et les exemples idiots ?

Non. Chaque "fanboy" te dira qu'il peut te faire ce que tu réclame dans SON langage. Et c'est surement vrai... Mais je ne vois pas l'interet de coder un "demineur" en PHP, ou un web-blog en C++

Maintenant ce n'est que mon avis. Si vous voulez comparer "techniquement" les 2 frameworks (plateformes, solutions, whatever....) libre a vous. Listez les API des librairies et comparez le nombre de packages, methodes, ou parametres. Après créez une formule pour calculer une note globale, et affichez le résultat du match:

.NET (>)(=)(<) Java (*)

(*) rayez le symbole inutile

[Deadpool]

.Net -> XAML

Ouais, sauf que XAML n'est pas le pendant XUL de MS. L'idée vient en fait de Java. Erwy l'explique dans ce post : http://www.developpez.net/forums/sho...&postcount=170 et celui-là : http://www.developpez.net/forums/sho...&postcount=192

En plus des implémentation de XUL existent en Java et pas qu'un peu: http://java-source.net/open-source/x...rface-toolkits

Alors je repose ma question, pourquoi Java n'est pas adapté? Parce que tu l'as décidé?

[JeitEmgie]

Non. Chaque "fanboy" te dira qu'il peut te faire ce que tu réclame dans SON langage. Et c'est surement vrai... Mais je ne vois pas l'interet de coder un "demineur" en PHP, ou un web-blog en C++

mais justement il ne s'agirait plus de dire mais de montrer comment…

et bien sûr, il n'est pas question d'applications complètes mais bien de tâches précises mais fréquentes ou qui aboutissent sur un réel "plus" à l'application, à l'utilisateur final, …

cela nécessite évidement un certain recul sur sa propre pratique du développement…

dans cette optique un "démineur" en soi n'est pas un problème intéressant, mais "comment ajouter des effets visuels d'animation et/ou des effets sonores lorsqu'un utilisateur déplace un objet graphique dans une interface" et comparer la problématique dans différents frameworks devient un sujet intéressant de comparaison…

prenons une autre situation assez "classique" :
application desktop qui va être mise en beta test chez des clients sélectionnés, il serait souhaitable d'automatiser les "bug reports" : quand l'application se plante chez un beta testeur, la génération du rapport doit être automatisée, et celui-ci doit être envoyé à un serveur (par POST, par mail, …),
comparaison de comment cela peut-être réalisé dans divers environnements :
quels sont les infos internes au programme qui sont possibles de joindre au rapport (état de variables, stack trace, listes des fichiers ouverts, état des threads, …), est-il possible d'ajouter automatiquement une copie d'écran au moment du plantage, joindre au rapport les fichiers de configuration de l'application propre à l'utilisateur, certaines infos utiles sur son hardware (par exemple si c'est une appli graphique, le modèle de carte et la version des drivers…), etc.

[pseudocode]

En plus des implémentation de XUL existent en Java.
Alors je repose ma question, pourquoi Java n'est pas adapté? Parce que tu l'as décidé?

Tu reponds toi meme a la question. Si Java (le langage) etait tellement bien adapté a la creation d' IHM, pourquoi on aurait le besoin ou meme l'idée d'implementer XUL (un autre langage pour faire des IHM) ?

Et pourquoi Microsoft a créé le langage XAML en plus du C# ?
Et pourquoi Macromedia a créé le langage MXML en plus de ActionScript ?

C'est pas parcequ'on peut tout faire en Java, qu'il faut tout faire en Java.
Idem avec dotNet. Idem avec C++. Idem avec Windev. Idem avec python, etc.


Plutot que de comparer le coté "technique" d'un langage/framework, je préfere m'interesser a sa raison d'etre:
- Pourquoi a-t-il été créé ?
- Quel problème est-il sensé résoudre ?
- Dans quel cas apporte-t-il une réelle valeur ajoutée ?

Pour moi, Java répond a un probleme de portabilité de code "objet" entre differents OS (windows, unix, linux, ...). "Write once, run anywhere".

Et .net répond a un probleme de standardisation d'une librairie "systeme" pour windows entre differents langages (c#, vb, C++, delphi, python, ...).

[lunatix]

ca a pas grand chose a voir avec le débat, mais même si c'est très a la mode en ce moment, je ne suis pas sur que décrire les interfaces en xml plutôt qu'en code soit forcement la panacée ultime (même si ça a des avantages sur certains cotés). ca permet surtout au developpeur web de se retrouver en terrain connu.
Par exemple GWT (google web toolkit) fait exactement le contraire pour generer une interface web.

[JeitEmgie]

Et pourquoi Microsoft a créé le langage XAML en plus du C# ?
Et pourquoi Macromedia a créé le langage MXML en plus de ActionScript ?

comme si tout ce que font les majors était motivé par d'uniques questions d'ordre technique…

[pseudocode]

comme si tout ce que font les majors était motivés par d'uniques questions d'ordre technique…

Effectivement, je doute que la raison soit technique.

Alors pourquoi, a ton avis ?

[Deadpool]

Tu reponds toi meme a la question. Si Java (le langage) etait tellement bien adapté a la creation d' IHM, pourquoi on aurait le besoin ou meme l'idée d'implementer XUL (un autre langage pour faire des IHM) ?

Pourquoi une implémentation de XUL en Java? Et bien tout simplement pour l'ouverture et la portabilité, ce qui tombe bien vu que c'est le but de Java et de XUL. De plus cela offre une alternative supplémentaire à Swing et augmente la richesse et les possibilités de Java. En clair tu as le choix (pas comme VB par exemple). Cela n'a rien à voir avec une prétendue non adaptation de Java aux IHM.

Et pourquoi Microsoft a créé le langage XAML en plus du C# ?
Et pourquoi Macromedia a créé le langage MXML en plus de ActionScript ?

Ben le XAML a priori c'est dans un but de simplification (XML plus simple à appréhender que C# par exemple) parce que XAML ne fait rien de plus à priori (corrigez moi si je me trompe).

C'est pas parcequ'on peut tout faire en Java, qu'il faut tout faire en Java.
Idem avec dotNet. Idem avec C++. Idem avec Windev. Idem avec python, etc.

Ben oui, évidemment, je suis tout à fait d'accord.

Plutot que de comparer le coté "technique" d'un langage/framework, je préfere m'interesser a sa raison d'etre:
- Pourquoi a-t-il été créé ?
- Quel problème est-il sensé résoudre ?
- Dans quel cas apporte-t-il une réelle valeur ajoutée ?

Pour moi, Java répond a un probleme de portabilité de code "objet" entre differents OS (windows, unix, linux, ...). "Write once, run anywhere".

Autre point : Java permet aussi de développer une IHM portable, .NET non (si on met le cas Mono de côté). Donc en un sens Java est plus adapté que .NET pour les IHM, si je suis ta logique, vu qu'il n'y a aucun travail spécial à faire pour cela.

Et .net répond a un probleme de standardisation d'une librairie "systeme" pour windows entre differents langages (c#, vb, C++, delphi, python, ...).

Python peut s'interfacer avec .NET? Je savais pas, cool!

[pseudocode]

Autre point : Java permet aussi de développer une IHM portable, .NET non (si on met le cas Mono de côté). Donc en un sens Java est plus adapté que .NET pour les IHM, si je suis ta logique, vu qu'il n'y a aucun travail spécial à faire pour cela.

Je me repete:
- d'un coté, il y a le "ce qu'on PEUT faire" avec un langage/framework (Java permet de ...)
- de l'autre il y a le "pour quoi" le langage/framework est fait.

Je ne crois pas que les createur de Java se sont dit: "Tiens, on va créer un langage/framework qui permet de faire des IHM portables.". Ca, je pense que c'etait plus l'idée des créateurs de HTML

Maintenant, on peut tout a fait comparer le "ce qu'on PEUT faire" avec Java+JSE , C#+.Net, python+gtk ou Ruby+QT. Mais a mon sens, ca n'a pas d'interet autre que "purement technique".

Je prefere coder dans un langage adapté a mon probleme, plutot que d'adapter mon code selon le langage et le probleme.

(1 ligne de "awk" vaut mieux que 20 lignes de C. avis personnel)

[Deadpool]

Je ne crois pas que les createur de Java se sont dit: "Tiens, on va créer un langage/framework qui permet de faire des IHM portables.". Ca, je pense que c'etait plus l'idée des créateurs de HTML

Et pourtant c'est le cas, notamment en ce qui concerne les Applets quand le Web a commencé à se développer.

Donc oui Java A ETE CONCU pour faire des IHM portables (via les Applets au départ)mais pas seulement, Java est une abstraction de la plateforme cible.

[pseudocode]

Et pourtant c'est le cas, notamment en ce qui concerne les Applets quand le Web a commencé à se développer.

Oui c'est vrai, les applets ont été concus pour etre portable.
Pas super jolies, mais portables

Java est une abstraction de la plateforme cible.

Pour faire mon pinailleur, je dirais que c'est plutot la JVM qui fait une abstraction de la plateforme cible. A ce titre toutes les VM font de meme (meme celle de dotNet).

[Deadpool]

Oui c'est vrai, les applets ont été concus pour etre portable.
Pas super jolies, mais portables

C'est un autre débat.

Pour faire mon pinailleur, je dirais que c'est plutot la JVM qui fait une abstraction de la plateforme cible. A ce titre toutes les VM font de meme (meme celle de dotNet).

Tu as raison, abus de langage de ma part. C'est vrai aussi que la VM de MS fait pareil sauf que dans son cas, on se demande à quoi ça sert. Oui je sais je trolle.

[pseudocode]

Tu as raison, abus de langage de ma part. C'est vrai aussi que la VM de MS fait pareil sauf que dans son cas, on se demande à quoi ça sert. Oui je sais je trolle.

Ca sert a assurer la compatibilité entre XP, Vista et les prochains. Ca leur coute moins cher de réecrire la VM que de réecrire l'implementation des classes !

Java assure la portabilité entre OS.

DotNet assure la portabilité entre Windows.

[Médinoc]

N'oubliez pas non plus que Windows n'est pas limité aux PC : La portabilité est également au niveau du matériel (ce que java fait aussi, évidemment).

[joho]

Ca sert a assurer la compatibilité entre XP, Vista et les prochains. Ca leur coute moins cher de réecrire la VM que de réecrire l'implementation des classes !

Java assure la portabilité entre OS.

DotNet assure la portabilité entre Windows.

et des langages, en DotNET on peut ecrire en plusieurs langage. On compile le tout et ca nous donne du "pseudocode " lisible par la meme CLR . Ecrivez n'importe comment (aka dans n'importe quel langage) executez de la meme maniere (avec la meme CLR).
Ca permet aussi d'executer du code de maniere plus secure . les bugs de memoires ou autres n'affectent que l'espace memoire alloué par la CLR ou la JRE)

[Médinoc]

Tiens, puisque l'on ajoute ce point-là (plusieurs langages sur la même VM, cité dans les atouts de .Net), est-ce qu'il existe des compilateurs autre-langage-que-java ---> Bytecode ?

[Deadpool]

Tiens, puisque l'on ajoute ce point-là (plusieurs langages sur la même VM, cité dans les atouts de .Net), est-ce qu'il existe des compilateurs autre-langage-que-java ---> Bytecode ?

Jython qui permet de compiler Python en bytecode Java.

[joho]

Jython qui permet de compiler Python en bytecode Java.

Pascal
http://pascal.developpez.com/compila.../presentation/
Ruby avec JRuby http://jruby.codehaus.org/

[pseudocode]

Tiens, puisque l'on ajoute ce point-là (plusieurs langages sur la même VM, cité dans les atouts de .Net), est-ce qu'il existe des compilateurs autre-langage-que-java ---> Bytecode ?

Oui. Il y a des barjots qui tentent regulierement l'ecriture de compilateur pour la JVM: Scheme, haskell, fortran, ADA, lisp, ...

Edit: Caml, Eiffel, smalltalk --> encore plus ici

[Médinoc]

Ah, j'en ai trouvé quelques-uns sur Wikipédia:

Originally only one compiler existed, the javac compiler from Sun Microsystems, which compiles Java source code to Java bytecode. But because all the specifications for Java bytecode are available other parties have supplied compilers that produce Java bytecode. E.g.:

• JGNAT, compiles from the Ada programming language to Java bytecode
  <snip>
• Groovy programming language, A scripting language based on java