Discussion :

[kpouer]

puisque tu parles des IDE, Eclipse est un très bon exemple de non efficacité flagrante, mais c'est sans doute encore pas de chance

A part cela, vous avez remarquer comme le ton de cette discussion est semblable a ce qu'il serait si vous parliez politique : c'est limite engueulade et surtout chacun campe sur ses positions. Sauf bien-sûr que dans mon cas, ne pas changer de position est normal, puisque j'ai raison

Oui mais Eclipse n'arrive pas à la cheville d'Intellij Idea
Quand on a essayé ce dernier difficile de revenir a Eclipse ou Netbeans c'est clair

[kisitomomotene]

puisque tu parles des IDE, Eclipse est un très bon exemple de non efficacité flagrante, mais c'est sans doute encore pas de chance

Je ne c pas si je vous ai bien compris. Mais quel inconvénient trouvez vous à Eclipse par rapport à d'autre IDE?
Merci.

[kpouer]

Je ne c pas si je vous ai bien compris. Mais quel inconvénient trouvez vous à Eclipse par rapport à d'autre IDE?
Merci.

Moi je connais pas ses arguments, mais il est indéniable qu'Idea est de loin supérieur au niveau des fonctionnalités, c'est le jour et la nuit. Mais bon quand on en connait aucun mieux vaut se mettre a eclipse c'est moins cher

[epsilon68]

visual studio 6 etait ecrit en c++, les suivant aussi mais en .NET je pense (a confirmer)
Kdevelop est aussi ecrit en C++ et je l'aime particulierement.

Kdevelop est superieur a eclipse ou netbeans.
super reactif, tres puissant ... j'adore


ps: je prefere netbeans a eclipse

[spidermario]

visual studio 6 etait ecrit en c++, les suivant aussi mais en .NET je pense (a confirmer)

Je confirme :
en utilisant bdllscan (un programme qui donne le nom des Dll dont dépend un programme) avec l'exécutable VCExpress.exe, mscoree.dll fait partie du résultat.

Il a donc bien été écrit en .NET.

[epsilon68]

vc6 etait reactif mais a partir de la version 2002 c'est la catastrophe, mais j'utilise la version vc2005 au boulot et on finit par s'habituer a la lenteur, il faut bien avancer dans ses projets a la fin !!!

[souviron34]

Je ne c pas si je vous ai bien compris. Mais quel inconvénient trouvez vous à Eclipse par rapport à d'autre IDE?
Merci.

Comme dis précedemment je ne connais pas arguments originaux, mais les miens principaux sont :

• lourdeur extrême
• démarrage extrêmement lent
• multifenêtrage plus que poussif

en gros, trop d'"extrême" liés à la taile et à la lenteur...

[Luc Hermitte]

Je connais aucun soft vendu a la Fnac qui soit développé en QT ... Et j'imagine que tu es simplement un trolleur car il existe des softs pro écrit en Java.

IIRC, Adobe ont (encore) des produits faits sous QT -- mais ils semblent vouloir s'en éloigner vu leur boulot concurrent -> ASL.

PS: si vous commencez à troller sur en quoi est écrit votre (I)DE, bientôt on va entendre parler de LISP...

[kpouer]

IIRC, Adobe ont (encore) des produits faits sous QT -- mais ils semblent vouloir s'en éloigner vu leur boulot concurrent -> ASL.

PS: si vous commencez à troller sur en quoi est écrit votre (I)DE, bientôt on va entendre parler de LISP...

Je n'ai jamais trollé (du moins pas ici .
Quelqu'un affirme que la preuve que Java c'est naze c'est qu'aucun logiciel vendu en magasin n'est écrit en Java, je dis juste que c'est parfaitement faux. Et je dis même plus, que souvent les IDE Java écrit en Java ont des fonctionnalités bien plus poussées que les IDE pour d'autres langages.
Pour QT, j'avoue je me suis trompé plusieurs d'entre vous ont prouvé qu'il existait des softs en QT vendus a la Fnac. Je ne voulais pas dire d'ailleurs que c'était une preuve que QT était mauvais mais au contraire que ce n'est pas parce qu'on ne vend pas de logiciels l'utilisant que c'est un mauvais produit.

[epsilon68]

pour en revenir au debat,
je n'ai pas encore vu un cas ou le java battait le c++.
pourtant je n'arrete pas de voir partout sur le net que Java etait meme plus rapide que le C++.

