X345 a écrit 580 commentaires

Peut-être pour des questions de vie privée ? Ça m'enchanterai assez moyennement que mes amis aient accès à mes mails sur un serveur mutualisé (et inversement, ça me enchanterai assez moyennement d'avoir accès à leurs mails). Même en utilisant des machines virtuelles, ça reste assez trivial à faire. Il faut aussi noter que c'est de plus en plus compliqué d'avoir beaucoup d'adresses IP par serveur (et qu'on a des hébergeurs qui proposent des dédiés à vraiment pas cher).

Bon on est Vendredi et ça doit beaucoup jouer (ne nous voilons pas la face, mais bon le troll a commencé Jeudi et Jeudi c'est pas Vendredi) mais je trouve que les réactions des gens font très enfant gâté et pas vraiment dans l'esprit du logiciel libre.

Sérieusement, tu présentes une application Web récente (si j'en crois l'historique de commit, le développement a débuté le 25 Janvier) donc une première version stable et utilisable et tout le monde est à geindre parce que ça marche pas sur CentOS 6, parce que tu fournis pas de VM préconfigurée (non mais franchement…), parce que y'a pas de version démo, parce que ton soft est pas full-compliant DSI avec des beau slides de présentation et une démo pour les diçaïdor…

Alors oui, pour installer une application Web, il faut une stack Web, grande nouvelle… Et oui, une stack Web, c'est un peu chiant à installer et ni Mme Michu, ne le DSI n'ont sur ça machine.
Les gens vont se faire des nœuds dans la tête (pas dans leur serveur Web sous CentOS etc.) alors que ça prend 10 minutes d'installer un serveur Web sur sa machine de bureau. Limite ils sont à demander de venir taper apt-get install apache2 libapache2-mod-php5 chez eux.

Évidemment une démo en ligne ce serait très pratique, mais c'est totalement compréhensible que l'auteur d'une application Web sortie il y a 4 jours n'ai pas eu le temps de faire ça. Quand à la demande pour une VM préconfigurée, ça laisse vraiment songeur. C'est pas comme si ça prenait du temps à mettre en place, et que ça avait des coûts d'hébergement non négligeables (Hein, ça fait pas 2Ko une image de VM).

Du coup, pour compenser un peu tout ça je te souhaite un bon courage pour la mise en place de ta démo en ligne quand tu en auras le temps.

Oui, même les routeurs bas de gamme comportent un switch configurable sur lequel on peut configurer l'interface (ethX.Y, en général on peut en configurer deux) sur laquelle on veut "brancher" chaque port. On peut faire ça facilement sous OpenWRT, j'imagine qu'on peut le faire aussi sous DD-WRT.

Par contre, pour revenir sur le commentaire initial, si le budget n'est pas un gros problème, j'éviterai d'acheter un routeur bas de gamme à 30€ car ils routent bien en dessous d'1Gbps, ne dépassant même pas 200Mbps pour les modèles les moins chers. J'entends bien router, c'est à dire transférer des paquets IP (niveau 3) d'une interface à une autre (entre le LAN et le WAN par exemple). Le switching marche en général très bien, et on peut transférer à 1Gbps entre deux machines du LAN, même sur les modèles les moins chers.

Quand on commence à jouer avec OpenWRT, avoir un peu plus que 32Mo de RAM et 8Mo de Flash, c'est appréciable (surtout pour la Flash). Il y a de bons routeurs dans la tranche 80-110€.

D'accord. De mon côté, j'ai besoin de :

3 kilos de CAROTTES lavées (que je cuisine direct)
2 CITRONS frais (à presser)
2 filets de MERLAN
1 motte de BEURRE
2 avocats 3 à 4 exp (pour Linuxfr :P)
10 pqt de trucs (je sais même pas vraiment ce qu'il me faut)
2 pots de CONFITURE (mûre et coings)
2 escalopes de DINDE
1 pot de MOUTARDE
1 mouton à 5 pattes avec connaissance obligatoire du périphérique parisien
1 développeur C++ MFC Aix Nord (prestation)
2 Chefs de Projet WEB Fonctionnel AIX (embauche ou pré-embauche)
1 BEURRE, l'argent du BEURRE et le cul de la crémière (président)
1 PQ senteur des prés (lotus)
1 pot de MIEL (toutes fleurs Ou acacia)
1 pqt de pat BARILLA
1 pqt riz complet

Plus sérieusement, j'ai jamais vraiment compris cette manie de mettre certains mots en MAJUSCULES dans les OFFRES d'EMPLOI. Typiquement, y'a aucun besoin d'écrire Java en HURLANT, ni même Web ou Web service. Je sais pas non plus ce que c'est qu'"1 Soft". Un développeur ? Un "soft emb" ? Un développeur embarqué ? Et euh… C'est vague comme intitulé de poste, on peut en savoir plus ? En plus, on se demande bien pourquoi t'en as besoin de 10. Sans compter les intitulés de poste qui posent question "développeur PHP5 connaissance Java", "Admin Linux avec connaissance Windows". On a aussi le droit aux intitulés de poste hyper précis (mais pourquoi ?!) style "développeur JAVA/SWING". Parce qu'un mec qui connaît Java, C++ et Qt, vous pensez qu'il va pas être efficace pour créer une appli en Swing ?

La France, pays où on prend les ingénieurs/techniciens/développeurs/scientifiques pour du bétail, que dis-je des objets qu'on se permet de lister comme sur une vulgaire liste de courses. Pour être cool faut avoir fait commerce, marketing et surtout, surtout, ne rien connaître à la technique. La technique c'est sale, c'est pour le petit personnel.

J'ai l'immense chance d'avoir un poste très intéressant et ne pas naviguer dedans, mais le marché du travail pour les informaticiens est vraiment déprimant en France. Pas étonnant qu'on arrive à rien dans notre pays (quasiment pas de start up en France, peu d'éditeurs logiciels, le marché est dominé par les SSI-à-qui-fera-le-truc-le-plus-dégeu-le-moins-cher). À croire que tout le monde en à rien à faire. Rien à faire de décrire les postes convenablement. Rien à faire d'embaucher un mec compétent, il faut juste un ingé jetable qui connait la techno qu'on va utiliser les trois prochains mois. Rien à faire de développer un produit/service innovant/stable/utile. Rien à faire de développer les compétences.

Si jamais ça t'intéresse de creuser la question, cette technique de manipulation (demander quelque chose de complètement déraisonnable pour conduire son interlocuteur à accepter la requête raisonnable) s'appelle une porte-au-nez

Le point soulevé par Almacha (le droit qu'a un prestataire de faire ce qu'il veut avec son propre réseau) est une question qui revient souvent lorsqu'on parle de neutralité du net.

Pour y répondre, je reprendrais bien un argument de Benjamin Bayart qui est dans le même ordre d'idées que ceux que tu énonces. Benjamin Bayart s'amuse à comparer un internet non neutre à des yaourts au mercure. En France, il y a des choses que l'on a pas le droit de vendre parce que ce sont des choses nocives. Même si les consommateurs sont libres d'acheter les yaourts sans mecrure d'un de mes concurrents, j'ai toujours pas le droit de vendre des yaourts au mercure. Reste à voir si un internet non-neutre est aussi nocif que des yaourts au mercure. Gardons à l'esprit qu'internet est depuis au moins 5 ans le principal moyen d'accès à l'information, à la vie démocratique de la majorité de la population. Que dira-t-on lorsqu'on ne pourra plus accéder au site web du parti communiste parce que le parti communiste n'aura pas pu passer d'accord avec les FAIs majoritaires. Je ne vous fait pas l'affront de vous ressortir le couplet sur la concurrence et la liberté d'entreprendre. Comment lancer un service innovant si les acteurs en place ont le pouvoir de vous empêcher d'accéder au marché. Un autre effet de bord inquiétant de cette politique est qu'on se dirigerait vers des accès internet de « pauvres » avec accès à quelques gros sites (facebook, youtube, tf1.fr) et des accès internet de « riches » avec une diversité plus grande. Génial pour la vie démocratique, l'égalité des chances, l'ascenceur social. L'accès à internet n'est manifestement pas un service comme les autres, ce ne serait donc pas illogique qu'il y ait des règles spécifiques qui régulent sa commerciation. La presse (en tant que produit pas comme les autres) non plus n'a pas le droit de faire n'importe quoi.

Autre argument, et pour reprendre ma métaphore latière (j'aime les yaourts), on a le droit de vendre des yaourts "régime" avec plus d'autres trucs que du lait et des ferments lactiques dedans mais on a pas le droit de les appeler yaourts. Regardez bien, tous ces yaourts "régime", s'appellent "spécialité latière" dans les supermarchés. Et ce parce que ce serait de la tromperie sur la marchandise : un yaourt c'est fait avec du lait et des ferments lactiques, c'est tout. Si tu mets d'autre trucs dedans, ça s'apelle plus un yaourt. Et internet ? Internet, c'est neutre, si tu mes des bout de non-neutralité dedans ça s'apelle plus internet.

Enfin, dernièrement, faut pas oublier que "le réseau de l'opérateur", en fait bien souvent, il a été payé en grande partie par les pouvoirs publics. Les bouts de cuivre qui vont de chez moi au central téléphonique, ils ont été largement subventionnés par l'état. Donc payés par les citoyens. On est en train de faire pareil avec la fibre, l'état va déployer là ou ce n'est pas hyper-rentable (tiens donc !). Donc finalement, notre regard sur ce que les opérateurs font de "leurs" réseaux ne serait pas si injustifié que ça.

T'aurais pu attendre vendredi quand même. T'abuses, on est tout juste Lundi !

Ton exemple est non représentatif d'objet à longue durée de vie. En C++, dans ce cas, il n'y aurait même pas d'allocation mais un objet local sur stack, qui ne coûte rien en allocation.

Pfff… Le graphe est supposé être une structure dynamique donc alloué dans le tas. Franchement, un graphe alloué sur la pile, c'est un graphe dont on connait exactement la structure à la compilation, ça limite son intérêt…

Évidemment dans le cas que tu présentes y'a une fuite mémoire (j'ai pas dit que c'était impossible). Après si tu fous pleins de morceaux de code qui n'ont rien à voir entre eux dans une même méthode… Clairement ici, la boucle infinie n'a pas besoin d'avoir accès au graphe. On en revient au code mal conçu.

Et même dans le cas hypothétique où tu aurais besoin de nuller une référence, ça reste avantageux en terme de temps de développement par rapport à une gestion manuelle :

• Pas besoin de concevoir des destructeurs pour Graph et Node
• Il n'y a que quelques endroits dans ton code ou tu dois nullifier ton graphe (donc équivalent à un delete) et non pas partout (avec le risque d'oublier, de ne pas penser aux exceptions qui pourraient passer etc.)

Après je vais vraiment arrêter de troller parce qu'on tourne vraiment en rond. Il n'y a vraiment pas à nuller des références en général et le GC désalloue la mémoire non utilisée.

La fuite mémoire en java cela se résous à coup de nullification sur les objets de longue durée

Je sais pas pourquoi tu as cette idée fixe :-( en tête mais en Java, il n'y a pas besoin de mettre à null les références pour que la mémoire soit désallouée. Comme le signale Barret Michel plus haut, si tu as besoin de faire ça, c'est que tu as un sérieux problème de conception dans ton application.

Ce genre de truc est totalement inutile en Java, par exemple :

int maMethode {
    Graph bidule = new Graph();
    // Faire des opérations sur bidule
    bidule = null; // Cette ligne ne sert à rien, bidule
    // sera désalloué à la fin de la méthode, même si
    // c'est une structure de données récursive (ou profondément linkée
    // comme tu dis). Il n'y pas besoin d'écrire de destructeur
    // dans la classe graphe pour détruire les nœuds.
    return result;
}

Si tu as des fuites mémoire en Java, c'est que tu gardes des références sur des des choses qui ne servent plus. Dans ce cas, tu as un problème de conception de ton application et la solution c'est pas de nullifier n'importe comment mais de revoir ton architecture. Un programme Java correctement fichu n'a pas besoin de « nullification » systématique.

Après, oui, un full GC bloque l'application. Mais il ne faut pas exagérer la durée d'un full GC non plus (en ~1seconde, on doit nettoyer au moins 1GB de tas) ni sa fréquence (ça n'arrive pas toutes les 1 seconde…)

Bon allez, je re réponds à ça et puis je vais m'arrêter là.

C'est à peu de chose la référence pour les logiciels libres.

D'accord mais n'en rajoutons pas. Ça a l'air surtout utilisé par des compilateurs/interpréteurs (Java,Scheme,C# notamment mono), ce qui est quand même quelque chose de particulier. Mozilla l'utilise certes mais comme détecteur de fuites, pas comme garbage collector. Reste que l'écrasante majorité des logiciels écrits en C++ sont codés avec une gestion manuelle de la mémoire.

Il est juste pas content parce qu'il dit « pas de gc en C » et que je lui prouve que c'est trivialement faux

Bravo pour la citation fausse citation. Je n'ai jamais écrit « pas de gc en C », ni même quelquechose de sémantiquement équivalent, inutile donc d'employer les guillemets. J'ai simplement prétendu que le C++ me forçait à gérer la mémoire à la main, ce qui est vrai. Il n'y a pas de garbage collector dans les bibliothèques C++ répandues et ce n'est pas quelquechose de courant d'utiliser un GC. Bref, je dois gérer ma mémoire à la main en C++.

D'autre part, on va pas jouer au plus malin C est Turing complet, donc évident qu'on peut implémenter n'importe quoi en C, y compris un garbage collector.

Je lui dis que les bench. de 6 secondes cela ne représente rien parce que le GC ne libère jamais rien. Il répond en résumé, il suffit d'utiliser -Xms. Il me parle de pool et prétend que j'ai décris le fonctionnement d'un GC parce que j'ai parlé de simuler, en C, ce que fait réellement le gc dans les bench de 6s : il alloue un pool et incrémente un pointeur c'est tout, jamais le moindre gc qui passe.

Non.

1. Tu as prétendu qu'il fallait mettre les pointeurs à null pour que la mémoire soit désallouée quand on utilisait un GC. C'est faux. Exécution de 6 secondes ou pas. C'est le cœur de mon argument.
2. Tu as confondu temps d'exécution et occupation mémoire. C'est n'importe quoi et je l'ai relevé.
3. La remarque sur -Xms était une remarque à côté, en aucun cas mon argument principal.

Donc, en résumé, non et re-non, jusqu'à preuve du contraire, aucun GC ne bat ni se rapproche des performances d'une (dés-)allocation manuelle. L'emballement se fait sur la durée pas sur du microbench.

Ah. Bon, on va finalement être d'accord. Effectivement (à l'heure actuelle), une gestion manuelle de la mémoire est plus performante qu'une gestion via un GC (d'ailleurs je n'ai pas vraiment prétendu le contraire mais passons). Mon point est simplement qu'en dehors de cas où on veut avoir le maximum de performance, la gestion par un garbage collector offrait des performances suffisantes. On parlait d'une application graphique à la base, pas d'un serveur daemon ultra optimisé ni d'un application de calcul intensif.

Bon et pour ton « emballement », va falloir préciser de quoi tu parles et donner des preuves. La mémoire n'est pas désallouée ? Le GC bouffre trop de temps CPU ?

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

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.

Je fais du python à peu près tous les jours et je n'ai jamais jamais de problème de performance. J'ai fait des applis simples et certaines moyennement complexes. Jamais je n'ai encore rencontré les limites de performances de Python.

Python (et PyQt/PySide) est très bien (j'insiste) tant que l'application n'est pas trop grosse et ne fait pas trop de calcul. J'ai aussi fait beaucoup d'applications Python (du Web, des applications graphiques, du réseau), plutôt des petites (< 10000 lignes), le plus gros projet auquel j'ai participé étant Netzob.

Cependant, dès que tu fais du calcul tu te heurtes à la lenteur de Python. Par exemple dans Netzob, les parties calculatoires (alignement de séquence etc.) sont codés en C car Python est trop lent. Sur des tâches purement calculatoires, Python peut être 50 fois plus lent que du C. Un facteur 50, c'est sensible. Dans le domaine du Web, les frameworks Python sont plus lents que leurs équivalents JVM (Java, Scala, Clojure), C++ ou Go. Je rappelle aussi qu'il n'y a pas de multithread réel en Python à cause du Global Interpreter Lock (GIL) qui empêche deux threads de s'exécuter réellement en parallèle (donc impossibilité d'exploiter un processeur multicore, et multiprocessing n'est qu'une solution partielle à ce problème).

Évidemment s'il s'agit de faire un client FTP ou éditeur de texte en Python et de le faire tourner sur un Core i5, il n'y aura aucun problème de performance (et même des choses plus grosses).

Et il rame peu, pour preuve, il est en train de s'imposer comme langage de référence dans le calcul numérique scientifique.

Wow Wow… Doucement. Python est certes très utilisé dans le monde scientifique mais c'est bien souvent via des modules comme numpy ou scipy et qui sont écrits… en C pour des questions de performance !
D'autre part, il existe des dizaines projets à destination du monde scientifique ou non visant à accélérer l'exécution du code Python : numexpr, shedskin, pythran, pypy, ce qui montre bien qu'il y a un problème. Au passage Pypy arrive a être 5x plus rapide que CPython (l'implémentation de référence) sur des benchmarks calculatoires, preuve qu'il y a bien de la marge de manœuvre. …

En résumé, non, c'est pas juste un mantra.

Oui, tu as raison sur toute la ligne. J'avais entendu parler de kivy il y a quelques années et j'ai jugé sur mes souvenirs sans prendre le temps d'aller visiter le site à nouveau /o\ Mais tu remarqueras que mon commentaire (à côté de la plaque) est sévèrement moinssé…

Après je ne sais pas ce que donne Python sur des plateformes mobiles, sur ces plateformes la puissance de calcul est plus faible et surtout le ratio performance∕watt est important, mais je ne vais pas commettre l'erreur de juger sans savoir une seconde fois :-)

Tout de même, tu m'accuses de ne pas être subtil mais tu ne fais pas mieux. Et en plus tu débarques après la fin du trolldi. Bref, c'est pas joli joli tout ça.

Alors dans un premier temps, tu réalises l'exploit de me dire que je n'ai qu'à utiliser un garbage collector pour ne pas avoir à gérer ma mémoire à la main (soit) et de m'expliquer dans le même commentaire que les garbage collector c'est pourri parce que la mémoire n'est jamais désallouée si on met pas les pointeurs à null. Donc au final, il faut que j'utilise un garbage collector mais les garbage collector, ça sert à rien ?

Deuxièmement, certes tu as trouvé une implémentation de garbage collector (GC) en C++ qui a l'air correct mais tu seras bien obligé d'admettre qu'utiliser un GC en C++ n'est pas courant.
Le GC que tu présentes est décrit sur une page de HP labs ce qui laisse clairement penser que ce n'est pas vraiment prêt pour être utilisé en production. Les bibliothèques C++ majeures (boost, Qt) n'incluent pas de GC. Le code de KDE, écrit en majorité en C++ n'utilise pas de GC. Bref, en C++, on gère sa mémoire à la main en pratique. Enfin, on utilise pas malloc en C++ mais new.

Troisièmement, dans la deuxième partie de ton message, tu m'expliques que Java va consommer plus de RAM (je vais expliquer dans la suite dans mon message pourquoi ton explication est fausse) puis tu utilises cet argument pour dire que les « performances sont dramatiquement plus basses ». Tu mélanges tout. Un programme peut consommer beaucoup de RAM s’exécuter rapidement, il ne faut pas confondre rapidité d'exécution et consommation mémoire.

Dernièrement, l'explication que tu donnes du fonctionnement d'un garbage collector est complètement erronée. Certes la JVM alloue un pool de mémoire à son démarrage, ce qui est une bonne idée pour de questions de performance, sa taille est réglable via le paramètre -Xms. Ce que tu ne précises pas est que la taille de ce pool est dynamique : il grandit si le programme a besoin de plus de mémoire (on ne fait pas qu'incrémenter le pointeur) et rétrécit (la mémoire est désallouée) si le programme à besoin de moins de RAM. La JVM ne fait pas qu'incrémenter un pointeur vers le pool, elle gère aussi sa taille.
Et évidemment, il n'y pas besoin de mettre des pointeurs à null pour que les objets vers lequels ils pointent soient désalloués, le GC désalloue les objets hors de portée (les choses invisibles sont détruites…) sans que les pointeurs soient mis à null (voir comptage de référence, et mark and sweep sur Garbage collection)

Et pour information, Hadoop (un environnement de programmation distribuée adapté au traitement de données volumineuses, le fameux big data) est écrit en Java et tourne sur 42000 serveurs chez Yahoo!. Si Java ne permettait de faire des daemons performants, tu crois pas qu'ils auraient recodé Hadoop en C++ ?

Bref, remballe ton troll bas de gamme, il est trop facile à démonter.

Ah du coup, à trois jours d'intervalle, tu arrives à dire :

Au lieu de Qt, j'aurais choisi HTML5. Qt c'est tout autant oldschool que GTK.
cf. http://linuxfr.org/users/nonolapero/journaux/c-est-au-tour-de-wireshark-de-passer-a-qt#comment-1494731

Non vraiment, je te conseille Ncurses sans aucun cotés web.

Et alors là, j'ai du mal à suivre.
Gtk+ et Qt c'est old school donc pas cool. HTML5 c'est récent donc cool.
Et alors, donc, euh… Ncurses c'est hyper old school donc ça devient hipster donc cool ?
Si j'ai pas tout compris, explique moi !

Alors mais oui, mais c'est du Ncurses over HTTP/HTML/JS/CSS, j'espère ? Non parce que si y'a pas de serveur HTTP embarqué, j'en veux pas !

Ça se voit qu'on est trolldi :-)

Oui, tu as totalement raison pour la version historique du client torrent qui est bien écrite en Python, y compris la partie réseau. Comme tu le dis toi-même, c'est surement une approche très bien pour les preuve de concept. Mais ce n'est peut-être pas pour rien que Deluge utilise la libtorrent écrite en C, plutôt que le module Python.

Totalement en dehors de cet exemple de client bittorent, dès qu'on fait un peut de calcul ou que l'application grossit un peu, on peut se retrouver limité par la lourdeur de Python.
Vous imaginez LibreOffice ou Abiword en Python ?
Il n'y aussi pas de vrais threads en Python (du fait du Global Interpreter Lock, qui empêche les threads de s'exécuter réellement en parallèle quand on dispose de deux cœurs), ce qui est aussi gênant, même si on ne fait pas spécialement de calcul.

Effectivement, tu as complètement raison, on peut maintenant coder une interface complète en Qt Quick/QML. Les tutoriels que j'ai lu n'en parlaient pas, surement parce que c'est tout récent (QtQuick.Controls date de Qt 5.1).

C'est intéressant, par contre, comme c'est du Qt, on reste obligé de se taper toute la logique métier en C++, ce qu'on pourrait vouloir éviter. Mais reste que QML a le potentiel de grandement alléger le développement en Qt/C++ ce qui est très bon à prendre.

… […] je n'en ai aucune idée, je ne fais pas d'interface graphique

Honnnêtement TTK, c'est vraiment pas terrible, c'est basé sur Tk ce qui n'est pas ce qui se fait de plus facile à utiliser de nos jours dès qu'on veut faire un truc un peu plus complexe que trois boutons et un champ texte (genre une fenêtre principale d'application avec des panneaux…). C'est très bien pour faire un truc rapidement en Python, mais c'est tout.
L'intégration TTK avec Gtk+/Qt est plus ou moins expérimentale (ça fonctionne pas out-of-the box sous Debian ou Ubuntu…)

Je passe sur le serveur web ("à la CUPS"). C'est surement jouable pour la configuration d'un serveur d'impression mais pour une application graphique, ce sera beaucoup beaucoup plus long et difficile à coder que n'importe quoi d'autre. Sans compter les performances et le déploiement.

[…] bindings type Cpython

Gni ? CPython c'est l'interpréteur "standard" et officiel de "Python". Cython est un compilateur de code Python et pseudo-Python (langage basé sur Pyrex) vers C. Du coup, je sais pas duquel tu parles.

D'autre part, cette approche—utiliser du Python autant que possible et ne faire en C que les parties dont la performance est critique—est certes très bonne en théorique mais un peu lourde en pratique. Je m'explique : si on veut faire ça, il faut commencer à profiler l'application en profondeur, découper les parties que l'on fait en C/Cython et celles que l'on fait en Python, s'occuper éventuellement de la glue entre Python et C.
Bref, c'est long (et relativement compliqué au final). C'était l'approche utilisée dans une application sur laquelle j'ai développé (oui, parce que ça devient marrant quand il faut synchroniser les threads du backend avec l'interface graphique…) et parfois, j'ai l'impression qu'on perd plus de temps avec cette approche que de tout faire en Java. D'autant plus que dans certains cas (widgets List et TreeView notamment), même mettre à jour l'interface graphique en Python peut devenir lent (l'interface va manquer de réactivité). Tout ça est loin d'être génial en pratique.

Je viens de retrouver les références du journal dont les commentaires critiquent l'utilisation de Python comme langage pour faire des applications graphiques :

Ici : https://linuxfr.org/users/nedflanders/journaux/j-ai-installe-ubuntu-sur-une-nexus-7#comment-1415470

On a fait une installe de ubuntu sur une Nexus 7 de notre cote, et juste apres le boot, le systeme consomme 600Mo sur 1Go. Autant dire qu'il n'y a pas moyen de faire tourner un navigateur web avec quelque tab ouvert… Le principal probleme, l'utilisation de python a tout bout de champs. Genre le clavier virtuel qui consomme 30Mo a lui tout seul !

Et là : https://linuxfr.org/users/nedflanders/journaux/j-ai-installe-ubuntu-sur-une-nexus-7#comment-1415553

Maintenant, le probleme, c'est plutot python que le fait que ce soit un langage de script. Android avec une VM Java a de bonne perf sur tablette. Maintenant dans le domaine du logiciel libre, la VM la plus aboutit, c'est v8. Mais bon, pas grand monde utilise ca pour faire des applis locales.

Euh, on peut reprocher à Qt de ne pas avoir de bindings de bonne qualité pour différents langages, mais est-ce vraiment mieux du côté de Gtk+ ?

En ce qui concerne Python, par exemple, la situation est meilleure du côté de Qt. Le binding Gtk+3 pour Python, PyGObject3+ est pénible à faire fonctionner sous Windows. Je viens de voir que sa doc s'est beaucoup améliorée, y'a 1 an et demi, c'était pas ça (mais bon, c'était pardonnable étant donné la jeunesse de Gtk+3 à l'époque). Les deux bindings Qt fonctionnent très bien, y compris sous Windows. Après, certes Python c'est lent.

Pour Java, j'ai du mal à dire si java-gnome est plus ou moins moribond que Qt Jambi.

Alors oui Gtk+ a un binding pour OCaml mais il n'est pas à jour et Go mais est-ce vraiment utilisable cette affaire ?

Alors finalement, ce serait quoi le langage que tu voudrais utiliser pour développer et qui dispose d'un binding Gtk+ mais pas de binding Gt ?

Je ne connais pas bien QML, j'ai jamais codé d'application avec, mais j'ai l'impression qu'il s'agit surtout d'une techno pour coder de nouveaux widgets avec un comportement particulier.

Les tutoriels ne me donnent pas l'impression qu'il n'est pas possible de coder une QMainWindow complète avec (avec tout plein de QLineEdit, QButton, QTreeView et QFrame dedans), mais peut-être que je me trompe mais plutôt qu'on utilise des composants de plus bas niveau (Rectangle etc.) pour coder de nouveau widgets (dont on exprime le comportement en Javascript).

Si ça permet de faire ça, c'est une solution intéressante d'autant que QML utilise le moteur javascript V8, ce qui devrait offrir de bonnes performances.

En général, je suis moyennement fan des trucs nouveaux/peu testés. Ça parait génial au début puis progressivement, on se rend compte qu'il manque la moitié des fonctionnalités dont on a besoin et qu'on est le premier à déterrer des bugs.

Et puis bon, comme je disais dans le journal, c'est du Python. Et Python, c'est lent.

un boost::shared_pointer, au même titre qu'un boost::scoped_pointer, boost_intrusive_ptr et autres joyeusetés, ne sont en aucun cas des ramasse miette !!!

Mais c'est bien ce que je dis. Moi aussi ça me fait bondir. Pourquoi me répondre en faisant usage de moultes point d'exclamations alors ?

J'ai énormément de mal à coder en Java, alors qu'en C++, les choses s'écrivent simplement pour moi.

Pardonne mon agressivité, mais on s'en fiche de ton cas personnel. La question est de savoir si pour la grande majorité des développeurs, C++ est plus difficile à utiliser/maitriser. Franchement, c'est quelquechose de généralement admis (demande à des profs d'informatique et aux étudiants) et prétendre le contraire, c'est un peu du troll.

Et perso, entre une appli en java faite par un dev qui ne sait pas ce qu'il fait mais qui va quand même sortir cas la JVM s'est occupée de ramasser ses merdes miettes et une en C++ avec un codeur qui ne sait pas ce qu'il fait, du coup ça ne sortira pas. Je ne suis pas sur de ce qui est le mieux.

Honnêtement, le ramasse-miettes, ça fonctionne, il ne faut pas prétendre le contraire. Certes faut éviter de faire complètement n'importe quoi (références croisées/circulaires, faire attention à ne pas garder des références sur des objets trop longtemps), mais dans 90% des cas ça marche sans qu'on s'en occupe. Pour les 10% restants de cas tordus, un tout petit peu d'expertise suffit à résoudre le problème. Pas évident qu'il y ait au moins un de ces cas dans une application donnée, j'ai codé des tas d'applis en Java et honnêtement, je peux compter mes problèmes avec le GC (si on exclue les problèmes de perf que ça peut poser, je parle uniquement de fuites/bug) sur les doigts d'une main.

XULrunner, c'était une technologie d'avenir en 2005, non ?

Plus sérieusement, j'ai pas l'impression qu'il soit très utilisé de nos jours, mais peut être que je me trompe. Apparemment, il a l'air d'être compatible Android, ce qui est un bon point. Cependant j'ai l'impression que l'ensemble de widgets XUL est un peut moins sympa et puissant que celui de Qt.