Discussion :

[zais_ethael]

Effectivement, si ça fonctionnait en VBA, tes applications ne doivent pas être très exigeantes , donc en Java ça devrait le faire.

Maintenant, si c'est pour le plaisir c'est différent. En dépis du fait que je juge le Java meilleur pour la majorité des applications, j'aime bien le C++. Mais pour moi le C++ est un hoby uniquement, je ne me base donc pas sur les mêmes critères et surtout pas la productivité. Evidemment, quand c'est l'amusement qui entre en jeu ces critères sont plus subjectifs et ne dépendent que de toi, idéalement il faudrait donc apprendre les deux langages pour te faire ta propre opinion (mais tu n'as probablement pas que ça à faire ). Je ne dirais que ceci: le cycle d'apprentissage du C++ est plus long que celui du Java, il y a donc le risque d'en être dégouté avant d'avoir fini sa formation. Par contre, je trouve que la plupart des tutos ou livres sur le Java sont plus "hards" sur le départ, ils ne prenent pas vraiment le temps de t'expliquer l'orienté objet (ça ferait un bon sujet de post ça je trouve). Au fait, désolé de te décevoir mais si tu ne connais que le VBA et le C sache que tu ne connais pas l'orienté objet, et non

[Jean-Marc.Bourguet]

Juste un avi supplémentaire (parceque au final je n'avais toujours pas donné mon avis sur la question java versus C++ ).

Java permettra toujours d'obtenir une meilleure productivité

Et tu as des arguments ou bien tu te contentes d'affirmations?

Le seul cas où il est préférable d'utiliser du C++ est quand on ne peut pas faire autrement pour des questions d'optimisation

A commencer par la question d'optimisation des ressources humaines que sont les programmeurs je suppose

tout en sachant qu'il est assez rare de voir les limites des machines actuelles.

Lancer eclipse sur ma machine actuelle (bi xeon, 2 G de mémoire, 4 G de swap) en voulant débugger le programme sur lequel je travaille. Résultat: pas assez de mémoire au bout de je ne sais pas combien de temps. C'est peut-être plutôt une limite de Java ? A moins qu'eclipse soit mal écrit ?

Je ne connais pas ton secteur mais, d'après ce que tu dis, j'ai le sentiment que les applications que tu pourrais développer ne nécéssiteront pas d'optimisation à outrance, je te conseillerais donc d'apprendre le Java.

Les simulations en hydraulique, c'est le genre de chose pour lesquelles on peut vouloir utiliser des petites machines à 128 CPU.

Je ne sais pas ce que lui veut faire, mais le domaine, à priori, c'est un gros consommateur de CPU.

Oui, c'est un avis radical.

J'ai un avis tout aussi radical sur Java: ça produit des logiciels inutilisables. Sur les trois logiciels que j'ai utilisé que je sais écrit en Java, pas un est utilisable pour ce que je veux en faire. Une application web interne qui a été retirée tellement tout le monde se plaignait de sa lenteur, sunstudio qui est tellement lent qu'il est inutilisable et qu'on continue à utiliser workshop même si ce n'est pas supporté et qu'il faut hacker pour cela, eclipse qui se plaint de ne pas avoir assez de mémoire quand je lui indique que je veux debugger le programme sur lequel je travaille. Au moins sunstudio le faisait sans autre problème que sa lenteur.

[epsilon68]

et OpenMP ne pourrait-il pas etre le point decisif pour C++ ?

[Matthieu Brucher]

Java permettra toujours d'obtenir une meilleure productivité (et ce en considérant tous les aspects du cycle de vie d'un logiciel), ce qui facteur le plus important dans le monde de l'entreprise.

Si la productivité est plus importante, Java n'est pas la solution, ce n'estq u'un langage de haut niveau comme le C++. Faut viser plus haut, comme Python.

[Jean-Marc.Bourguet]

Si la productivité est plus importante, Java n'est pas la solution, ce n'estq u'un langage de haut niveau comme le C++. Faut viser plus haut, comme Python.

