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