que le Java soit plus lisible: oui et non, les programmes ecrits avec Qt sont tres elegants.

que le Java soit plus rapide: je reponds non, j'aimerais qu'on m'aide a comprendre pourquoi je n'arrete pas de le voir sur le net

que le Java soit plus objet: non, ca depends fortement du programmer, mais Java donne plus de facilité (langage plus simple, pas de pointeur)

en consommation memoire: Java explose !!!

et vos experiences a vous ?

[kpouer]

pour en revenir au debat,
je n'ai pas encore vu un cas ou le java battait le c++.
pourtant je n'arrete pas de voir partout sur le net que Java etait meme plus rapide que le C++.

que le Java soit plus lisible: oui et non, les programmes ecrits avec Qt sont tres elegants.

que le Java soit plus rapide: je reponds non, j'aimerais qu'on m'aide a comprendre pourquoi je n'arrete pas de le voir sur le net

que le Java soit plus objet: non, ca depends fortement du programmer, mais Java donne plus de facilité (langage plus simple, pas de pointeur)

en consommation memoire: Java explose !!!

et vos experiences a vous ?

Plus rapide ca dépend probablement des cas, mais c'est vrai que c'est probablement pas les cas les plus courants. Reste que dans une grande majorité de situation ce n'est pas le langage qui fera la différence de vitesse entre 2 programmes.
La consommation mémoire, certainement, mais pas autant qu'on le croit, ca dépend beaucoup de l'efficacité du développeur. Je sais plus qui donnait l'exemple d'un modeleur UML, mais en regardant l'offre dans ce domaine, a part celui qui était cité, les autres occupaient sensiblement la même chose qu'ils soient écrits en Java ou en C++.
Et enfin lorsqu'on parlait d'IDE, il était dit que KDevelop est nettement meilleur qu'Eclipse (en quoi je sais pas, mais c'est possible, j'aime pas trop Eclipse d'ailleurs).
Le problème de KDevelop c'est que si on est sous Windows, on peut s'asseoir dessus. Et c'est donc l'avantage de Java. Quand j'écrit un logiciel en Java, je sais qu'il tournera sous Linux ou Mac OS sans que j'ai a le compiler pour et encore moins le tester.

[epsilon68]

Reste que dans une grande majorité de situation ce n'est pas le langage qui fera la différence de vitesse entre 2 programmes.

entre java et .net non
en java ou .net et C++ si

un language avec VM comparé a un autre compilant du code natif...
qu'on le veuille ou non mais tous mes tests m'ont confirmé que le C++ etait largement plus rapide.

La consommation mémoire, certainement, mais pas autant qu'on le croit, ca dépend beaucoup de l'efficacité du développeur. Je sais plus qui donnait l'exemple d'un modeleur UML, mais en regardant l'offre dans ce domaine, a part celui qui était cité, les autres occupaient sensiblement la même chose qu'ils soient écrits en Java ou en C++.

En general je ne compare pas deux programmes differents mais en general les programmes ecrits en Java ils ont tous la tendance a utiliser beaucoup de memoire...

Le problème de KDevelop c'est que si on est sous Windows, on peut s'asseoir dessus. Et c'est donc l'avantage de Java. Quand j'écrit un logiciel en Java, je sais qu'il tournera sous Linux ou Mac OS sans que j'ai a le compiler pour et encore moins le tester.

Justement, Kdevelop est ecrit en C++/Qt avec les KDElibs.
Avec la version 4 de Qt, ils parlaient de rendre disponible les KDELibs sur toutes les plateformes. KDevelop est (ou sera plus exactement) donc multi-plateforme.

[bountykiller]

Le problème de KDevelop c'est que si on est sous Windows, on peut s'asseoir dessus. Et c'est donc l'avantage de Java. Quand j'écrit un logiciel en Java, je sais qu'il tournera sous Linux ou Mac OS sans que j'ai a le compiler pour et encore moins le tester.

Pour être précis, la raison principale pour laquelle kdevelop n'est pas dispo sous windows est le fait que ce dernier utilise encore la version 3.x de qt, laquelle n'est pas dispo en open source sous windows.
Mais la prochaine version de kdevelop (4.0) utilisera la version 4 de qt, laquelle est dispo en open source sous windows (changement du mode de licence chez trolltech).
Donc la version 4.0 de kdevelop sera également dispo sous windows

