Je vois qu'un compétiteur de qualitay s'est introduit dans le troll. Me voilà donc attelé à la lourde tâche de défendre les garbage collector.
Bien ! Pour essayer d'avancer, reprenons les points marquants de mon message précédent :
1. Incohérence de conseiller un GC puis de le critiquer
2. Les GC en C++ sont expérimentaux / En C++ on gère sa mémoire à la main.
3. Les GC désallouent bien la mémoire inutilisée sans action du développeur.
4. Java fonctionne pour développer des daemons performants (exemple Hadoop!)
Tu m'accordes le point 2 (et je t'en remercie), nous ne reviendrons donc pas dessus.
Alors, concernant le point 1, tu me réponds
Non, il te dit que si tu veux un GC, tu en as un, avec les mêmes merdes qu'avec les autres language à GC obligatoire.
C'est toi qui veut un GC, il y peut rien si tu veux un truc qui ne marche pas bien... Il dit juste que si tu veux un truc qui sert à rien, tu peux l'avoir en C aussi, le manque de GC est un faux argument contre C.
Tu admettras quand même que c'est un brin tordu de recommander un truc qu'on estime inutile. On ne donner pas un exemple de GC en C++ si on estime que les GC c'est inutile. On explique directement pourquoi c'est inutile. Si j'estime qu'une voiture c'est inutile (oh... encore une analogie de voiture), je vais pas donner l'adresse d'une concession (削除) Renault (削除ここまで)(削除) Peugeot (削除ここまで) Toyota et t'expliquer ensuite que tu ferais mieux de pas acheter de voiture. En somme, mon point 1 est valide.
A part que les GC C sont en "labs", tu n'as pas démonté grand chose...
Si, voir les points 3. et 4. J'ai démonté l'idée selon laquelle les GC ne désallouaient pas la mémoire (une grosse partie de son message), et désolé cette partie de mon argumentation est inattaquable. Au passage, j'ai taclé la confusion entre occupation RAM et rapidité d'exécution.
J'ai également argumenté contre l'idée que Java n'était pas performant (ça on peut troller là dessus).
Bref, j'ai bien démonté une grosse partie de ses affirmations.
Tu décales légèrement le troll en affirmant un GC, ça sert à rien (i) et en disant que Java n'est pas performant (ii).
Pour te répondre sur le point (i), tu seras d'accord pour dire qu'un GC, si, ça sert à quelque chose, ça sert à désallouer la mémoire inutilisée. Tu ne peux pas prétendre le contraire, je l'ai démontré dans mon commentaire précédent (point 3.). Je suppose que ta position est plutôt : la gestion manuelle de la mémoire est préférable à une gestion par un GC.
Je pense que dans la majorité des cas, il est préférable de ne pas gérer la mémoire à la main. Premièrement parce que ça évite les erreurs et oublis, un ordinateur est beaucoup plus fiable qu'un humain pour les tâches systématiques et répétitives. Deuxièmement délester le développeur de cette tâche permet de lui permettre de faire autre chose pendant se temps là (penser à l'ergonomie de son application, etc.).
Le seul problème des garbage collector est un problème de performance. Effectivement, il faut bien faire tourner l'algo de récupération de la mémoire à un moment donné et de la manière dont c'est implémenté aujourd'hui nécessite d'arrêter complètement le programme en cours d'exécution.
Mon point est que dans la plupart des cas ce ralentissement du au garbage collector est acceptable. De nombreux langages de haut niveau et pas forcément lents utilisent un garbage collector : OCaml, Haskell, Lisp...
Évidemment dans certains cas, on veut utiliser la totalité de la capacité processeur disponible (exemple, pour faire du traitement vidéo) et le ralentissement causé par un garbage collector n'est pas acceptable. Dans ces cas, on fait du C++ et basta.
Bref, non, la gestion manuelle de la mémoire n'est pas toujours préférable, et un garbage collector, ça sert.
En ce qui concerne le point (ii), tu réponds à mon argument consistant à dire que Java est suffisamment performant puisqu'il est largement utilisé, y compris pour faire du calcul intensif. Ta thèse est de dire que Java est largement répandu parce que maintenant la majorité des dévs ne sait faire que du Java à cause du forcing de Sun. Tu continues en insinuant que Java dilapide les ressources matérielles, ce qui ferait le bonheur des vendeurs de matériel. Tout ceci sans apporter aucune preuve, aucun lien, aucun benchmark. Du beau FUD.
Donc, en plus de tes souvenirs de grand-père qui vont te rester jusqu'à la fin de ta vie, je vais te demander des benchmarks ou n'importe quoi, un article. Mon argument est le suivant : hormis optimisation spécifiques (instructions vectorielles tout ça), un code Java est 2 fois plus lent qu'un code C++ en général. Et c'est quelque chose de généralement admis, voir ce post sur stackoverflow, et l'étude Loop Recognition in C++/Java/Go/Scala ainsi que Computer Language Benchmark Game.
Enfin, si tu jettes Java à cause de la perf, alors tu jettes tout les autres langages à part C∕C++/Fortran car ils sont tous soit équivalents à Java en termes de performance (Ada, Haskell...), soit beaucoup plus lents (Python, PHP, Ruby).
Oui, pour des applications très calculatoires, CPU intensive C++ est largement meilleur (et parfois 10 fois plus rapide si on utilise des choses comme les intructions SSE). Mais coder en C++ optimisé est long et difficile.
Pour revenir sur mon argument, Java est largement suffisant pour faire la majorité des tâches dans une application graphique (je rappelle que c'est ça le sujet) avec des performances raisonnables (pas plus de deux fois plus lent qu'un code C++).
Il faut arrêter avec le FUD prétendant que Java est extrêmement lent, c'est n'importe quoi.
[^] # Re: la réponse est évidente
Posté par X345 . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Bonjour Zenitram.
Je vois qu'un compétiteur de qualitay s'est introduit dans le troll. Me voilà donc attelé à la lourde tâche de défendre les garbage collector.
Bien ! Pour essayer d'avancer, reprenons les points marquants de mon message précédent :
1. Incohérence de conseiller un GC puis de le critiquer
2. Les GC en C++ sont expérimentaux / En C++ on gère sa mémoire à la main.
3. Les GC désallouent bien la mémoire inutilisée sans action du développeur.
4. Java fonctionne pour développer des daemons performants (exemple Hadoop!)
Tu m'accordes le point 2 (et je t'en remercie), nous ne reviendrons donc pas dessus.
Alors, concernant le point 1, tu me réponds
Tu admettras quand même que c'est un brin tordu de recommander un truc qu'on estime inutile. On ne donner pas un exemple de GC en C++ si on estime que les GC c'est inutile. On explique directement pourquoi c'est inutile. Si j'estime qu'une voiture c'est inutile (oh... encore une analogie de voiture), je vais pas donner l'adresse d'une concession
(削除) Renault (削除ここまで)(削除) Peugeot (削除ここまで)Toyota et t'expliquer ensuite que tu ferais mieux de pas acheter de voiture. En somme, mon point 1 est valide.Si, voir les points 3. et 4. J'ai démonté l'idée selon laquelle les GC ne désallouaient pas la mémoire (une grosse partie de son message), et désolé cette partie de mon argumentation est inattaquable. Au passage, j'ai taclé la confusion entre occupation RAM et rapidité d'exécution.
J'ai également argumenté contre l'idée que Java n'était pas performant (ça on peut troller là dessus).
Bref, j'ai bien démonté une grosse partie de ses affirmations.
Tu décales légèrement le troll en affirmant un GC, ça sert à rien (i) et en disant que Java n'est pas performant (ii).
Pour te répondre sur le point (i), tu seras d'accord pour dire qu'un GC, si, ça sert à quelque chose, ça sert à désallouer la mémoire inutilisée. Tu ne peux pas prétendre le contraire, je l'ai démontré dans mon commentaire précédent (point 3.). Je suppose que ta position est plutôt : la gestion manuelle de la mémoire est préférable à une gestion par un GC.
Je pense que dans la majorité des cas, il est préférable de ne pas gérer la mémoire à la main. Premièrement parce que ça évite les erreurs et oublis, un ordinateur est beaucoup plus fiable qu'un humain pour les tâches systématiques et répétitives. Deuxièmement délester le développeur de cette tâche permet de lui permettre de faire autre chose pendant se temps là (penser à l'ergonomie de son application, etc.).
Le seul problème des garbage collector est un problème de performance. Effectivement, il faut bien faire tourner l'algo de récupération de la mémoire à un moment donné et de la manière dont c'est implémenté aujourd'hui nécessite d'arrêter complètement le programme en cours d'exécution.
Mon point est que dans la plupart des cas ce ralentissement du au garbage collector est acceptable. De nombreux langages de haut niveau et pas forcément lents utilisent un garbage collector : OCaml, Haskell, Lisp...
Évidemment dans certains cas, on veut utiliser la totalité de la capacité processeur disponible (exemple, pour faire du traitement vidéo) et le ralentissement causé par un garbage collector n'est pas acceptable. Dans ces cas, on fait du C++ et basta.
Bref, non, la gestion manuelle de la mémoire n'est pas toujours préférable, et un garbage collector, ça sert.
En ce qui concerne le point (ii), tu réponds à mon argument consistant à dire que Java est suffisamment performant puisqu'il est largement utilisé, y compris pour faire du calcul intensif. Ta thèse est de dire que Java est largement répandu parce que maintenant la majorité des dévs ne sait faire que du Java à cause du forcing de Sun. Tu continues en insinuant que Java dilapide les ressources matérielles, ce qui ferait le bonheur des vendeurs de matériel. Tout ceci sans apporter aucune preuve, aucun lien, aucun benchmark. Du beau FUD.
Donc, en plus de tes souvenirs de grand-père qui vont te rester jusqu'à la fin de ta vie, je vais te demander des benchmarks ou n'importe quoi, un article. Mon argument est le suivant : hormis optimisation spécifiques (instructions vectorielles tout ça), un code Java est 2 fois plus lent qu'un code C++ en général. Et c'est quelque chose de généralement admis, voir ce post sur stackoverflow, et l'étude Loop Recognition in C++/Java/Go/Scala ainsi que Computer Language Benchmark Game.
Enfin, si tu jettes Java à cause de la perf, alors tu jettes tout les autres langages à part C∕C++/Fortran car ils sont tous soit équivalents à Java en termes de performance (Ada, Haskell...), soit beaucoup plus lents (Python, PHP, Ruby).
Oui, pour des applications très calculatoires, CPU intensive C++ est largement meilleur (et parfois 10 fois plus rapide si on utilise des choses comme les intructions SSE). Mais coder en C++ optimisé est long et difficile.
Pour revenir sur mon argument, Java est largement suffisant pour faire la majorité des tâches dans une application graphique (je rappelle que c'est ça le sujet) avec des performances raisonnables (pas plus de deux fois plus lent qu'un code C++).
Il faut arrêter avec le FUD prétendant que Java est extrêmement lent, c'est n'importe quoi.