En quoi Python est-il de plus haut niveau que le C++?

[epsilon68]

... heu OpenMp n'est pas disponible pour python

[Matthieu Brucher]

Le cycle de programmation est raccourci - plus de compilation, d'édition des liens voire de relancer l'application -, le compilateur usuel est basé sur le C, permettant l'intégration native de tout ce qui existe en C/C++, ... C'est en utilisant ce type de langage qu'on se rend compte qu'ils permettent une vision d'un peu plus haut.

... heu OpenMp n'est pas disponible pour python

Eh si, puisque c'est dispo pour le C/C++ !

[Jean-Marc.Bourguet]

Le cycle de programmation est raccourci - plus de compilation, d'édition des liens voire de relancer l'application -, le compilateur usuel est basé sur le C, permettant l'intégration native de tout ce qui existe en C/C++, ... C'est en utilisant ce type de langage qu'on se rend compte qu'ils permettent une vision d'un peu plus haut.

Tu as cela si tu as un interpréteur TCL, ou même un interpréteur Basic, ou même un interpréteur C...

Je ne vois pas en quoi quelles sont les abstractions que Python permet de manipuler que le C++ ne permet pas aussi facilement. L'assembleur est de plus haut niveau que le langage machine parce qu'il permet de s'abstraire de tout le codage. Les langages comme FORTRAN ont permis de s'abstraire de détails de la machine. L'étape d'après a été de permettre aux programmeurs de créer ses propres abstractions: types et modularite (le C++ de ce dernier point de vue est loin d'être excellent mais les idiomes permettant de contourner ses déficiences sont bien connus). L'étape d'après, c'est de pouvoir s'abstraire des types, donc le polymorphisme et le C++ de ce point de vue est bien fourni.

Pour être de plus haut niveau, on peut aller plus loin dans la manipulation des types (comme Aldor le fait par exemple), ou alors passer dans des langages moins généraux mais ne nécessitant pas une description de comment faire mais simplement de ce qui est à faire (lex, yacc pour rester dans le domaine informatique, prolog,...)

Python ne me semble pas être dans une voie ou l'autre. Être interprété et dynamique offre des avantages dont une souplesse certaine (d'un certain point de vue, l'héritage en C++ est essentiellement un moyen de récupérer une partie de la souplesse des langages dynamiques sans perdre la vérification statique des types), mais ça ne change pas le niveau d'abstraction auquel on travaille. Le seul argument en faveur de Python de ce point de vue, c'est la gestion de la mémoire.

[Mat.M]

Mais, tu semble critiquer ma remarque alors que tu donnes toi même son argument maitre. En C++ tu dois faire un effort pour faire un code qui compilera sur plusieurs compilos, en Java non (enfin, en théorie bien sur , mais c'est quand même fort bien respecté). Maintenant si tu me dis "ça n'a aucune importance pour moi" tant mieux pour toi, mais ne viens pas dire que c'est d'une utilité inexistante.

Attention ne pas déformer mes propose je n'ai jamais parlé "d'utilité inexistante"
C'est évident qu'avec Java on n'a pas à recompiler étant donné que la JVM fait abstraction de l'OS

[Luc Hermitte]

Comme d'ailleurs un certain à priori existe certainemnet envers Java sur le forum C++...

Tout à fait

[zais_ethael]

Et tu as des arguments ou bien tu te contentes d'affirmations?

J'ai vraiment envie de me contenter d'affirmations.
Bon, en vrac:
- vision de l'orienté objet beaucoup plus proche du pur concept objet
- immense portabilité (ralala, je sens qu'on va encore me copier coller LE truc ultra rare qui prouve un exemple de non portabilité du java)
- api standard très fournie, les seuls langages qui égalent + ou - le java sur ce point sont le C# et le Delphi. Pour le C++, on peut dire qu'il est vraiment tout en bas de l'échelle, la stl ne contient à peu de choses près que des conteneurs, des streams et... des chaines de caractères ( wow, c'est révolutionnaire).
- edis extrèmement puissants, avec nottament de la rédaction de code automatique et du refactoring comme j'en ai jamais vu dans aucun autre langage. C'est quelque chose de pratiquement impossible à créer en C++, justement parcequ'il n'est pas bien normalisé mais aussi parcequ'il est d'une grande complexité au point de vue syntaxique.
- plus grande facilité de gestion de la mémoire (he oui, fallait bien en venir à ça)
Bon, je t'ai donné mes arguments en faveur de Java, à toi de me donner les tiens en faveur du C++.
Mais avant ça, j'aimerais parler d'un argument que je juge complètement irrecevable et que tu vas surement m'énoncer parcequ'il revient 99% du temps: l'optimisation de la vitesse, le controle de la mémoire et "les GC c'est pô bien". Oui un programme Java c'est plus lent que du C++, c'est indéniable, oui on ne controle pas la mémoire à l'octet près, mais et alors? Le but d'un programmeur n'est pas de créer des programmes les plus rapides possibles, mais de créer des programmes, point. Je le redis, avec les ordinateurs actuels l'optimisation à outrance n'est pas nécessaire, si ce n'est dans quelques domaines bien précis. L'un des seuls arguments que je trouve recevables que j'ai pu apercevoir sur ce forum est la métaprogrammation, mais on peut vraiment pas dire qu'il soit cité souvent.

A commencer par la question d'optimisation des ressources humaines que sont les programmeurs je suppose

Tu déformes ce que je dis, c'est limite du troll

Lancer eclipse sur ma machine actuelle (bi xeon, 2 G de mémoire, 4 G de swap) en voulant débugger le programme sur lequel je travaille. Résultat: pas assez de mémoire au bout de je ne sais pas combien de temps. C'est peut-être plutôt une limite de Java ? A moins qu'eclipse soit mal écrit ?

Chez moi eclipse prend 200 mo, alors je sais vraiment pas comment tu fais pour atteindre les 6 Go.

Je ne sais pas ce que lui veut faire, mais le domaine, à priori, c'est un gros consommateur de CPU.

Mais puisqu'il dit que le VBA lui convient...

[zais_ethael]

Attention ne pas déformer mes propose je n'ai jamais parlé "d'utilité inexistante"
C'est évident qu'avec Java on n'a pas à recompiler étant donné que la JVM fait abstraction de l'OS

Non, je ne parlais pas de ça. Le byte code portable est une fonctionnalité assez utile de java mais pas indispensable selon moi. Quand on veut distribuer un applic pour plusieurs systèmes, il est de toutes façons obligatoire de faire des solutions de déploiement spécifiques ce qui prend bien plus de temps qu'une simple recompilation. Je parlais du langage lui même (le code source) pour lequel aucun compilateur n'est sensé exister si il ne respecte pas la norme stricte.


Pour le cas du Python, je m'en vais commettre un crime impardonable: m'autociter

Java permettra toujours d'obtenir une meilleure productivité (et ce en considérant tous les aspects du cycle de vie d'un logiciel),

Beaucoup considèrent qu'un langage de programmation est plus productif si il est dynamiquement typé. Imaginons que c'est vrai lors de la première écriture du programme (je ne suis pas trop d'accord mais "imaginons"). Je spécifiait bien tout le cycle de vie d'un programme, qui est d'en moyenne une dizaine d'année. Imaginons sortir une nouvelle version tous les deux mois, ça fait 60 versions distinctes. Vous vous imaginez 60 modifications majeures d'un gros projet en python? On ne me fera jamais croire qu'un langage dynamiquement typé est facile à maintenir.

[Luc Hermitte]

(Ne vous sentez pas oblgés de répondre où il y a des smileys, ce sont mes opinions les plus subjectives et trollesques)

a- vision de l'orienté objet beaucoup plus proche du pur concept objet
b- immense portabilité (ralala, je sens qu'on va encore me copier coller LE truc ultra rare qui prouve un exemple de non portabilité du java)
c- api standard très fournie, les seuls langages qui égalent + ou - le java sur ce point sont le C# et le Delphi. Pour le C++, on peut dire qu'il est vraiment tout en bas de l'échelle, la stl ne contient à peu de choses près que des conteneurs, des streams et... des chaines de caractères ( wow, c'est révolutionnaire).
d- edis extrèmement puissants, avec nottament de la rédaction de code automatique et du refactoring comme j'en ai jamais vu dans aucun autre langage. C'est quelque chose de pratiquement impossible à créer en C++, justement parcequ'il n'est pas bien normalisé mais aussi parcequ'il est d'une grande complexité au point de vue syntaxique.
e- plus grande facilité de gestion de la mémoire (he oui, fallait bien en venir à ça)

f- Bon, je t'ai donné mes arguments en faveur de Java, à toi de me donner les tiens en faveur du C++.

g- Mais avant ça, j'aimerais parler d'un argument que je juge complètement irrecevable et que tu vas surement m'énoncer parcequ'il revient 99% du temps: l'optimisation de la vitesse, le controle de la mémoire et "les GC c'est pô bien". Oui un programme Java c'est plus lent que du C++, c'est indéniable, oui on ne controle pas la mémoire à l'octet près, mais et alors? Le but d'un programmeur n'est pas de créer des programmes les plus rapides possibles, mais de créer des programmes, point. Je le redis, avec les ordinateurs actuels l'optimisation à outrance n'est pas nécessaire, si ce n'est dans quelques domaines bien précis.
h- L'un des seuls arguments que je trouve recevables que j'ai pu apercevoir sur ce forum est la métaprogrammation, mais on peut vraiment pas dire qu'il soit cité souvent.

a- Je ne vois pas ce que la soit-disant pureté apporte de plus. Ah oui. void* s'appelle maintenant Object.
C'est une regression en ce qui me concerne.
Et puis, les oeillières ce n'est pas mon truc, ça bride ma productivité.

b- Le terme "portabilité" est un abus de langage. Je vois la JVM comme un pseudo-OS porté sur quantité de processeurs/OS. Après, un programme en java tournera sur un ensemble pas toujours complet de JVM (ce qui est parfaitement normal -- je n'attends pas qu'elles soient toutes exemptes de bugs, ou d'écarts relativement aux spécs)
Faire du portable en C++ est parfaitement possible. Par contre, vu qu'il y a plus de fournisseurs, il y a plus de chances de tomber dans des manques relativement au support du standard. Plus c- qui nous oblige à recourrir à des bibliothèques tierces.
(T'as vu, je n'ai pas parlé de l'expérience passée sur OOo, ni de certaines regressions entres deux versions, ni que demain un nouveau fournisseur un peu trop pressé de partager son produit pouvait apparaitre )

c- Globalement d'accord avec toi.

d- OK pour la richesse/compléxité qui posent des problèmes pour l'analyse. Toutes fois, je préfère toujours un vrai editeur de textes, et du papier, un crayon et une gomme pour faire mes diagrammes.

e- Hum. D'un côté, une gestion non déterministe de la mémoire + le dispose-pattern (->try-finally) pour gérer de façon déterministe les autres ressources.
De l'autre, le RAII pour gérer toutes les ressources de façon déterministe, et uniforme. (mais ce n'est pas ça pour les références cycliques)

Je sais que tout le monde n'est pas d'accord, perso je préfère le RAII -- question d'habitude peut-être ? -- que je trouve plus clair et compact.
Il existe aussi des GC en C++, mais il est vrai qu'il y a des petits problèmes pour une intégration propre en profondeur.

f- Je suis d'accord, ce n'est pas ce qu'il y a de plus pertinent, ni ce qui fait que je n'aime pas le langage Java (je ne parle pas de la VM et autres technos connexes).

g- Cela n'engage que moi
g.1- plus grande richesse, pas de limitations sous prexte que je ne saurais pas me servir de fonctionalités avancées -- N'est-ce pas Stroustrup qui regrettais dans un article que le C++ étais trop guru-friendly ?
g.2- Donc meilleure séparation des sémantiques de valeur et d'entité
g.2bis- surcharge d'opérateur qui vient à point pour les objets customs que l'on veut à sémantique mathématique
g.3- Héritage multiple qui me permet entre autre de définir, nativement, des contrats (sortes d'interfaces qui vérifient en plus pré-/post-conditions et autres invariants)
g.4- Un héritage de réutilisation (privé) qui n'implique pas le LSP (non nécessaire, mais parfois bien pratique)
g.5- J'aimais beaucoup le Prolog et le LISP -- la méta-programmation me rappelle beaucoup ces deux langages.
g.6- Par de voi^Wtype Object parent de toutes choses, on a une vraie généricité qui s'applique à n'importe quoi
g.7- Pas de (fausse-)"pureté" objet imposée.
g.8- Les concepts, dans la famille du duck-typing statique, je sens que cela va être pas mal.
g.9- g2.+g.6 => nos gurus ne sont pas divisés sur la question de comment définir l'opérateur de comparaison nécessaire à certains conteneurs -- comme quoi certains choix ont des conséquences qui ne cessent de me surprendre. (OK, ils seront divisés ailleurs )


i- En + pour Java, tu pouvais parler de l'argent investi dedans, du JIT, de l'introspection.

[Matthieu Brucher]

Pour le cas du Python, je m'en vais commettre un crime impardonable: m'autociter
Beaucoup considèrent qu'un langage de programmation est plus productif si il est dynamiquement typé. Imaginons que c'est vrai lors de la première écriture du programme (je ne suis pas trop d'accord mais "imaginons"). Je spécifiait bien tout le cycle de vie d'un programme, qui est d'en moyenne une dizaine d'année. Imaginons sortir une nouvelle version tous les deux mois, ça fait 60 versions distinctes. Vous vous imaginez 60 modifications majeures d'un gros projet en python? On ne me fera jamais croire qu'un langage dynamiquement typé est facile à maintenir.

Ce n'est pas à cause de cela seulement que je le considère de plus haut niveau.

[Jean-Marc.Bourguet]

J'ai vraiment envie de me contenter d'affirmations.

Je signale si ce n'etait pas clair que mon intervention etait essentiellement due a la portee enorme de ton affirmation.

Bon, en vrac:
- vision de l'orienté objet beaucoup plus proche du pur concept objet

Tu commences bien, par un defaut. Le paroxisme du pur objet chez moi, c'est de devoir heriter d'une classe Math pour pouvoir calculer un sinus (ce que fai(sai)t Eiffel). L'OO, c'est essentiellement une technique de conception qui, comme toutes les techniques de conceptions, a ses limites.

- immense portabilité (ralala, je sens qu'on va encore me copier coller LE truc ultra rare qui prouve un exemple de non portabilité du java)

Write-Once, Debug everywhere, c'est ca? Je me demande pourquoi certains logiciels imposent de tourner avec la JVM qu'ils fournissent.

- api standard très fournie, les seuls langages qui égalent + ou - le java sur ce point sont le C# et le Delphi. Pour le C++, on peut dire qu'il est vraiment tout en bas de l'échelle, la stl ne contient à peu de choses près que des conteneurs, des streams et... des chaines de caractères ( wow, c'est révolutionnaire).

En quoi une API standard (en passant, pour l'interface graphique, le standard c'est AWT, Swing, SWT ou les bindings GTK ou QT?) augmente-t'elle la productivite dans tous les cas. Je rappelle que tu avais ecrit toujours et que c'est toi qui a souligne. Des infrastructures non standards mais mieux adaptees au probleme peuvent etre plus productives. Ces infrastructures existent pour moi en C++.

- edis extrèmement puissants, avec nottament de la rédaction de code automatique et du refactoring comme j'en ai jamais vu dans aucun autre langage. C'est quelque chose de pratiquement impossible à créer en C++, justement parcequ'il n'est pas bien normalisé mais aussi parcequ'il est d'une grande complexité au point de vue syntaxique.

J'ai de tres mauvaises experiences avec les EDI autres qu'Emacs. Jusqu'a present ils m'ont fait perdre plus de temps qu'en gagner: je reviens toujours a Emacs.

- plus grande facilité de gestion de la mémoire (he oui, fallait bien en venir à ça)

Je suis un partisant du GC bien utilise... C'est disponible en C++ (mais on sort a nouveau de la norme actuelle). Et le GC a des limites. Et quand ca convient pas en Java tu n'as plus le choix.

Bon, je t'ai donné mes arguments en faveur de Java, à toi de me donner les tiens en faveur du C++.

J'ai un gros avantage sur toi: je n'ai jamais pretendu que le C++ soit quasiment universellement meilleur que Java. Il me suffit de trouver un cas ou C++ est plus productif que Java pour quelque chose qui ne soit pas fortement dependant des performances.

Pour moi, la programmation est essentiellement l'art d'utiliser et de construire des abstractions.

Pour l'utilisation

Java a un avantage avec sa bibliotheque standard et le GC. Je le concede sans probleme.

C++ a un avantage quand il s'agit d'utiliser des choses existante par ailleurs ayant une interface C, surtout si ces choses continuent a etre maintenue en parallele.

C++ a un avantage avec la surcharge des operateurs qui permet dans certains cas de donner une interface plus naturelle. Sincerement, meme si je ne suis pas contraint par les performance, pour manipuler des matrices je prefere ecrire A = B * C + C que A = B.mult(C).plus(C).

Le RAII est plus confortable a utiliser que des clauses finally.

Globalement, avantage en productivite au C++ car ses avantages sont sur des couts recurrent et l'avantage de Java sur un cout d'initialisation.

Pour la definition,

Java a un systeme de modularisation nettement meilleur que celui du C++; mais je doute qu'il influence beaucoup la productivite.

C++ permet la definition de types ayant une semantique de valeur, ce qui est difficile si pas impossible en Java.

L'heritage multiple permet de combiner les abstractions avec une souplesse que les interface de Java ne permettent pas.

On peut avoir des fonctions libres quand c'est necessaire.

Meme sans parler de la meta-programmation -- que je considere plus comme un gadget qu'autre chose -- les templates offrent une souplesse sans rapport avec ce que permet Java.

L'existance des destructeurs et l'idiome RAII est aussi un avantage pour le C++.

Pour la definition d'abstraction, avantage au C++ egalement.

Total, avantage en general au C++ mais le GC et la bibliotheque standard de Java peuvent dans certains cas faire de Java un meilleur choix.

Mais avant ça, j'aimerais parler d'un argument que je juge complètement irrecevable et que tu vas surement m'énoncer parcequ'il revient 99% du temps: l'optimisation de la vitesse, le controle de la mémoire et "les GC c'est pô bien". Oui un programme Java c'est plus lent que du C++, c'est indéniable, oui on ne controle pas la mémoire à l'octet près, mais et alors? Le but d'un programmeur n'est pas de créer des programmes les plus rapides possibles, mais de créer des programmes, point.
Je le redis, avec les ordinateurs actuels l'optimisation à outrance n'est pas nécessaire, si ce n'est dans quelques domaines bien précis.

J'ai bien l'impression que je suis dans un de ces domaines precis. Nous passons globalement pas mal de temps a chercher a ameliorer la rapidite et la consommation memoire de nos programmes (et oui la consommation memoire n'est pas trop importante... sauf quand son importance fait franchir des seuils: rester en 32 bits ou devoir passer en 64 bits est le premier, ne pas swapper est le second; les deux sont importants pour nos clients; j'ai un collegue qui travaille avec les donnees des clients qui se plaint de ne pas avoir de machine avec plus de 32 G de memoire)

L'un des seuls arguments que je trouve recevables que j'ai pu apercevoir sur ce forum est la métaprogrammation, mais on peut vraiment pas dire qu'il soit cité souvent.

Tu déformes ce que je dis, c'est limite du troll

Je reponds dans le style du message auquel je repond

Chez moi eclipse prend 200 mo, alors je sais vraiment pas comment tu fais pour atteindre les 6 Go.

Je doute qu'eclipse soit capable de lancer different process pour passer outre la limite de 4G par process... Sinon j'ai simplement fait Importer un executable C++, choisi le programme sur lequel je travaille et puis attendu longtemps.

[lunatix]

marrant, vu qu'on en parle ici, je viens de tomber sur un blog why-its-way-better-to-develop-in-java.html
du 23 janvier 2007
(ça appelle pas forcement une réponse hein ! c'est juste drôle de tomber la dessus)

[loufoque]

En fait à bien réfléchir je pense que pour le GUI il est peut-être intéressant de savoir au moins utiliser quelque chose comme GTK+ ou Qt qui sont disponibles dans de nombreux langages et sur de nombreuses plate-formes.
Parce que par exemple, si je sais faire une GUI avec Swing mais que pour une raison x ou y je dois changer de langage (par exemple parce que Java n'existe pas pour la machine ou alors que Java ou Swing demandent trop de ressources), il me faut apprendre un nouveau système.

Dans cette optique j'aurais plutôt tendance alors à choisir GTK+, parce que déjà c'est plus ciblé car uniquement pour faire des GUI, parce que c'est plus portable, plus léger, et que le développement est libre contrairement à celui de Qt qui est réalisé de manière fermée par Trolltech Inc.

Après bien sûr, certains langages peuvent aussi proposer des alternatives intéressantes. Mais ça reste des alternatives, qui sont d'ailleurs propres aux langages.

[zais_ethael]

7a) Java IDEs represent an amazing achievement in development productivity.
7b) C++: Emacs and vi have excellent syntax highlighting.

J'adore , c'est tellement vrai.

[Matthieu Brucher]

En fait à bien réfléchir je pense que pour le GUI il est peut-être intéressant de savoir au moins utiliser quelque chose comme GTK+ ou Qt qui sont disponibles dans de nombreux langages et sur de nombreuses plate-formes.
Parce que par exemple, si je sais faire une GUI avec Swing mais que pour une raison x ou y je dois changer de langage (par exemple parce que Java n'existe pas pour la machine ou alors que Java ou Swing demandent trop de ressources), il me faut apprendre un nouveau système.

Mouais, faudra tout de même réécrire le code pour que ça ait la même gueule...

Dans cette optique j'aurais plutôt tendance alors à choisir GTK+, parce que déjà c'est plus ciblé car uniquement pour faire des GUI, parce que c'est plus portable, plus léger, et que le développement est libre contrairement à celui de Qt qui est réalisé de manière fermée par Trolltech Inc.

c'est même plus orienté Linux que Windows, GTK+, vu la tête de The GIMP, ils peuvent faire des progrès comparé à Trolltech. D'ailleurs, c'est ça qui est bien justement avec Qt : tu peux aider, mais leur besoin d'avoir des clients assure la stabilité de la bibliothèque.

[loufoque]

C'est un troll ?
Depuis quand le fait d'avoir à la tête d'un projet une compagnie qui prend toutes les décisions de conception (ici Trolltech) rend le projet plus stable ?

c'est même plus orienté Linux que Windows, GTK+, vu la tête de The GIMP, ils peuvent faire des progrès comparé à Trolltech.

Le Gimp est une application très particulière.
Cela ne représente aucunement de manière générale les interfaces des applications écrites avec GTK+.