C'est rigolo, je croyais que le java était un langage facile est efficace.
Je pense qu'aucun langage de programmation n'est "facile". Java est conçu pour être simple (et pas facile), ça n'empêche pas que chaque langage a ses propres idiomes et qu'il est insensé de transcrire naïvement le code sans tenir compte des propriétés du système (en l'occurrence la JVM).
Il faudrait que tu montres le code pour qu'on puisse te dire ce que tu fais mal, car c'est clair qu'il y a un problème vu les différences que tu trouves entre Java et C. Mais en réalité, c'est pas très important, comme il a été dit plusieurs fois, il y a plein de benchmarks bien faits sur le Web qui montrent que Java n'a pas à rougir niveau perfs.
C'est une question de compromis entre le niveau d'abstraction et la performance du code. Dans le monde réel, le compromis proposé par la JVM est intéressant et c'est pour ça que tout le monde, en dehors de Microsoft, utilise Java.
Java est présent dans des applications où il devrait à avoir du C (ou équivalent). Python et ruby non.
Non. Java a remplacé C++ qui est un enfer à maintenir et à programmer, et je dis ça en tant qu'ancien fan de C++ qui a vu la lumière et qui s'est reconverti. C++ c'est un jouet fun mais ça fait plus de mal que de bien.
Non, j'avoue, je n'ai rien codé d'aussi complexe. Et tant mieux, je n'ai pas la prétention de pouvoir le faire.
Donc, si je suis bien ton discours, tu dis "les applications complexes devraient être programmées sans GC", à quoi je réponds "ça va pas, c'est justement là qu'il est le plus utile" et tu me dis qu'en fait tu ne sais pas de quoi tu parles ;). Et bien je te dis, prenons par exemple le cas d'Eclipse vu que tu l'as utilisé comme IDE. Eclipse c'est des millions de ligne de code si tu prends que les projets de l'Eclipse Foundation (sur eclipse.org), sans compter les très nombreux projets extérieurs. Et dans un langage bien plus expressif que C.
Dans un tel système, s'assurer qu'il n'y a pas de memory leak, c'est difficile. Le garbage collector aide énormément.
Mais pas seulement pour ça. Au niveau des propriétés même du langage, c'est pratique d'avoir un garbage collector car ça te permet de savoir que si tu as une référence sur un objet, il existe. Dans un contexte de mémoire partagée (en multithread), et même si c'est bien d'éviter ça en général parfois on n'a pas le choix, c'est hyper pratique.
En C ou en C++, tu peux te retrouver avec la main sur un pointeur qui pointe dans le vide. T'es donc obligé, dès que t'as un pool de mémoire partagée, de créer toi même une abstraction sur tes pointeurs (en l'occurence, on utilise boost). Le garbage collector simplifie la vie de tous les programmeurs et l'overhead est minime comparé aux avantages. Encore une fois, c'est un compromis qu'on fait parce qu'il est impossible d'avoir uniquement des développeurs qui maîtrisent non seulement le langage, mais aussi la façon précise dont fonctionne l'application : en C/C++, une bonne partie du code, c'est pas du métier, c'est juste comment tu vas utiliser ton application. Heureusement y'a des frameworks / libs mais ils vont moins loin que ce qui existe en Java ou en .NET.
Uniquement ? Par certain ça... J'essayerais bien de tout virer (et de comparer avec la vitesse de lancement de nano, pour faire du comparatif de qualité).
Donc cette fois, tu veux comparer la durée de lancement d'un programme ncurse avec le lancement d'un programme graphique ?
Encore une fois, et j'ai l'impression que tu refuses d'entendre ça... je ne dis pas que Java ou la JVM est plus rapide ou aussi rapide qu'une application C/C++. Je dis qu'elle est *suffisamment* rapide (et à vrai dire, pas loin de C++), et que si tu as un PC antique c'est le PC qu'il faut changer, pas la JVM !
Car ils ont plus de contributeurs qui aiment le java ?
Personne n'aime Java. J'aime pas Java. Il y juste des gens pragmatiques qui reconnaissent une solution efficace ou pas. Apache utilise Java parce qu'il s'agit du langage d'entreprise ouvert.
C'est le problème quand on troll. Mais si java devient correcte un jour, je l'utiliserais. Dans l'état actuel, cette alternative ne me semble pas intéressante.
Il me semble que tu n'as pas regardé d'assez prêt ce qu'est "Java" aujourd'hui.
Clairement, tu n'as jamais utilisé un framework Java style OSGi ou Spring, car les équivalents n'existent pas en C++ .
Ouais, j'ai du faire autre chose en cours et en TP de java.
C'est pas avec quelques cours et TP de Java dans un IUT que tu risques de réaliser des avantages du langage. C'est probablement le langage avec le plus de bibliothèques, de frameworks, etc pour tout et n'importe quoi aujourd'hui. C'est le langage qui tourne sur le plus d'ordinateurs (je compte les téléphones portables).
Tu bases tous tes arguments sur Java, le langage, alors que je parlais explicitement de Java, la plateforme.
Oui, c'est la java que j'aime pas. Je n'ai rien contre les multiples librairies java à part leur lenteur due au langage.
Je ne parle pas particulièrement des bibliothèques mais surtout de la JVM et des langages alternatifs comme Scala ou Clojure, qui offrent clairement un confort à des années lumières de C ou de C++.
Bah un garbage collector a une utilité pour les applications d'entreprise mal codées, une machine virtuelle pour maintenir une stabilité au détriment des performances, et les langages interéprétés sont mieux fait que le java.
Après tu dit que ces langages interprétés sont plus performants avec la jvm. Tant mieux, au moins elle sert à quelque chose cette machine virtuelle.
Le garbage collector n'a rien à voir avec coder mal ! Ca fait partie du paradigme, comme les exceptions ! Une application complexe, il y a plein de développeurs qui vont travailler dessus, et pendant des années, voire dizaines d'années ! Il faut que quelqu'un qui se ramène dessus puisse la maintenir, la modifier sans tout casser. Les applications C ou C++ ont souvent leur pseudo framework maison bordélique qui change tous les ans qui rend la maintenance compliquée. En Java, tout ça, c'est standardisé ! Même la façon de nommer les classes, méthodes, tout est standardisé. On obtient un code bien plus uniforme mais surtout plus facile à maintenir.
Enfin, trouves-tu vraiment inutile qu'un développeur qui crée une application sous Windows sans penser à Linux ou à Mac produise du code compatible ? Trouves-tu que la situation d'avoir trois systèmes avec des frameworks qui se limitent à chaque système (et même parfois plusieurs frameworks comme GNOME et KDE sous Linux) est acceptable ?
[^] # Re: Ça passe très bien :)
Posté par smc . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 7.
C'est rigolo, je croyais que le java était un langage facile est efficace.
Je pense qu'aucun langage de programmation n'est "facile". Java est conçu pour être simple (et pas facile), ça n'empêche pas que chaque langage a ses propres idiomes et qu'il est insensé de transcrire naïvement le code sans tenir compte des propriétés du système (en l'occurrence la JVM).
Il faudrait que tu montres le code pour qu'on puisse te dire ce que tu fais mal, car c'est clair qu'il y a un problème vu les différences que tu trouves entre Java et C. Mais en réalité, c'est pas très important, comme il a été dit plusieurs fois, il y a plein de benchmarks bien faits sur le Web qui montrent que Java n'a pas à rougir niveau perfs.
C'est une question de compromis entre le niveau d'abstraction et la performance du code. Dans le monde réel, le compromis proposé par la JVM est intéressant et c'est pour ça que tout le monde, en dehors de Microsoft, utilise Java.
Java est présent dans des applications où il devrait à avoir du C (ou équivalent). Python et ruby non.
Non. Java a remplacé C++ qui est un enfer à maintenir et à programmer, et je dis ça en tant qu'ancien fan de C++ qui a vu la lumière et qui s'est reconverti. C++ c'est un jouet fun mais ça fait plus de mal que de bien.
Non, j'avoue, je n'ai rien codé d'aussi complexe. Et tant mieux, je n'ai pas la prétention de pouvoir le faire.
Donc, si je suis bien ton discours, tu dis "les applications complexes devraient être programmées sans GC", à quoi je réponds "ça va pas, c'est justement là qu'il est le plus utile" et tu me dis qu'en fait tu ne sais pas de quoi tu parles ;). Et bien je te dis, prenons par exemple le cas d'Eclipse vu que tu l'as utilisé comme IDE. Eclipse c'est des millions de ligne de code si tu prends que les projets de l'Eclipse Foundation (sur eclipse.org), sans compter les très nombreux projets extérieurs. Et dans un langage bien plus expressif que C.
Dans un tel système, s'assurer qu'il n'y a pas de memory leak, c'est difficile. Le garbage collector aide énormément.
Mais pas seulement pour ça. Au niveau des propriétés même du langage, c'est pratique d'avoir un garbage collector car ça te permet de savoir que si tu as une référence sur un objet, il existe. Dans un contexte de mémoire partagée (en multithread), et même si c'est bien d'éviter ça en général parfois on n'a pas le choix, c'est hyper pratique.
En C ou en C++, tu peux te retrouver avec la main sur un pointeur qui pointe dans le vide. T'es donc obligé, dès que t'as un pool de mémoire partagée, de créer toi même une abstraction sur tes pointeurs (en l'occurence, on utilise boost). Le garbage collector simplifie la vie de tous les programmeurs et l'overhead est minime comparé aux avantages. Encore une fois, c'est un compromis qu'on fait parce qu'il est impossible d'avoir uniquement des développeurs qui maîtrisent non seulement le langage, mais aussi la façon précise dont fonctionne l'application : en C/C++, une bonne partie du code, c'est pas du métier, c'est juste comment tu vas utiliser ton application. Heureusement y'a des frameworks / libs mais ils vont moins loin que ce qui existe en Java ou en .NET.
Uniquement ? Par certain ça... J'essayerais bien de tout virer (et de comparer avec la vitesse de lancement de nano, pour faire du comparatif de qualité).
Donc cette fois, tu veux comparer la durée de lancement d'un programme ncurse avec le lancement d'un programme graphique ?
Encore une fois, et j'ai l'impression que tu refuses d'entendre ça... je ne dis pas que Java ou la JVM est plus rapide ou aussi rapide qu'une application C/C++. Je dis qu'elle est *suffisamment* rapide (et à vrai dire, pas loin de C++), et que si tu as un PC antique c'est le PC qu'il faut changer, pas la JVM !
Car ils ont plus de contributeurs qui aiment le java ?
Personne n'aime Java. J'aime pas Java. Il y juste des gens pragmatiques qui reconnaissent une solution efficace ou pas. Apache utilise Java parce qu'il s'agit du langage d'entreprise ouvert.
C'est le problème quand on troll. Mais si java devient correcte un jour, je l'utiliserais. Dans l'état actuel, cette alternative ne me semble pas intéressante.
Il me semble que tu n'as pas regardé d'assez prêt ce qu'est "Java" aujourd'hui.
Clairement, tu n'as jamais utilisé un framework Java style OSGi ou Spring, car les équivalents n'existent pas en C++ .
Ouais, j'ai du faire autre chose en cours et en TP de java.
C'est pas avec quelques cours et TP de Java dans un IUT que tu risques de réaliser des avantages du langage. C'est probablement le langage avec le plus de bibliothèques, de frameworks, etc pour tout et n'importe quoi aujourd'hui. C'est le langage qui tourne sur le plus d'ordinateurs (je compte les téléphones portables).
Tu bases tous tes arguments sur Java, le langage, alors que je parlais explicitement de Java, la plateforme.
Oui, c'est la java que j'aime pas. Je n'ai rien contre les multiples librairies java à part leur lenteur due au langage.
Je ne parle pas particulièrement des bibliothèques mais surtout de la JVM et des langages alternatifs comme Scala ou Clojure, qui offrent clairement un confort à des années lumières de C ou de C++.
Bah un garbage collector a une utilité pour les applications d'entreprise mal codées, une machine virtuelle pour maintenir une stabilité au détriment des performances, et les langages interéprétés sont mieux fait que le java.
Après tu dit que ces langages interprétés sont plus performants avec la jvm. Tant mieux, au moins elle sert à quelque chose cette machine virtuelle.
Le garbage collector n'a rien à voir avec coder mal ! Ca fait partie du paradigme, comme les exceptions ! Une application complexe, il y a plein de développeurs qui vont travailler dessus, et pendant des années, voire dizaines d'années ! Il faut que quelqu'un qui se ramène dessus puisse la maintenir, la modifier sans tout casser. Les applications C ou C++ ont souvent leur pseudo framework maison bordélique qui change tous les ans qui rend la maintenance compliquée. En Java, tout ça, c'est standardisé ! Même la façon de nommer les classes, méthodes, tout est standardisé. On obtient un code bien plus uniforme mais surtout plus facile à maintenir.
Enfin, trouves-tu vraiment inutile qu'un développeur qui crée une application sous Windows sans penser à Linux ou à Mac produise du code compatible ? Trouves-tu que la situation d'avoir trois systèmes avec des frameworks qui se limitent à chaque système (et même parfois plusieurs frameworks comme GNOME et KDE sous Linux) est acceptable ?