[kpouer]

entre java et .net non
en java ou .net et C++ si

un language avec VM comparé a un autre compilant du code natif...
qu'on le veuille ou non mais tous mes tests m'ont confirmé que le C++ etait largement plus rapide.

Je vais te donner un exemple :
dans jEdit (un éditeur GPL en Java), toutes les actions utilisateur sont écrites en beanshell (du java interprété non compilé, 100 fois plus lent que le java normal). Et pourtant c'est imperceptible. Car le temps d'exécution de ce code si lent reste nettement plus rapide que le temps de réaction humain, et du coup on gagne en souplesse sans perdre en vitesse dans la perception de l'utilisateur final. Alors oui bien sur si ces actions étaient programmées en java compilé ca serait encore plus rapide, mais quel intéret finalement si l'utilisateur ne peut pas voir la différence ?
C'est ce que je veux dire, que même si le résultat est effectivement plus rapide il y a bien des cas ou aucune différence ne se fera sentir.
Regarde combien de jeux programment une partie en LUA, que Civilization 4 a quasi tout son moteur de jeu en python par exemple et simplement le moteur graphique et autres parties critiques en C++.
Et finalement question vitesse j'ai toujours ma boutade favorite, un md5 en java (pas jni) est plus rapide que md5sum.

En general je ne compare pas deux programmes differents mais en general les programmes ecrits en Java ils ont tous la tendance a utiliser beaucoup de memoire...

Ben il faut bien comparer pour se faire une idée. Sinon c'est facile de dire que les programmes écrit en C++ bouffent de la mémoire. Suffit de regarder Firefox qui monte facilement a 200 Mo, Yahoo Messenger qui doit en faire 50

Justement, Kdevelop est ecrit en C++/Qt avec les KDElibs.
Avec la version 4 de Qt, ils parlaient de rendre disponible les KDELibs sur toutes les plateformes. KDevelop est (ou sera plus exactement) donc multi-plateforme.

Ya pas eu de versions de Kdevelop plus anciennes ?
Et ca change pas le fait que le jour ou Qt4 sera dispo sous Windows pour le distribuer sous Windows il faudra le compiler spécialement, faire un programme d'install particulier, bref du boulot supplémentaire.

[adiGuba]

Plus rapide ca dépend probablement des cas, mais c'est vrai que c'est probablement pas les cas les plus courants. Reste que dans une grande majorité de situation ce n'est pas le langage qui fera la différence de vitesse entre 2 programmes.

C'est vrai, ce n'est pas le langage en lui même qui fait la différence, mais sa compilation.

Java utilise une JVM et un compilateur JIT qui peut faire des optimisations impossible pour un compilateur natif "standard", car ce dernier ne peut pas bénéficier des informations disponible lors de l'exécution de l'application...

que le Java soit plus objet: non, ca depends fortement du programmer, mais Java donne plus de facilité (langage plus simple, pas de pointeur)

Je dirais plutôt que les deux langages ont une vision très différente de la POO, et incorpore des concepts assez différents...

en consommation memoire: Java explose !!!

Java, ou plus précisément le Garbage Collector alloue la mémoire par bloc, ce qui fait une consommation plus importante que la mémoire réellement utilisé. Mais cela permet en contrepartie cela permet des allocation/libération d'objet bien plus performante (pas de requête système) : Urban performance legends, revisited

un language avec VM comparé a un autre compilant du code natif...
qu'on le veuille ou non mais tous mes tests m'ont confirmé que le C++ etait largement plus rapide.

On aimerais bien les voir ces tests justement ! Parce que sinon c'est dur de vérifier tes dire... Je ne te met en doute, mais pourquoi devrait-on te croire sur parole sans rien connaitre de tes tests ?

a++

[epsilon68]

On aimerais bien les voir ces tests justement ! Parce que sinon c'est dur de vérifier tes dire... Je ne te met en doute, mais pourquoi devrait-on te croire sur parole sans rien connaitre de tes tests ?

C'est vrai tu as raison, j'aimerais partager les sources de mon engine mais je crains qu'il soit utilisé a des fins commerciales. As-tu quelques solides arguments pour me convaincre ?

Je suis convaincu par Java mais mon engine me dit le contraire. et je crains fortement que la seule reponse que je vais avoir du partage de mes sources est simplement: oui mais Java n'est pas encore adapté au domaine d'application.

As-tu toi-meme fait quelques applis en Java et en C++ qui font exactement la meme chose pour comparer la vitesse des deux ?

[epsilon68]

Java, ou plus précisément le Garbage Collector alloue la mémoire par bloc, ce qui fait une consommation plus importante que la mémoire réellement utilisé. Mais cela permet en contrepartie cela permet des allocation/libération d'objet bien plus performante (pas de requête système)

Qu'est ce qui empecherait le systeme de faire pareil ? On peut aussi faire ce type d'allocation a l'interieur du programme, avec la strategie adaptée pour le cas

[epsilon68]

Java utilise une JVM et un compilateur JIT qui peut faire des optimisations impossible pour un compilateur natif "standard", car ce dernier ne peut pas bénéficier des informations disponible lors de l'exécution de l'application...

un programme compilé peut aussi faire des cas si il y a tel ou tel materiel disponible a l'execution. Les libs que tu utilises peuvent aussi etre faites dans cette optique. Je ne pense vraiment pas que ce soit un argument pour Java.

[bafman]

Java, ou plus précisément le Garbage Collector alloue la mémoire par bloc, ce qui fait une consommation plus importante que la mémoire réellement utilisé. Mais cela permet en contrepartie cela permet des allocation/libération d'objet bien plus performante (pas de requête système) : Urban performance legends, revisited

nous aussi, on fait ca au boulot, mais en C++ et avec un cout memoire nettement inferieur à celui de Java

[adiGuba]

Je suis convaincu par Java mais mon engine me dit le contraire. et je crains fortement que la seule reponse que je vais avoir du partage de mes sources est simplement: oui mais Java n'est pas encore adapté au domaine d'application.

Ou alors tu ne maitrises pas Java aussi bien que le C+++... Les deux langages sont très différents et un code optimisé en C++ n'est pas forcément le même en Java...

As-tu toi-meme fait quelques applis en Java et en C++ qui font exactement la meme chose pour comparer la vitesse des deux ?

Non, car personnellement c'est C++ que je ne maitrise pas

Par contre j'avais fait quelques tests comparant du code Java exécuté avec une JVM ou compilé en natif (avec GCJ et Excelsior JET) et la JVM n'avait pas à rougir de la comparaison. Au contraire la JVM server se plaçait souvent en première position : La machine virtuelle Java est-elle vraiment lente ?

En effet la JVM est donné comme la principale cause des "lenteurs" de Java, et je trouvais cela intéressants de démontrer que ce n'était pas forcément vrai...

Qu'est ce qui empecherait le systeme de faire pareil ? On peut aussi faire ce type d'allocation a l'interieur du programme, avec la strategie adaptée pour le cas

Ce qui est "lourd" c'est l'allocation/désallocation auprès du système justement, et la solution c'est d'utiliser un GC (bien sûr il est possible d'en utiliser en C++ aussi).

un programme compilé peut aussi faire des cas si il y a tel ou tel materiel disponible a l'execution. Les libs que tu utilises peuvent aussi etre faites dans cette optique. Je ne pense vraiment pas que ce soit un argument pour Java.

Un exemple : l'inlining de méthode.

Avec un compilateur standard, les méthode sont "inliné" à la compilation. A l'inverse, le compilateur JIT "inline" les méthodes à l'exécution.

L'intérêt c'est que le JIT peut inliné des méthodes qui ne doivent pas l'être, car il peut toujours revenir en arrière plus tard en recompilant le code...

Prenons le cas d'une méthode virtuelle : elle ne peut pas être inlinée par un compilateur classique, car la méthode pourrait être redéfini dans une classe fille. Mais le JIT peut très bien faire cela


Pour moi le principal défaut de Java est son temps de chargement, relativement long par apport à une application native, mais dont la différence se fait surtout sentir sur de petit utilitaire en ligne de commande...

nous aussi, on fait ca au boulot, mais en C++ et avec un cout memoire nettement inferieur à celui de Java

Vous allouez moins de mémoire... Ok !
Mais perso je préfère carrément ne pas m'en occuper et laisser le GC gérer tout ca. Et si j'ai des besoins spécifiques je peux toujours le tuner pour modifier son comportement

a++


a++