Journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes

Posté par  . Licence CC By‑SA.
Étiquettes :
14
25
oct.
2013

Bonjour Nal,

Je me faisais cette semaine la réflexion que je serais bien en peine si je devais à au jour d'aujourd'hui (oui cette formulation est totalement redondante) choisir un couple langage/bibliothèque pour écrire une application multiplateforme disposant d'une interface graphique. Mais tu auras remarqué, Nal, que je suis bien élevé et que j'ai religieusement attendu trolldi pour te faire part de mes états d’âme.

Prenons l'exemple d'une application effectuant des transferts réseau comme un gestionnaire de téléchargement ou un client bittorrent devant fonctionner sous Linux/Windows/MacOS. Ou d'une application d'édition de documents, un éditeur markdown par exemple.

Je connais les technos suivantes, mais aucune ne me parait vraiment utilisable.

  • Il y a tout d'abord le couple C++/Qt. Il est vrai que ce couple permet de faire sans problèmes des interfaces graphiques de très bonne qualité et relativement faciles à porter sur différentes plateformes. Mais honnêtement, coder en C++ c'est compliqué et très error-prone, comme nous l'a si bien montre LiNuCe à travers un lien posté sur la Linuxfr International Tribune : Deep C. Est-ce que je veux vraiment coder dans un langage d'aussi bas niveau, qui me force à gérer la mémoire à la main pour réaliser une interface graphique ?

  • Si on je ne veux pas gérer la mémoire à la main et disposer d'un langage de plus haut niveau, on me proposera Java. Mais il faut reconnaître que les interfaces graphiques réalisées avec Swing sont vraiment moins attractives que celles réalisées avec Qt. Il y a bien un binding Java pour Qt, Qt Jambi, mais il est franchement moribond (pas de projets libres majeurs l'utilisent, d'ailleurs le site de Jambi est down à l'heure au j'écris).
    D'autre part, bien que la JVM offre d'excellentes performances (Java est bien souvent seulement 20% plus lent que C++, au pire seulement 100% plus lent), elle est tout de même assez lourde en termes d'occupation mémoire et de temps de chargement en mémoire. Un runtime plus léger serait franchement appréciable.

  • On pourra alors me proposer Python et PyQt (ou PySide). Ce couple peut paraitre excellent à première vue : les bindings Python pour Qt sont maintenus et documentés, Python est langage de haut niveau, le runtime est relativement léger. Mais voilà, il faut bien reconnaître que Python est lent, très lent. Là où Java est 2 fois plus lent que C++, Python sera facilement 5 à 10 fois plus lent. On peut certes coder les parties les plus critiques de notre application en C ou utiliser un des choses comme Cython. Mais cette technique nécessite de profiler notre application, écrire des bindings Python/C, adapter le process de compilation de l'application pour utiliser deux langages. Bref, tout ceci complique grandement le développement de notre application.
    On pourra aussi ajouter que Python est langage typé dynamiquement et que dans des projets plus importants, un langage typé statiquement est préférable pour détecter un maximum d'erreurs à la compilation. Et tout ceci est sans compter le cauchemar qu'est le packaging et déploiement d'applications Python.

Si on regarde du côté des langages plus récents comme Go, Scala ou Rust, la situation n'est guère plus reluisante. Ils ne proposent rien de vraiment utilisable pour coder des interfaces graphiques.

Et toi, mon journal qu'en penses-tu ?
Est-ce tu penses que je devrais arrêter de me préoccuper de tout ça et coder mes interfaces graphiques en nodejs/HTML5 et communiquer avec mon bancked à travers HTTP WebSocket ?
Est-ce que tu penses que le Windows/Linux/MacOS sont morts et qu'il suffit de maitrîser l'API d'Android ?

  • # la réponse est évidente

    Posté par  (site web personnel) . Évalué à 7.

    Je pense que Qt/c++ est un no-brainer dans ce genre de situation.
    Ou bien si tu veux un truc un peu plus rustique et moins gros que Qt, http://www.juce.com/ est portable sur linux/windows/macos/android/ios

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 1.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: la réponse est évidente

        Posté par  . Évalué à 7.

        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.

        • [^] # Re: la réponse est évidente

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 27 octobre 2013 à 22:31.

          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.

          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.

          Donc au final, il faut que j'utilise un garbage collector mais les garbage collector, ça sert à rien ?

          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.

          mais tu seras bien obligé d'admettre qu'utiliser un GC en C++ n'est pas courant.

          Ben disons que les gens ont compris que ça sert à rien, donc pas courant, oui.

          Si Java ne permettait de faire des daemons performants, tu crois pas qu'ils auraient recodé Hadoop en C++ ?

          Pas si ils ont des développeurs Java à la pelle qui refusent de faire du C/C++.
          Java a tellement été poussé par Sun à une époque que des dév' Java tu en as par camion entier de nos jours, malheureusement (et pour le bohnur des vendeurs de hardware, CPU autant que RAM)
          Au départ, les sociétés calculent que le camion de dévs Java coûtent moins cher que matos en plus, et quand ça doit scallait, il y a le poids de l'histoire qui fait qu'on ne change plus. Sun a été très fort sur le sujet.

          De la même manière, Facebook en est à devoir faire un traducteur PHP vers C pour ses camions de dévs PHP incapables de faire du PHP assez rapide et incapables de faire du C correct, le poids de l'histoire et du dévs pas cher par rapport au matos au début mais pas à la fin, encore…

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

          A part que les GC C sont en "labs", tu n'as pas démonté grand chose…

          PS : oui, j'ai encore le souvenir de bons de commandes à signer sur des achats de machines monstrueuses pour afficher 3 graphiques en Java… Ca va sans doute me rester jusqu'à la fin de ma vie.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: la réponse est évidente

              Posté par  . Évalué à 3.

              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 ?

              • [^] # Re: la réponse est évidente

                Posté par  . Évalué à 4.

                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.

                Ben justement, les pauses gc sur une UI, c'est redibhitoire a mon sens de se taper un freeze, meme de qq millisecondes.
                Alors, certes, concurrent gc, tout ca, mais c'est pas encore au top, et ca n'elimine pas toutes les pauses.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 3.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: la réponse est évidente

                  Posté par  . Évalué à 4.

                  Ben non, ce n'est pas vrai. La lib que j'ai fourni offre un gc largement utilisé, stable et performant, depuis 15 ans.

                  Bien sûr la R&D sur les gc s'est arrêté en 1995…

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à -1.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: la réponse est évidente

                      Posté par  . Évalué à 2.

                      Merci, d'avoir enlevé le contexte de mon post. Je répondais à un mensonge éhonté. Le 15 ans est la pour mentionner que les ramasse-miettes pour le C/C++ ce n'est pas une histoire nouvelle. Cela existe depuis longtemps, très longtemps.

                      J'ai peut être mal compris ta phrase. Qu'il y ai eu révolution ou pas en 15 ans (la différence entre révolution et évolution peut subtile). Les techniques ont largement évoluées et les performances avec. Ta phrase laisse penser que ça existe depuis 15 ans et que depuis c'est stable et performant. C'est comme tout c'est une technique qui évolue. Le plus évolué que je connaisse c'est G1 et il offre des possibilités qui n'ont rien avoir avec ce qui se faisait il y a quelques temps.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à -2.

                        Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: la réponse est évidente

                  Posté par  . Évalué à 5.

                  Tu t'énerves beaucoup, donc c'est durde savoir de quoi tu parles exactement, mais quand je lit ca:

                  Mettre à NULL aide le GC a ne jamais arriver au stade de faire une passe entière sur tout le graphe de flot de donnée.

                  Je me demande bien de quoi tu parles. Si tu parles du GC java, tu viens d'écrire une gigantesque connerie. Si tu parles de n'importe quel GC mark and sweep en fait, tu viens d'écrire une monumentale connerie (et j'espère bien que plus personne n'écrit de GC a retain count).

                  Si ta variable est locale et que tu ne t'en sert plus jusqu'a la fin de ton scope et que le JIT ne l'a pas deja optimised out (ca commence a faire pas mal de et la quand meme), certes, tu vas permettre a une potentielle passe du GC de la trouver avant la fin du scope.
                  Si tant est que le GC fait sa pause entre le moment ou tu penses avoir assigne ta variable a NULL et le moment ou le scope se serait fini et ou ton pointeur devient garbageable.
                  Oui, je dit "pense avoir assigne ta variable", parce que tu n'es pas sans savoir que le compile peut decider que c'est une idée a la con d'assigner NULL a une variable locale et virer l'instruction (et entre nous, c'est difficile de lui en vouloir de penser ca).

                  Si ta variable n'est pas locale, i.e. un membre vu que c'est un peu le seul moyen d'avoir une variable non locale en java, ben soit tu viens de fixer une leak gentillette (= vaguement equivalent a un malloc non balance par un free en c), en d'autre termes, un bug, soit tu viens de modifier le comportement de ton programme (i.e tu viens de créer un bug).

                  Bref, t'avoueras qu'au final le gain est maigre et vraiment hypothétique.

                  Sinon je veux bien que tu m'expliques en quoi le GC java va skipper les structures récursives ou profondément linkees (et surtout j'aimerais bien savoir ce qu'est une structure profondément linkee), sachant qu'il fonctionne surtout par generation, et qu'il va donc parcourir toute la heap appartenant a une generation.

                  Ensuite, le "on the fly progressif", comme tu dit, ca ne garantit pas de tout libérer, effectivement, et ca tombe bien, c'est le but. Le fait est que les jeunes generations meurent très jeunes et les vieilles ne meurent souvent jamais. En gros, des gens plus malin que toi se sont rendus compte que l'immense majorité des objets meurent soit très très vite, soit jamais.
                  Donc effectivement, tu ne libères pas tout en faisant une passe sur ta jeune generation, tu libères quasiment tout, et c'est bien le but.

                  En arriver à devoir du tuning aussi bas niveau que https://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues (premier lien en cherchant garbage collector performance dans google, je n'ai pas sélectionné, hein) est ridicule quand le but affiché du GC est de ne plus gérer la mémoire. C'est plus de travail de tuning qu'une allocation manuelle et tes moyens d'actions sont très limités.

                  Oui, parce qu'évidemment, gérer une heap de 8+GB avec du c++, c'est trivial, hein? D'ailleurs, FF n'a jamais eu de problèmes de fragmentation de heap qui gonflait en permanence son occupation mémoire, c'est bien connu!

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                  • [^] # Re: la réponse est évidente

                    Posté par  . Évalué à 4.

                    J'avais raté son message et je ne peux que te seconder dans le fait qu'il raconte un peu n'importe quoi sur ce point là.

                    Le seul cas où un passage à null pourrait changer quelque chose c'est un objet à vie courte dans la young gen qui serait tenu par un objet dans la old gen en attente d'être garbagé. En gros tu viens de créer un objet que tu passes en référence à un veille objet qui va mourir). En pratique j'ai pas souvenir d'un seul problématique comme cas comme ça. Ça ne veut pas dire que ça n'arrive pas, mais que ça pose pas de problème, faire un GC de la old gen ca n'a rien d'un problème.

                    sachant qu'il fonctionne surtout par generation, et qu'il va donc parcourir toute la heap appartenant a une generation.

                    Plus que ça. Pour pouvoir collecter la young gen tu as besoin de parcourir aussi toute la old gen pour trouver les références rentrantes vers tes nouveaux objets. En pratique c'est optimisé avec des dirty cards qui sont utilisé comme des write-barriers pour ne parcourir que les pages qui ont été modifiés depuis la dernière collection plutôt que toute la old gen.

                    Si tu veux voir un peu comment fonctionne réellement les collections de young gen chez Hotspot je te conseil d'aller faire un tour chez Alexey Ragozin. Il a fait pleins de bons articles sur le fonctionnement du CMS et ca doit être un des derniers à comprendre comment il fonctionne en détail vu que les devs se sont tirés de chez Oracle… Les talks de Gil Tene sont pas mal aussi.

                    • [^] # Re: la réponse est évidente

                      Posté par  . Évalué à 0.

                      La vache, on peut entendre son accent de l'est rien qu'en le lisant le pere alexey, pas besoin de connaitre son nom pour savoir de quelle region il vient :)

                      Interessant quand meme.

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: la réponse est évidente

              Posté par  . Évalué à 5.

              Il suffit d'aller un peu plus loin sur la page pour avoir une liste très partielle des utilisateurs http://www.hpl.hp.com/personal/Hans_Boehm/gc/#users . C'est à peu de chose la référence pour les logiciels libres.

              N'importe quoi. La référence pour les projets libres, quand on veut un GC, c'est d'utiliser un langage nativement à GC. Il n'y a à peu près aucun projet important dans ta liste, à part Mozilla et Mono, mais une courte recherche Google m'apprend que les deux références sont obsolètes :

              (et si les deux seules références que j'ai vérifiées sont obsolètes, le reste doit pas être bien frais non plus…)

              aucun GC ne bat ni se rapproche des performances d'une (dés-)allocation manuelle

              On s'en fiche. C'est comme dire qu'il ne faut pas programmer en C parce que l'assembleur roulé sous les aisselles est plus rapide. Au bout du compte, le temps gagné à ne pas écrire du code bas niveau et à ne pas traquer les bugs de gestion mémoire est du temps libéré pour d'autres tâches comme ajouter des fonctionnalités ou optimiser un algorithme important.

              Surtout quand on répond à un journal qui parle d'écrire une application graphique, c'est-à-dire un programme qui va probablement passer une grande partie de son temps dans du code externe (bibliothèque graphique, serveur d'affichage…).

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 3.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: la réponse est évidente

                  Posté par  . Évalué à 3.

                  Donc, au bout du compte, tu développes longuement en te reposant sur le garbage. Et à la fin, très fréquemment, tu te rends compte que le système laggue monstrueusement après quelques heures/jours d'utilisation parce que le GC à de plus en plus de mal sans aide.

                  C'est faux. Ce que tu décris c'est un code qui fait de la fuite mémoire écris par des développeurs qui s'imaginent que le gc supprime les fuites mémoire ce qui est faux. Un gc récent ne pause pas ce genre de problème. Par exemple en Java, tu sais qu'après un full-gc tu repars d'une mémoire propre. Si tu as ce genre de problème de performance c'est que quelque part tu garde des références vers des objets que le gc ne pourra donc jamais désallouer. Tu peut régler ça avec des reboot ou en nullifiant les références en question si tu n'a pas le temps de réfléchir au problème, mais en réalité c'est un problème de fuite mémoire, pas de garbage collector.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 2.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: la réponse est évidente

                      Posté par  . Évalué à 3.

                      On sait tous que le full-gc commence par un stop-th-world, mais tu semble affirmer que la situation empire avec le temps. C'est faux, elle est au pire cas juste avant le full-gc une fois ce dernier déclenché tu repars sur une bonne base. L'objectif principal des garbage collector c'est de rendre tout ça aussi court et prédictible que possible.

                      Le reboot c'est quand tu ne réfléchis pas. « Nullifier » c'est quand tu y as réfléchis. La fuite mémoire en java cela se résous à coup de nullification sur les objets de longue durée.

                      Je n'ai presque jamais connu de cas où il était nécessaire de nullifier et l'utilisation de références faibles à presque supprimé la totalité des cas d'utilisation (en fait mis à part si tu écris des structures de données je n'en vois pas l'usage).

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 0.

                        Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Re: la réponse est évidente

                          Posté par  . Évalué à 2.

                          On accumule un dette.

                          Il faut mettre ça en balance avec la fragmentation de la mémoire que peuvent produire les langages où l'on gère manuellement la mémoire. C'est aussi une dette qui va augmenter la pression sur la gestion de la mémoire. Une fois que le full-gc est passé, on a éliminé cette dette (on compact la mémoire). Pour un programme qui gère manuellement sa mémoire c'est bien plus compliqué.

                          Grosso modo quand on programme il faut connaître le modèle de mémoire et il y a un tas de technique pour réduire la pression sur la gestion de la mémoire. Java ou le C++ ne font pas exception, C++ va exploser si ça arrive (mais ça peut être insidieux et très difficile à debugguer) alors que Java va être lent (mais ça peut être insidieux et très difficile à debugguer).

                          Oui, les référence faibles aident la chose et permettent de faire du référence counting uniquement. Mais cela complexifie le travail du dèv. est cela rapproche (non ce n'est pas la même chose, je n'ai pas dit cela) de la gestion manuelle.

                          C'est un peu plus sophistiqué que du comptage de références ou du moins il y a un peu plus de possibilités. Tu parle des weak références, mais les soft référence peut aussi être très pratiques.

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: la réponse est évidente

                      Posté par  . Évalué à 2. Dernière modification le 28 octobre 2013 à 14:20.

                      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…)

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 2.

                        Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Re: la réponse est évidente

                          Posté par  . Évalué à 1.

                          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.

                          • [^] # Commentaire supprimé

                            Posté par  . Évalué à 3.

                            Ce commentaire a été supprimé par l’équipe de modération.

                          • [^] # Re: la réponse est évidente

                            Posté par  . Évalué à 4.

                            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…

                            Toi tu es resté à l'époque du C ;) tu peux très bien faire du char a[plop.size()]; (bon je ne recommande pas non plus, un vector est généralement plus indiqué ;)

                            Quand je code en c++, je fais très peu de new (et de delete associé), et je trouve que forcer les gens à réfléchir lorsqu'il font le new à la visibilité de l'objet en question, de sa durée de vie, et de la pertinence du new est une excellente chose, et dans le cas où le new est pertinent, voir si un conteneur est utile (shared_ptr, uniq_ptr…)

                            De plus, je persiste à penser qu'avoir un destructeur qui est appelé de manière prédictible est une excellente chose (fermeture de ficher, connexion, trace…)

                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                            • [^] # Re: la réponse est évidente

                              Posté par  . Évalué à 2.

                              Quand je code en c++, je fais très peu de new (et de delete associé) […]

                              Un peu quand même sinon c'est que tu alloue assez peu de mémoire.

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                              • [^] # Re: la réponse est évidente

                                Posté par  . Évalué à 2.

                                Une grande partie des objets sont crées comme ça Plop paco(truc);

                                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                • [^] # Re: la réponse est évidente

                                  Posté par  . Évalué à 1.

                                  Oui, merci c'est ce que l'on appel l'allocation sur la pile, mais la taille de la pile est limitée et bien plus petite que le tas (http://stackoverflow.com/questions/10482974/why-is-stack-memory-size-so-limited).

                                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                  • [^] # Re: la réponse est évidente

                                    Posté par  . Évalué à 2.

                                    Oui, et? Généralement si j'ai de grosse structure de données, elle sont stocké via de vector/map/set qui eux se chargent d'avoir l'allocation dynamique sans que moi j'ai à m'en charger.

                                    Si on en arrive à allouer toute la pile, c'est effectivement qu'il y a un soucis, mais jusqu'à présent je n'ai jamais eu ce soucis.

                                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                              • [^] # Re: la réponse est évidente

                                Posté par  . Évalué à 2.

                                Le truc, en fait, c'est qu'en C++, il n'y a pas que new, delete, malloc, calloc et free.

                                Il y a aussi… les smart pointer, qui évitent les delete ( parce que si le mot clé "new" implique la gestion de la mémoire, alors les dev java gèrent plus la mémoire que les dev C++ :p ).
                                Ajoutons à cela les collections, qui existent d'ailleurs aussi en java ( bien que mes usages épisodiques de java m'aient fait acquérir de la pitié pour ses utilisateurs quotidiens, sur ce point, mais ne changeons pas de troll… ) et il n'y a plus de problème.

                                D'ailleurs, l'un des derniers point qui forcent un dev C++ à gérer des raw pointers, ce sont les collections polymorphiques. Si un dev C++ utilise un pointeur en dehors, c'est qu'il estime que c'est plus simple que d'utiliser un autre mécanisme, mais un autre dev ne sera pas forcément d'accord.

                                Pour revenir sur les smart pointers, avant 2011, il n'y avait que auto_ptr, qui avait ses problèmes. Cependant, il m'aurait sûrement économisé pas mal de débogage si j'avais fait l'effort d'arrêter d'utiliser les pointeurs comme un dev C.

                                Et pour finir ce message, le C++ n'est pas le C. En C++ on ne gère pas la mémoire manuellement, on utilise la RAII. Quelques classes de bas niveau gèrent la mémoire, les autres n'y touchent jamais. On parle d'un langage qui permet de coder en bas niveau, ou en haut niveau, ou un mixe des deux. Je ne nie pas que ça ajoute de la complexité, surtout qu'on se coltine l'héritage du C, mais utiliser les possibilités du bas niveau pour dire qu'on est obligé de gérer la mémoire manuellement, c'est juste faux.

                    • [^] # Re: la réponse est évidente

                      Posté par  . Évalué à 6.

                      C'est exactement ça le problème. La mémoire se remplis de tout ce qui ne peut pas être libéré on-the-fly et à un moment, après une utilisation suffisamment longue, il y a un mark-and-sweep total qui a tendance à bloquer le truc en entier.

                      En fait les GC Java sont un poil plus malin qu'un bête mark & sweep stop the world et c'est assez intéressant de regarder comment CMS/G1/C4 fonctionnent exactement en pratique car ce sont les meilleurs GC actuels à ma connaissance. Très loin devant ceux des autres langages/runtimes. Je peux te filer des pointeurs si ca t'intéresse.

                      Dans le fond je serais moins "extremiste que toi". Un GC est pratique et fait le job dans 90% des cas. Maintenant il faut savoir le dégager quand y'a besoin et la dessus la sémantique de Java est mauvaise puisqu'il faut bidouiller alors que ca pourrait être plus clean. Après des produits mal branlés restent des produits mal branlés.

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 1.

                        Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Re: la réponse est évidente

                          Posté par  . Évalué à 3.

                          C'est ce que je dis, il me semble. C'est juste que quand tu arrives à la situation problématique cela revient plus ou moins à cela (un mark&sweep).

                          Non carrement pas. En fait on arrive à faire des full GC qui sont presque entièrement concurrents et parallèles. D'un point de vu jitter pour l'application, le full GC n'est pas pire qu'un minor GC, ca va juste occuper plus du CPU et pourrir temporairement tes caches CPU.

                          Par contre tu as quelques phases qui sont bloquantes, mais qui arrivent aussi en minor collection, et dont le temps d'exécution va dépendre de la tête de ta oldgen. Notament de sa fragmentation et de l'état des dirty cards. Ce qui fait que le full GC est rarement un problème, par contre tes performances se dégradent lentement jusqu'à ce qu'un full GC arrive.

                          Quand tu as ce genre de problèmes en général soit tu configures ton GC pour être aggressif et déclancher des full GC très tôt, soit tu forces des full GC reguliers via JMX. Les deux sont crados mais ca fait le job.

                          Je suis assez d'accord avec :

                          Je suis pas foncièrement en désaccord non plus. J'ai pas regarder rust en détail mais leur approche semble pas mal non plus.

                          Après je reste pragmatique par rapport aux outils actuellement disponibles et leur facilité d'utilisation/déploiement. Et surtout je n'oublie pas que je peux écrire du Java comme du C pour la gestion mémoire: je peux faire des alloc manuelle, je peux gérer mes alignements, je peux gérer ma contiguité etc.

                          La question qui se pose est donc:
                          - Quel est le meilleur outil pour écrire la majorité du code
                          - Puis-je atteindre les perfs visées pour le code qui a besoin d'être performant ? Exemple: Si j'ai besoin de SIMD Hotspot ne tient pas la route, mais je peux aussi sortir du C++ pour les 100 lignes de code qui en ont besoin ou tout faire en C++.

                          Maintenant si j'écrivais un jeu, je ne ferais clairement pas les mêmes choix que pour écrire du code backend.

                          • [^] # Commentaire supprimé

                            Posté par  . Évalué à 1.

                            Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: la réponse est évidente

                    Posté par  . Évalué à 4.

                    C'est faux.

                    Non c'est vrai (même si c'est pas aussi noir qu'il le dit)

                    Ce que tu décris c'est un code qui fait de la fuite mémoire écris par des développeurs qui s'imaginent que le gc supprime les fuites mémoire ce qui est faux. Un gc récent ne pause pas ce genre de problème.

                    Si. Sauf si tu as la chance de jouer avec Azul C4 (malheureusement on a toujours réussi à trouver des workaround avec CMS/G1 avant que quelqu'un veuille signer le chèque) tu finis par avoir des pauses conséquentes dès que ta heap grossie. En dessous de 4/6GB tu n'as aucun soucis. Au dessus les temps de pause peuvent rapidement devenir un problème en fonction de la latence maxi que tu veux obtenir.

                    Par exemple en Java, tu sais qu'après un full-gc tu repars d'une mémoire propre

                    Sauf qu'avant d'arriver à un full GC tes perfs peuvent se dégrader lentement et surement.

                    Pour te donner un exemple précis, on a eu le cas en prod sur un cluster Cassandra avec un CMS et >8GB de heap. Pas de full GC avant 2/3 jours par contre le stop-the-world des minors collections montaient lentement jusqu'à 3/5 secondes avant de qu'un full GC ne passe. Domage quand tu dois garantir des temps de réponse en dessous de 50ms…

                    mais en réalité c'est un problème de fuite mémoire, pas de garbage collector.

                    En vrai c'est un peu plus compliqué que ca.

                    Avec des heap non ridicules, c'est un mélange de bien comprendre comment fonctionne les différentes implémentations de GC (et je peux te garantir que très très peu de monde sait comment ca marche vraiment), le hardware, et de désigner son application pour être GC friendly en fonction de ses besoins précis. Entre une latence <1ms en HFT, un stock exchange qui prend en plus quelques millions d'ordres secondes, ou un gros batch data il y a un monde, mais tous demandent de savoir ce que l'on fait. Ca peut vouloir dire faire du garbage free dans certaines portitions, de faire du off-the-heap avec allocation/libération manuelle, utiliser des fly-weight, de réutiliser des zones mémoires préallouées avec des structures type ring buffer etc.

                    Bref le GC marche bien pour la plupart des besoins simples, par contre il faut savoir quand on va tapper ses limites et désigner en conséquence (et c'est un truc qu'on essai de faire assez tôt sinon tu pleures pendant longtemps). En Java les solutions sont assez crado mais ca se fait.

                    Maintenant les perfs ne se limitent clairement pas au GC et au layout mémoire. Par exemple tu vas avoir l'absence actuelle de SIMD qui peut faire très mal selon ce que tu fais. Tu vas aussi voir que pas mal d'API du JDK sont clairement pas orientées performances mais sont gardées par compat.

                    Bref comme souvent il y a un compromis à faire. Il n'y a pas de techno géniale ou tout est gratuit.

                    BTW: RedHat bosse actuellement sur un nouveau GC type C4 pour hotspot. A voir si il sorte un truc moins bouseux que G1.

                    • [^] # Re: la réponse est évidente

                      Posté par  . Évalué à 3.

                      Avec des heap non ridicules […]

                      Si tu parle de plus de 4Gio tu parle de logiciels qui utilisent plus de mémoire que la plus puissantes des machines que j'utilise. Je ne sais pas si c'est ridicule ou pas, je ne sais pas si les applications qui prennent tant de mémoire sont monnaies courantes ou pas (moi je n'en ai jamais rencontrée). J'ai travaillé surtout sur des systèmes distribués où l'on a 4Gio par nœud.

                      Bref le GC marche bien pour la plupart des besoins simples, par contre il faut savoir quand on va tapper ses limites et désigner en conséquence (et c'est un truc qu'on essai de faire assez tôt sinon tu pleures pendant longtemps). En Java les solutions sont assez crado mais ca se fait.

                      Je suis tout à fait d'accord.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: la réponse est évidente

                        Posté par  . Évalué à 4.

                        Si tu parle de plus de 4Gio tu parle de logiciels qui utilisent plus de mémoire que la plus puissantes des machines que j'utilise.

                        Tu vis dans quel siècle ? ;) C'est ce qu'avaient les stations ou nœuds des Grid le plus moisi il y a presque 10 ans !

                        Je ne sais pas si c'est ridicule ou pas, je ne sais pas si les applications qui prennent tant de mémoire sont monnaies courantes ou pas (moi je n'en ai jamais rencontrée). J'ai travaillé surtout sur des systèmes distribués où l'on a 4Gio par nœud.

                        Ça dépend vraiment ce que tu fais tant d'un point de vu hardware que config logicielle. Actuellement en général on tourne souvent entre 4 et 8GB de RAM par cœur.

                        Après tu as des tâches où tu vas faire tourner un processus par cœur et garder des heaps < 8GB, et d'autres ou tu vas avoir un gros processus parallèle qui va attaquer toutes les resources de la machine. D'autre encore où la plupart de la RAM ne sera pas utiliser par l'applicatif mais par le cache VFS. Pour les gros consommateurs de RAM tu as typiquement les DB qui vont avoir un cache applicatif en plus du cache VFS, les gros traitements de graphes qui vont plusieurs ordre de grandeur plus vite que si tu devais le faire en distribué, tout ce qui bosse entièrement in-memory plutôt que de toucher au disque.

                        Je ne bosse actuellement plus du tout dans le big data, mais même ailleurs on nous file de base des VM avec 64GB de RAM. Après pour des déploiements plus conséquent tu configures ton hardware en fonction des besoins. Mais la RAM c'est pas cher. J'ai déjà passé plus deux semaines à devoir tordre et optimiser des gros batch map/reduce pour que ca passe sur une petite heap alors que le design, l'implémentation et le tuning étaient déjà parfaitement gaulés pour être efficace pour le problème. C'est pas très rentable à long terme…

                        Après il faut bien voir que tu n'as pas forcément besoin d'une énorme heap pour devoir faire une gestion propre de la mémoire ou bien comprendre les problématiques du GC. Ça se voit très facilement sur des grosses heap par ce que les pauses deviennent extrêmement importantes. Mais grosso modo dès que tu veux une latence bornée tu vas voir que ça arrive vite. Maintenant si tu as des heap à 1GB, sauf a avoir des bornes dans la dizaine de ms tu n'auras pas de soucis. Ça garbage vite…

                • [^] # Re: la réponse est évidente

                  Posté par  . Évalué à 3.

                  Ce que je dis c'est qu'avec un GC, on se retrouve très rapidement avec les mêmes problèmes que pour le C/C++.

                  Ben non, c'est faux. Avec un GC, tu n'as pas de fuite mémoire obscure parce que tu as oublié un free quelque part, tu n'as pas de crash obscur parce que dans tel cas imprévu il y a un double free, etc.

                  On se retrouve à devoir faire du tuning très bas niveau

                  Ah, oui, je vois, c'est pour customiser les enjoliveurs ? :-)

                  Sérieusement, du "tuning très bas niveau" sur un langage à GC, à part pour une application très exigeante, je ne vois pas.
                  (sauf si par "tuning très bas niveau" tu veux dire régler la taille maximale du tas)

                  Et à la fin, très fréquemment, tu te rends compte que le système laggue monstrueusement après quelques heures/jours d'utilisation

                  C'est qui "tu" ? Parce que personnellement, en Python et son système de GC rudimentaire, ça ne m'est jamais arrivé d'avoir un système qui "laggue monstrueusement" après quelques jours d'utilisation. Ça ne veut pas dire qu'il ne peut pas y avoir de problème, mais par rapport à la corvée que représente la gestion manuelle de la mémoire dans une application non-triviale, y a pas photo.

                  C'est le choix par défaut

                  Non, désolé, toujours faux. C'est le choix par défaut si tu veux un GC dans ton programme écrit en C.

                  Mais pour la majorité des gens, "utiliser un GC" implique "programmer dans un langage à GC natif". Et tes 98 paquets qui dépendent (en première approximation) du GC Boehm, c'est que dalle par rapport au nombre de paquets dépendant de Python, Java, Erlang, Ruby, etc. Rions un peu :

                  $ apt-rdepends -r python | wc -l
                  Reading package lists... Done
                  Building dependency tree       
                  Reading state information... Done
                  20067
                  $ apt-rdepends -r libgc1c2 | wc -l
                  Reading package lists... Done
                  Building dependency tree       
                  Reading state information... Done
                  229
                  
                  • [^] # Re: la réponse est évidente

                    Posté par  . Évalué à 0. Dernière modification le 02 novembre 2013 à 16:42.

                    Ce que je dis c'est qu'avec un GC, on se retrouve très rapidement avec les mêmes problèmes que pour le C/C++.

                    Ben non, c'est faux. Avec un GC, tu n'as pas de fuite mémoire obscure parce que tu as oublié un free quelque part, tu n'as pas de crash obscur parce que dans tel cas imprévu il y a un double free, etc.

                    Et si vous arrêtiez de mettre le C et le C++ dans le même sac? Ou alors, parlons de C/C++/ObjC/C#…
                    free( void* ) c'est du C. En C++, on utilise delete. Et encore, on ne devrait pas, on a un outil vachement plus puissant, et qui n'a quasiment aucun impact (et même aucun avec GCC -O3) nommé std::unique_ptr. Avec ça, pas besoin de free/delete.
                    Et donc, pas de double free/delete.

          • [^] # Re: la réponse est évidente

            Posté par  . É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

            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  . Évalué à 0.

              Juste comme ca luajit est tres proche des perfs du C quand celui-ci ne peut pas utiliser d'instruction vectorielle (cas quand tu ne compiles pas avec -march=native globalement).

              Et Java est extremement lent :-)

          • [^] # Re: la réponse est évidente

            Posté par  . Évalué à 4.

            Ben disons que les gens ont compris que ça sert à rien, donc pas courant, oui.

            Par les gens, tu entends ceux qui font du C, du C++, du Vala et du rust (plus d'autres), il reste tout de même les quelques personnes qui font du Java, du python, du perl, du ruby, du PHP, du C#, du go, de l'ocaml et du js qui n'ont pas compris. Si c'est d'une telle évidence, ça fait encore un paquet de monde d'horizon très divers qui se fourvoient.

            Je ne me risquerais pas à dire que l'un ou l'autre ne fonctionne pas. Ce serait totalement idiot et ferrait preuve d'une mauvaise foie sans limite tant les exemples sont nombreux pour montrer que l'usage d'un garbage peut très bien fonctionner, que la gestion manuelle de la mémoire aussi ainsi que d'autres variantes (comme les pointeurs intelligents du C++, je n'ai pas compris pourquoi ce n'est pas de ça dont il a était question immédiatement).

            De plus tu parle des garbages collectors comme si l'état de l'art n'avait pas évolué depuis 1995 c'est totalement faux, il existe différentes familles de garbage collector (la plus connue étant les gc générationnels) et plusieurs continues d'évoluer. G1 qui est le gc officiel de Java7 est extrêmement sophistiqué et n'a aucun rapport avec ce que l'on pouvait trouver il y a quelques années.

            Mais tout ça te passe bien au dessus, non seulement tu parle de choses que tu ne connais pas, mais surtout que tu ne souhaite pas connaître. Le problème ce n'est pas que tu semble ignorant en la matière¹, mais que tu répand celle-ci avec fierté.

            [1] : j'espère que tu es simplement ignorant parce que sinon c'est volontairement du FUD et de le désinformation

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: la réponse est évidente

          Posté par  . Évalué à 2.

          Concernant Hadoop, le choix de Java n'est pas du tout dicté par les performances à mon avis. Hadoop c'est performant en sortant l'artillerie lourde, tu spammes du serveur en te disant que de toute façon ça coute pas si cher et que programmer un truc plus adhoc et vraiment taillé pour la tache en question serait plus couteux. Derrière il y a un gâchis de ressources assez phénoménal (je parle de ressource en terme de puissance de calcul, pas du coût économique).

          • Pleins de machines potentiellement différentes avec des environnements pas tous identiques -> une VM ça facilite bien la vie.
          • Une VM -> du contrôle assez fin pour le système sur ce que le programme a le droit de faire
          • Besoin de beaucoup de petites fonctionnalités présente dans le jdk (réseau, compression, serialization, hashing, logging…)
          • Beaucoup d'existant -> difficile de changer.

          Je ne crois pas que l'implémentation de Google soit en java par exemple.

          En outre, je crois qu'on parlait d'UI… Quand un job hadoop de 2 heures freeze pour passer le GC pendant 5 min, ça ne fait pas le même effet que quand une UI ou un serveur devant répondre fait la même chose.

  • # Python et perfs

    Posté par  (site web personnel) . Évalué à 10.

    Dans ton paragraphe, le principal reproche que tu fais à python, c'est qu'il est 5 à 10 fois plus lent que du C++. Et là tu propose plein de trucs pour l'accélérer.

    J'ai envie de te dire : oui, python est bien plus lent, et alors ?
    À moins que tu fasse du calcul intensif, je vois pas en quoi ça serait gênant.

    • [^] # Re: Python et perfs

      Posté par  . Évalué à 1.

      C'est du vécu, la lenteur de Python peut devenir problématique. Même mettre à jour un TreeView GTK+ (contenant environ une centaine d'items) à partir de données provenant d'un backend C peut devenir
      lent. Peut-être que les bindings GTK+ pour Python sont mal codés, je ne sais pas ce que ça aurait donné en Qt mais je suspecte tout de même Python.

      Dans l'exemple que je donnais dans mon journal, il ne serait pas envisageable d'écrire la partie client bittorent en Python, ce serait trop lent. Alors que si on opte pour Java, il est possible de tout écrire en Java sans se casser la tête.

      Il me semble qu'il avait été rapporté ici le cas du clavier virtuel d'Ubuntu qui était ridiculement lent et consommait énormément de mémoire au rapport de sa fonction.

      De manière générale, dans une application graphique, la latence (c'est à dire le temps de réaction de l'interface à une action utilisateur) est importante. Une différence que quelques dizaines de millisecondes est perceptible (ça en rend pas l'interface non fonctionnelle mais laisse l'impression que le logiciel est lent). Alors même si on ne fait pas de calcul intensif, la lenteur de Python est problématique. Et c'est sans compter le packaging et le fait qu'il soit typé dynamiquement.

      • [^] # Re: Python et perfs

        Posté par  . Évalué à 4.

        Dans l'exemple que je donnais dans mon journal, il ne serait pas envisageable d'écrire la partie client bittorent en Python, ce serait trop lent

        Deluge est écrit en Python et ce n’est pas spécialement lent.

        • [^] # Re: Python et perfs

          Posté par  . Évalué à 4.

          Non.

          C'est exactement le cas que je décris. La partie client bittorent de Deluge est écrite en C++, c'est la libtorrent-rasterbar. C'est certes une bonne solution mais ça oblige à écrire des bindings .so/Python ou C,C++/Python. Dans le cas de la libtorrent, ce n'est vraiment pas un problème : écrire une un client bittorent est beaucoup plus long et difficile que d'écrire un binding python pour une bibliothèque déjà existante.

          Cependant, quand on code tout soi-même, on apprécie de tout faire dans le même langage et ne pas avoir un process de compilation trop compliqué.

          • [^] # Re: Python et perfs

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Le client bittorrent "historique" (que l'on pourrait considérer du coup comme une preuve de concept), conçu par le créateur du protocole lui-même, était lui aussi écrit en Python (avec le client graphique en PyGTK si je me souviens bien).
            Bon, fallait lancer un client par fichier .torrent, mais ça marchait très bien, et ce fût longtemps le seul client dispo pour aller récupérer des films de vacances sur suprnova.

            • [^] # Re: Python et perfs

              Posté par  . Évalué à 0.

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

          • [^] # Re: Python et perfs

            Posté par  . Évalué à 2.

            Cependant, quand on code tout soi-même, on apprécie de tout faire dans le même langage et ne pas avoir un process de compilation trop compliqué.

            Pfff. L'expérience montrera que beaucoup de développeurs aiment "se faire plaisir"…

      • [^] # Re: Python et perfs

        Posté par  . Évalué à 1.

        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.

  • # J'en pense que

    Posté par  . Évalué à 4.

    Oublier la mémoire est une mauvaise idée; Je le vois tous les jours sur une aplli java, personne ne sais d'où vient un objet sa durée de vie et s'il est un jour déréférencé, résultat, le code fuit, et personne ne sais comment régler le problème.

    Masquer les problème n'est généralement pas une bonne solution; cependant si tu veux retrouver la problématique java et oublier les pointeurs, passe tout via shared_ptr<>, et tu récupère un comportement semblable à java. (avec un ramasse miette probablement pas aussi efficace)

    Cela fait des années que c++ offre des conteneurs de pointeur rudement utile, avec la possibilité de faire des actions lors de la destruction d'un objet, exécuté à un endroit prévisible.

    Si pour toi coder en c++ est compliqué fuit le java, depuis les annotations c'est devenu la foire aux bibliothèque faisant tout, sauf ce que le dev veut et il fait des hack immonde pour utiliser la moitié des fonctionnalité des annotation, sauf pour une propriété, rendant le code encore plus abscons qu'un script perl maintenu sur 10 ans, ou un script python sur 8 ans.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: J'en pense que

      Posté par  . Évalué à 9. Dernière modification le 25 octobre 2013 à 16:20.

      Je le vois tous les jours sur une aplli java, personne ne sais d'où vient un objet sa durée de vie et s'il est un jour déréférencé, résultat, le code fuit, et personne ne sais comment régler le problème.

      C'est sûr que si tu as affaire à des développeurs java qui ne connaissent rien de la gestion mémoire de Java, et qui ne savent pas profiler une application pour voir d'où une fuite peut provenir, tu risques d'obtenir des appli toutes pourries.
      Ne pas avoir à se préoccuper sans cesse des allocations / désallocations, ça ne veut pas dire n'avoir aucune idée du fonctionnement de la JVM et des cycles de vie des objets.

      Si pour toi coder en c++ est compliqué fuit le java, depuis les annotations c'est devenu la foire aux bibliothèque faisant tout, sauf ce que le dev veut et il fait des hack immonde pour utiliser la moitié des fonctionnalité des annotation, sauf pour une propriété, rendant le code encore plus abscons qu'un script perl maintenu sur 10 ans, ou un script python sur 8 ans.

      J'espère quand même que le code est moins abscons que ta phrase. Les annotations sont juste un formidable outil. Taper sur l'outil parce qu'il est mal utilisé par certains, ça n'a pas de sens.

    • [^] # Re: J'en pense que

      Posté par  . Évalué à 9. Dernière modification le 25 octobre 2013 à 16:32.

      Merci, tu ensoleilles mon vendredi :-)

      Bon déjà shared_ptr<> c'est certes bien mais ça n'est sûrement pas un ramasse miettes complet (c'est un peut comme si tu comparais un moteur de voiture avec une voiture complète). Il faut toujours se préoccuper de problèmes comme la rule of three, se demander si on veut passer les objets par copie ou par référence. Il faut aussi gérer les .hpp et .cpp, se casser la tête parce qu'on doit faire des forward déclaration de classes si on a des dépendances circulaires. L'héritage en C++ n'est pas aussi simple qu'en Java : il faut se préoccupper de déclarer ses méthodes virtual (et ses destructeurs hein pour éviter les fuites) , regarder comment on caste les shared_ptr<> si on en utilise. Sans compter les cas où les exceptions se marient moyennement bien avec la gestion manuelle de la mémoire. Je pourrais continuer comme ça pendant des heures.

      Bref, coder en C++, c'est dur. Bien plus dur que coder en Java. On devrait coder en C++ uniquement quand on a besoin du gain de performance apporté.

      Tu dis que ne pas gérer la mémoire à la main, c'est masquer les problèmes. Certes, mais c'est bien le sens de ce qu'on fait en informatique depuis 30 ans, non ? Le C masque l'assembleur et le fait que mon processeur à des registres et qu'il faut aller chercher des trucs de la mémoire pour les mettre dans des registres. Même chose pour les systèmes d'exploitations qui masquent le matériel et offre des API unifiées.

      Et honnêtement une application en C++ a mille fois plus de chances de fuire qu'une application codée en Java. Certes l'application Java utilisera certainement plus de mémoire à la base, mais le ramasse-miette limite franchement les erreurs de programmation.

      Concernant les bibliothèques Java utilisant de manière excessivement les annotations, tu n'es pas obligé de les utiliser.

      • [^] # Re: J'en pense que

        Posté par  . Évalué à -1.

        Bon déjà shared_ptr<> c'est certes bien mais ça n'est sûrement pas un ramasse miettes complet (c'est un peut comme si tu comparais un moteur de voiture avec une voiture complète).

        ça c'est de la comparaison !!
        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 !!!
        Ce sont des outils de gestion de la mémoire adapté à des problèmes particuliers, mais tes miettes ne seront jamais ramassées par eux.
        Le mieux, c'est comme au lit, il ne faut pas faire de miette, même en buvant son café…

        Bref, coder en C++, c'est dur. Bien plus dur que coder en Java. On devrait coder en C++ uniquement quand on a besoin du gain de performance apporté.

        J'ai énormément de mal à coder en Java, alors qu'en C++, les choses s'écrivent simplement pour moi.
        Du coup, c'est peut-être pas aussi simple que ça, et ça dépends aussi un peu du dévelopeur, de sa façon de faire, de son expérience, de sa culture, ….

        Pour le reste, oui, en c++ généralement, il faut savoir ce que l'on fait.
        Ça n'en fait pas un langague plus dur. 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.

        • [^] # Re: J'en pense que

          Posté par  . Évalué à 5.

          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.

          • [^] # Re: J'en pense que

            Posté par  . Évalué à 2. Dernière modification le 28 octobre 2013 à 13:46.

            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 ?

            Parce que tu as dit "ça n'est sûrement pas un ramasse miettes complet" et que tu as enchainé avec la comparaison voiture indispensable à toute explication informatique.
            Moi ce que je dis, c'est que ça n'est pas un ramasse miette tout court ! de près comme de loin !! Sinon tu peux aussi considerer new et delete comme des ramasses miettes.

            Pardonne mon agressivité, mais on s'en fiche de ton cas personnel.

            C'est pour cela qu'il y avait une seconde phrase après.. faut lire jusqu'au bout aussi…

            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.

            Les profs d'informatique et étudiant ne sont pas des développeurs pour moi. Pour chaque prof que j'ai eu, le langage qu'ils enseignait était le meilleur de tous, avec arguments.
            Tu comprends bien que même sans connaitre les arguments en question, il y a une impossiblité quelque part…
            Ensuite, pour le "C++ est plus difficile à utiliser/maitriser", je suis d'accord qu'il est un peu plus dur à maitriser que d'autres langagues. Mais là, on parlait d'utilisation, pas d'apprentissage ! Donc non, je ne suis pas d'accord.

            Pour la fin, tu sors les même arguments que mes profs "qui s'y connaissent" :
            en c++, c'est la merde, tu peux faire n'importe quoi. Mais dans mon super langage, tout va bien !! Bien sur, il faut éviter de faire n'importe quoi.. mais quand tu as compris et maitrisé les concepts 1, 2, 8 et 43, franchement, c'est nickel !
            Et bien c'est pareil en c++ ! Y'a peut être un peu plus de concepts, ils sont peut-être un peu moins usuel quand on est habitué à d'autres choses, mais compte les personnes qui font n'importe quoi en C++ et celles qui font n'importe quoi en java, je pense que la proportion ne dois pas être si différente que ça.

            • [^] # Re: J'en pense que

              Posté par  . Évalué à -4.

              j'execre le java, la moindre application prend une quantité de mémoire allucinante et se met à ramer pour aucune raison (si, ce foutu ramasse miette se déclanche).

              Pour moi un VRAI language à une instruction delete, car je sais quand je veux détruire ma variable, ou alors je veux faire confiance à un shared_ptr pour le faire pour moi, mais je sais quand la variable va etre détruite. Un garbage collector ok, mais quand JE le veux.

        • [^] # Re: J'en pense que

          Posté par  . Évalué à 2.

          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.

          Ben c'est un peu comme comparer un moteur de voiture avec… ok ---->[] je sors

      • [^] # Re: J'en pense que

        Posté par  . Évalué à 2.

        Merci, tu ensoleilles mon vendredi :-)

        :D C'était le but ;)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: J'en pense que

        Posté par  . Évalué à 1.

        comme dans tout language, il faut de la rigueur (donc la connaissance du language). Avec rigueur, on peut faire un code en c++ très efficace et très maintenance, bien modulé avec des beaux tests unitaires et une doc qui s'autogénère, gérer avec les shared_ptr tout ce qui va bien sans perdre de vue quand va etre détruit telle objet.

        On peut faire du gros paté en C++ ou en python ou en ocaml. Après, il faut suivre des règles de codages qui aident à rendre le code propre et maintenable.

    • [^] # Re: J'en pense que

      Posté par  . Évalué à 5.

      Oublier la mémoire est une mauvaise idée

      c'est une mauvaise idée… en C++…

      depuis les annotations c'est devenu la foire aux bibliothèque faisant tout, sauf ce que le dev veut

      ben parlons des bibliothèques C++ alors… ah j'oubliais, on ne sait jamais comment elles gèrent la mémoire donc on évite de les utiliser (c'est bien vendredi ?)

    • [^] # Re: J'en pense que

      Posté par  (site web personnel) . Évalué à 4.

      Oublier la mémoire est une mauvaise idée; Je le vois tous les jours sur une aplli java, personne ne sais d'où vient un objet sa durée de vie et s'il est un jour déréférencé, résultat, le code fuit, et personne ne sais comment régler le problème.

      Et les codeurs qui ont pondu ça deviennent magiquement meilleurs lorsqu'ils programment en C++ ?

      • [^] # Re: J'en pense que

        Posté par  . Évalué à 2.

        Et les codeurs qui ont pondu ça deviennent magiquement meilleurs lorsqu'ils programment en C++ ?

        Non les codeurs qui ont pondu ça n'essayent même pas le c++, ou utilisent les shared_ptr à tout va, ce qui revient au même; mais on peut toujours utiliser un truc qui s'appelle valgrind qui marche plutôt bien pour repérer les connerie qui traine ;)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: J'en pense que

          Posté par  . Évalué à 2.

          mais on peut toujours utiliser un truc qui s'appelle valgrind qui marche plutôt bien pour repérer les connerie qui traine ;)

          La JVM possède tout ce qu'il faut pour ça aussi.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: J'en pense que

            Posté par  . Évalué à 2.

            La jvm est capable en fin d'exécution de me dire quel objet est encore alloué avec le chemin qui a conduit à son allocation? Si oui je veux savoir comment faire ;)

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: J'en pense que

              Posté par  . Évalué à 2.

              Avec MAT tu peut voir chaque objet en sachant qui le référence. Il ne permet pas directement de savoir comment il a était alloué par exemple si tu fait :

              int i = Random.nextInt();
              MyObject o = (i % 2 == 0) ? new MyObject() : MyObject.factory(i);
              i = Random.nextInt();

              Tu ne pourra pas faire grand chose (c'est pas non plus un cas que j'ai rencontré). Il se base sur un dump de la mémoire et ne donne donc qu'une image à un moment donné de l'état du programme, c'est suffisant dans tous les cas que j'ai rencontré). Sinon je pense que ça deviens plus compliqué et qu'il faut regarder s'il n'y a pas des alternatives à la jconsole qui soit plus performant et donnent plus d'informations (Oracle à fourni des outils récemment qui vont dans cette direction je crois mais je n'ai pas regardé plus en détail).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Qt/C++

    Posté par  . Évalué à 5.

    Il faut quand même savoir qu'en Qt, une partie de la gestion mémoire tu ne la gère pas totalement toi même;
    Si tu a bien lié tes objets, la destruction d'une fenêtre par exemple, s'occupe de détruire les boutons qui sont a l’intérieur…

    Certe a l'origine, ça reste du C++, mais une appli Qt/C++ c'est pas aussi compliqué que du pure C++ habituel.
    En faite, si ton appli est surtout graphique, tu n'aura que peu de contrainte lié au C++…
    Les macro Qt comme connect permettent de faire une grosse abstraction de ce qui est habituellement compliqué en C++.

    Biensur, ce n'est pas aussi simple que du python, mais franchement, c'est agréable a coder…

    • [^] # Re: Qt/C++

      Posté par  . Évalué à 1.

      Je confirme, coder en Qt/C++ est largement plus simple qu'en C++/boost par exemple. La stack Qt facilite énormément de choses, l'API ressemble à du PHP.
      De plus maitriser Qt permet de développer n'importe quel type d'application, serveur, desktop, ou smartphone depuis peu (Android, voir iOS).

      • [^] # Re: Qt/C++

        Posté par  . Évalué à 10.

        l'API ressemble à du PHP.

        Tu sais que ce n'est pas vraiment convaincant ça ?

        • [^] # Re: Qt/C++

          Posté par  . Évalué à 1.

          Oui enfin je voulais dire au niveau de la simplicité :)

          • [^] # Re: Qt/C++

            Posté par  . Évalué à -1.

            tiens moi j'aurais comparé avec java parce que Qt c'est assez lourd…

  • # JavaScript sans HTML5...

    Posté par  (site web personnel) . Évalué à -1.

    … c'est possible, avec XUL(Runner).
    Pour avoir une idée de ce que ça donne en terme de portabilité et de ce que l'on peut réaliser avec, il suffit de lancer Firefox. Et pour ceux qui préfèrent utiliser C++ au lieu de JavaScript, c'est également possible. Sachant que l'on peut également utiliser C++ pour coder une application Android (ainsi que iOS), étant partisan du moindre effort, mon choix a été vite fait :-) !

    Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

    • [^] # Re: JavaScript sans HTML5...

      Posté par  . Évalué à 7.

      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.

      • [^] # Re: JavaScript sans HTML5...

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        j'ai pas l'impression qu'il soit très utilisé de nos jours

        Il y a encore pas mal d'appli.
        https://developer.mozilla.org/en-US/docs/XULRunner_Hall_of_Fame

        Bon ok, c'est peu comparé à du QT ou gtk…

      • [^] # Re: JavaScript sans HTML5...

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

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

        Disons que cette technologie s'est transformée. Pour rappel, une appli lancée par XULRunner, c'est une appli avec des fichiers XUL (du HTML like +++++, sous stéroïde), CSS pour le design et javascript pour le code. Voir du C++ pour des composants bas niveau (XPCOM) permettant de fournir des API au niveau JS (pratique aussi pour intégrer des libs binaires externes).

        Pour l'aspect "appli lancée depuis mon bureau", Mozilla s'est tourné vers les webapps : une appli web peut ainsi être lancé en dehors du navigateur (mais avec son moteur), grâce au "web runner" (cf webapprt-stub dans le dossier Firefox). Techniquement, webapprt n'a pas énormément de différence avec l’exécutable xulrunner ;-)

        Pour le langage XUL: beaucoup de choses ont été porté/spécifié vers HTML5 et CSS (en particulier le modèle de boite CSS : flexbox model).

        Pour le language XBL (qui permet de faire des composants d'interface réutilisables): après un échec de standardisation de XBL2 il y a quelques années (trop complexe pour les implementeurs), la spec XBL2 a été découpée en plusieurs specs. On obtient les web components (shadow dom + templates html + scope CSS + …). En cours d’implémentation & spécification, dans chrome et firefox.

        Et les webapi, permettent de remplacer l'appel à certains composants XPCOM de la plate-forme.

        Bref, ce que proposait XULRunner (et propose toujours), préfigurait les technos d'aujourd'hui et de demain au niveau web ;-)

        Même si aujourd'hui, on fait encore des choses largement plus puissantes avec XulRunner qu'avec les seules technos du web (HTML5…). Un navigateur scriptable par exemple ;-)

  • # Tu as oublié une possibilité

    Posté par  . Évalué à 10.

    Tu as songé à Qt/QML ?

    Ça ne t'empêchera sans doute pas de faire un peu de C++ pour certaines parties du code, mais la partie QML permet de passer une bonne partie du code de gestion graphique vers du JavaScript.

    • [^] # Re: Tu as oublié une possibilité

      Posté par  . Évalué à 1.

      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.

      • [^] # Re: Tu as oublié une possibilité

        Posté par  . Évalué à 2. Dernière modification le 25 octobre 2013 à 18:15.

        Tu peux consulter la liste des modules QML. Qt 5.1 a apporté son lot de composants graphiques clés en main, y compris la gestion des fenêtres (module QtQuick.Window), et autres contrôleurs thémables dont des éditeurs de texte et autres boutons (module QtQuick.Controls). Les arbres se font par liste récursives, plus ou moins, et il n’y a pas de contrôleur spécial prévu pour en développement. Créer ses propres contrôleurs QtQuick entièrement en QML est trivial.

        • [^] # Re: Tu as oublié une possibilité

          Posté par  . Évalué à 2.

          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.

  • # QML et JavaFx

    Posté par  . Évalué à 5.

    En restant dans le monde Qt, il est possible d'écrire l'IHM avec le langage dédié QML. C'est une approche fortement déclarative, qui a ses forces et ses faiblesses. Le gros atout, c'est que ce que l'on ne peut pas faire avec QML, on peut toujours le faire en revenant au C++ au cas par cas.

    http://qt.digia.com/Product/Qt-Core-Features--Functions/qt-quick/

    Côté Java, Swing est effectivement un candidat à ne pas négliger. Personnellement j'ai rarement été limité par ce toolkit, et le résultat est très chouette autant avec le look and feel natif qu'avec Nimbus (le look and feel multiplateforme). Si j'avais à réaliser une IHM en Java aujourd'hui, j'évaluerai JavaFx 2 qui est sensé être le successeur de Swing, et qui (quand je m'y était intéressé) semblait très prometteur.

  • # kivy et Python

    Posté par  (site web personnel) . Évalué à 8.

    Je suis en train de regarder kivy
    http://kivy.org/#home

    Il y a même un kivydesigner
    https://github.com/kivy/kivy-designer

    L'idée de développer une seule fois pour Linux, Mac, Windows, Tablette, Android, Ios est séduisante.

    ウィズコロナ

    • [^] # Re: kivy et Python

      Posté par  . Évalué à -3.

      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.

      • [^] # Re: kivy et Python

        Posté par  (site web personnel) . Évalué à 5.

        Kivy n'est pas aussi "grand" que Gtk ou Qt oui. Mais ce n'est pas nouveau et existe depuis 2008, précédemment sous le nom PyMT. La communauté grandie, et le nombre d'application personnelles et commerciales aussi. Une mini liste est disponible sur le wiki, dont quelques unes sur le Google Play. On participe aussi au Google Summer of Code depuis 2008: le designer est d'un étudiant de cette année.

        On bosse sur les toolchains pour compiler Python et certaines extensions sur Android via python-for-android et Kivy-ios. Mais même avec une documentation qui indique toutes les étapes pour le packaging, cela reste trop compliqué pour certain (installer les dépendances, le SDK et NDK d'android, etc.).

        C'est aussi pourquoi nous avons commencer un outil nommé buildozer, qui se charge de tout, mais ne marche que pour pousser son application sur android, et ios. On a tenté aussi une approche web avec un cloud builder où tu balances ton code source et quelques paramètres, et tu reçois par email un APK de debug ou non-signé.

        Ah, dernier point dont tu ne te poses pas la question sur ton journal est: comment accéder aux API natives si on utilise pas le language natif? Si le framework/langage utilisé ne te le permet pas, tu te retrouves à faire du natif. (indices: intégration Google Maps / Google Play Service / Twitter / Facebook / Camera / Intents…). Pour Java, on a créé Pyjnius, qui permet d'appeler dynamiquement via JNI du Java en Python, ou implémenter des classes d'observers en Python. Pour Objective-C, Pyobjus est en cours, et le dernier GSOC a permis de combler pas mal de blancs, et utiliser l'accéléromètre sur iOS.

        Bref, c'est un journal de troll oui, mais bon. :)

        • [^] # Re: kivy et Python

          Posté par  . Évalué à 2.

          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 :-)

  • # Java/SWT

    Posté par  . Évalué à 3.

    En Java, il y a aussi SWT. Et pour modifier ses UI (SWT ou Swing) graphiquement sous Eclipse, il y a WindowBuilder. Pour Swing en tout cas, cet outil génère un code lisible, sans lignes superflues (pas comme NetBeans avec ses fichiers XML).

  • # Déprimant

    Posté par  . Évalué à 5.

    Dans un précédent journal, je répondais à la question "Gtk ou Qt" sur le ton de la plaisanterie: celui des deux qui a un binding pour le langage que tu utilises.

    Et du coup, Gtk est encore très très utilisé parce que les bindings Gtk, c'est pas ce qui manque. Par contre, en Qt, on a le non-choix:
    -C++ (forcément)
    -Java, mais vu la gueule du Java autant faire du C++ directement?
    -Python mais ça va ramer à mort
    -d'autres bindings plus ou moins bien maintenus que je me lancerais pas là-dedans à ta place!

    Donc Qt est formidable, multiplate-forme, et… élitiste!
    Hors C++, c'est pour les bricolos?

    Tout le monde n'a pas envie de choisir entre devenir un super expert sur le fonctionnement du CPU et des allocations mémoires et des standards C++ d'un côté, ou se cantonner à des trucs légers sinon ça rame à mort parce que "Python" de l'autre.

    Je trouve incroyable que Qt soit si populaire en ayant si peu de bindings officiels et bien documentés!

    • [^] # Re: Déprimant

      Posté par  . Évalué à 2.

      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 ?

      • [^] # Re: Déprimant

        Posté par  . Évalué à 7.

        Bon, d'une je suis pas codeur, je serais plutôt, au mieux, un bricolo pour de vrai.
        De deux, j'ai utilisé peu de langages dans ma vie, et un seul par "plaisir".
        Le R parce que les stats me sont utiles au taf. Et j'ai codé une interface graphique en Tk (oui oui, simplement parce que j'avais pas besoin de me demander comment installer truc-machin si je devais envoyer l'appli à quelqu'un d'autre).

        Mais c'est un commentaire général. Je trouve qu'il y a un fossé entre la popularité et la puissance de Qt d'un côté et son accessibilité aux dévs en dehors de C++ et Python de l'autre. C'est fort dommage!

        Et effectivement, j'aime beaucoup OCaml, bien plus que tout ce que j'ai jamais vu. C'est sans doute parce que ça a l'air plus "mathématique" que "mains dans le cambouis du CPU". Mais on va dire que c'est une coïncidence:
        Je n'ai jamais regardé les bindings Gtk de OCaml.

        Non, si je devais te citer une référence, je dirais… Tk! C'est vieux, obsolète, tout ce que tu veux, mais ça a le mérite d'être utilisable par tout le monde!

        • [^] # Re: Déprimant

          Posté par  (site web personnel) . Évalué à 1.

          Non, si je devais te citer une référence, je dirais… Tk! C'est vieux, obsolète, tout ce que tu veux, mais ça a le mérite d'être utilisable par tout le monde!

          Tk est largement sous-estimé à mon avis. Les plus gros manque est probablement l'absence d'un widget qui affiche du HTML: rien de très important. Sans vraiment bien connaître l'historique des toolkits, ils semblaerait d'ailleurs que GTK ait beaucoup repompé sur Tk, au moins les widgets texte et canvas.

    • [^] # Re: Déprimant

      Posté par  (site web personnel) . Évalué à 4.

      Je trouve incroyable que Qt soit si populaire en ayant si peu de bindings officiels et bien documentés!

      C'est parce que la majorité des développeurs sont contents de la version native C++ de Qt. Et donc le besoin de bindings est limité.

    • [^] # Re: Déprimant

      Posté par  (site web personnel) . Évalué à 8.

      C'est quoi ce préjugé sur Python ? C'est juste la répétition d'un mantra ou vous faites vraiment des applis avec ?

      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.

      Et j'utilise régulièrement le couple Python et Qt, et je n'ai jamais connu quelque chose d'aussi efficace.

      Quant au couple Qt/C++, le confort de programmation est très loin au dessus du C++ classique. Qt a une gestion de la mémoire très bien faite qui fait que en gros, l'allocation mémoire, tu n'as pas besoin d'y songer (sauf évidemment si la problématique mémoire est au coeur de ton appli, genre tu parse un fichier de 5 millions de lignes). Pour ce qui est de maitriser le CPU, je ne vois même pas à quoi tu fais allusion.

      Python n'est pas un langage élitiste et est très bien approprié pour un nombre extrèmement large d'application. 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.

      Par contre, pour ce qui est d'autres langages, c'est vrai que … bof. Je pense que c'est du à quelques facteurs assez simples:

      • C++ est déjà un langage majeur et une référence dans l'industrie. Cela permet d'adresser un panel extrèmement large de développeurs. Les ajustements que permet Qt vis à vis du C++ en font en plus un langage simplifié.

      • pour Gtk, le C est moins facile d'approche pour une application graphique, et donc il y a un besoin plus intense de trouver une alternative.

      • le binding Python est extrèmement bien maintenu de sorte, que il comble à mon sens le besoin de gens qui se détournent du C++.

      • au final, il reste trop eu de monde qui soit à la fois repoussé par le C++ et le Python et les autres bindings sont mort-vivants.

      D'ailleurs, sur Gtk, il y a force binding, mais combien contiennent 100% de la lib Gtk, sont basés sur la dernière version de Gtk, parfaitement documenté, stables ?

      • [^] # Re: Déprimant

        Posté par  . Évalué à 5.

        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.

        • [^] # Re: Déprimant

          Posté par  (site web personnel) . Évalué à 2.

          numpy et autre sont peut être implémenté en C mais ça reste des modules python. Python est un plutôt un langage, comme tu le mentionnes, qu'une implémentation. De même, le GIL concerne seulement CPython, une implémentation. Je t'accorde que la frontière est floue.

        • [^] # Re: Déprimant

          Posté par  (site web personnel) . Évalué à 9.

          Merci pour ce petit cours.

          Tu as lu le commentaire original qui dit "Python, ça rame". Je réponds juste en disant que non ça rame pas.

          Bien sur, faire du Python brut pour du calculatoire, ça rame. De même que si tu ecris un framework graphique type Qt ou Gtk en pur python, ça ramera aussi. Sauf que justement, Python vient avec tout un ensemble de bibliothèque prêtes à l'emploi, dont beaucoup ont déjà résolu le problème de la performance.

          Prenons le monde scientifique où le problème est plus visible. En suivant le raisonnement du commentaire, on prend pas Python parce que ça rame, et on part par exemple sur du C++. Sauf que dans les faits, en Python, le langage et les bibliothèques existantes permettront très vite d'arriver à code une appli, et numpy est suffisamment rapide pour répondre à la demande.

          Il est très probable qu'à vouloir coder un calcul scientifique en C++, l'auteur passera plus de temps d'une part à écrire son appli, d'autre part, à faire des calculs qui seront au final moins rapide que Python + numpy.

          C'est pour ça que j'insiste sur ce point: le langage Python a des perf inférieurs aux langages compilés, il y a pas de toute là-dessus. Mais dans la vraie vie, les applis Python marchent plutôt bien et vite, parce que des frameworks existent pour accélérer de base les parties critiques de ton application. Et quand ils ne suffisent pas, tu peux te concentrer sur les 1% qui ont besoin de perf maximale plutôt que sur la totalité de ton appli. Et au final, tu as un meilleur résultat.

          Donc le racourci, Python est lent donc les applis Python sont lentes, est un raccourci à deux balles !

  • # Golang

    Posté par  (site web personnel) . Évalué à 3.

    Si tu veux faire du go, il y a un début de support de QML en go : https://github.com/niemeyer/qml. C'est encore en version alpha, mais le début est encourageant.

  • # Quelle question !

    Posté par  (site web personnel) . Évalué à 5.

    Smalltalk/Squeak!

  • # Sinon

    Posté par  . Évalué à 1. Dernière modification le 25 octobre 2013 à 19:29.

    Sinon, une possibilité simple serait d'utiliser Python + TTK. C'est une bibliothèque incluse dans Python et qui reprend le thème de l'interface (c'est du tkinter relooké). Et d'ailleurs, pourquoi pas envisager Tk ? (je ne connais pas du tout)
    Les perfs, je n'en ai aucune idée, je ne fais pas d'interface graphique (enfin si, mais ce sont des trucs qui n'ont pas besoin de perf' de ouf et j'utilise le binding Qt, que je n'aime pas trop car il me fait perdre trop de temps pour des besoins simple).

    Ou alors, peut-être une interface web ? Un serveur à la cups. Je ne sais pas les besoins, c'est une possibilité, et niveau portabilité, y a pas trop de soucis à se faire.

    Si tu pars sur un gros logiciel, c'est dommage d'oublier le combo langage script (glue) + langage moins haut niveau plus performant. Les bindings type Cpython sont vraiment simple d'utilisation (je parle de ça parce que c'est ce que je connais le plus), et le coté interface est vraiment casse-couille à faire, je préfère déléguer ça à un langage de script pour le torcher vite fait bien fait, et me concentrer sur la logique, d'abord en python puis en optimisant par étape en descendant vers le C.

    • [^] # Re: Sinon

      Posté par  . Évalué à 2.

      […] 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.

      • [^] # Re: Sinon

        Posté par  (site web personnel) . Évalué à 2.

        Je n'ai pas spécialement eu de problèmes de perfs avec Python + Qt (PyQt et non PySide), en revanche j'ai eu (et j'ai toujours :( ) quelques rares problèmes de stabilité totalement aléatoire, notamment en utilisant des threads. Une bonne partie de ces problèmes ont été résolus en mettant à jour PyQt et Qt, mais il y en a toujours de temps en temps (et sans stacktrace, dans un produit un peu complexe, ce n'est pas évident de débugguer…).

        (sinon, il parle peut-être de ctypes, qui permet d'utiliser des libs C en Python)

  • # Puisque l'on en vient à proposer du XUL, du TK et même du Qt…

    Posté par  (site web personnel) . Évalué à 0.

    Je propose du Ncurses, c'est simple efficace. Très très performant, peu coûteux en mémoire (de toutes façons vous devez tout gérer car vous êtes un vrai développeur).

    Pour les plus paresseux, vous pouvez utiliser NDK++ qui est un kit de développement ncurses pour C++.

    Et ça fonctionne partout, Windows, GNU/Linux, Android, Mac os X…

    • [^] # Re: Puisque l'on en vient à proposer du XUL, du TK et même du Qt…

      Posté par  . Évalué à 1.

      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 !

      • [^] # Re: Puisque l'on en vient à proposer du XUL, du TK et même du Qt…

        Posté par  (site web personnel) . Évalué à 0. Dernière modification le 25 octobre 2013 à 20:42.

        Ncurses over HTML/JS, c'est comme une QTextEdit over HTML/JS : ça n'a pas de sens.

        Ou alors peut-être que c'est un processus créatif similaire aux émulateurs de veilles consoles en JavaScript. Par exemple : http://gmarty.github.io/jsSMS/

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

        • [^] # Re: Puisque l'on en vient à proposer du XUL, du TK et même du Qt…

          Posté par  . Évalué à 1.

          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 !

          • [^] # Re: Puisque l'on en vient à proposer du XUL, du TK et même du Qt…

            Posté par  (site web personnel) . Évalué à 1.

            En utilisant emscripen, une appli sans aucun côté web peut devenir une appli web. Une appli multiplateforme de base peut devenir doublement multiplateforme !

            Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

          • [^] # Re: Puisque l'on en vient à proposer du XUL, du TK et même du Qt…

            Posté par  (site web personnel) . Évalué à -4.

            J'adapte mes trolls à mes interlocuteurs.

            Pour Wireshark, j'aurais vraiment tenté de faire quelque chose en HTML5 si ça avait été à moi de développer. Ça aurait été un peu plus risqué, mais avec une innovation qui aurait provoqué plus de réactions que de simples «ah oui c'est plus joli sur mon mac».

            Maintenant vous semblez faire une fixation là dessus : «Ah l'autre il a dit qu'il faisait des IHMs avec du HTML !!». Du coup je vous conseille du Ncurses.

            Une analogie avec des voitures (c'est mignon les voitures et toujours parfait pour faire des analogies avec l'informatique) :

            Au lieu d'avoir choisi un moteur Diesel pour remplacer un moteur essence, j'aurais utilisé un moteur électrique. Le diesel ça pollue peut-être même plus que l'essence.

            • T'as raison, pour aller en vacances, l'électrique c'est idéal ! D'ailleurs t'as qu'à devenir constructeur automobile et proposer une voiture électrique, on viendra te voir au mondial de l'auto.
            • J'ai bien ri, mais rassures-moi, c'était bien une blague ?
            • Et sinon, tu connais l'Hybrid Diesel/Électrique ?
            • Moi j'aurais choisi une machine à vapeur, t'as vu j'ai trop de répartie car t'as autant d'arguments pour l'électrique que moi pour ma machine à vapeur.
            • L'électrique, c'est pas maintenable par rapport à du Diesel !

            Journal un peu plus tard : Quelle est la meilleure technologie de motorisation pour les véhicules terrestres ?

            Je cherche à concevoir une voiture, et voici les technologies que j'ai repéré :
            - L'essence
            - Le diesel
            - Le bois

            Merci de me conseiller, car je vais quand même pas faire de l'électrique lol.


            Du coup vous comprendrez que je conseille (ironiquement) de revenir à la charrette tirée par des chevaux.

  • # Interface graphique multiplateforme...

    Posté par  (site web personnel) . Évalué à 1.

    Selon mon prof d'IHM, tu peux t'en tirer avec Tcl/Tk.

  • # Oublie les bindings

    Posté par  . Évalué à 5.

    Oublie les bindings pour une "grosse" applis, ils sont toujours bloated (documentation inexistante, lents ou buggés, toujours en retard avec la version de la lib, migration impossible …)

    Du coup il te reste deux choix: Java/Swing ou C++/QT-QML. Et la ton choix devrait êtres vite fait suivant tes goûts pour Java ou C++. (oublie SWT: ca ne vaut pas le coup par rapport à Swing)

    Moi le C++ ça me saoule un peu (à part pour certains projets critiques ou "bas niveau"): gérer les .h/.cpp, les #ifdef #include, la compilation (-longue-), les versions de dll … c'est juste un boulot ingrat et inutile (on pourrait garder le même langage et supprimer tout ce bordel).
    Et puis quand ton programme pète tu n'a pas une belle stacktrace, il faut implémenter le destructeur, ne pas oublier le mot clef 'virtual' (ils ont vraiment choisi la pire convention …), la réutilisation de lib est contraignantes (l'une utilise la stl, l'autre QT, d'autres leurs propres implémentation de string voir juste char* …).

    Oui, Java c'est un peu plus lent au démarrage, mais au moins:
    * Il existe une librairie pour quasiment tout: des composants graphiques à la génération de PDF.
    * Toutes les libs utilisent les mêmes conteneurs, le même type String, unicode par defaut, le même type pour les sockets/l’accès au net, le même type pour l’accès au fichier, pour les regexp, …
    * La compilation et très rapide et faite avec des outils "sains"; Les projets sont facilement modulables.
    * Swing ça reste "joli/correct" avec le thème qui va bien (sauf sous Ubuntu …)

    Si tu veut êtres "bleeding edge", tente JavaFx (successeur de Swing), mais du coup tu te prive de l'immense bibliothèque de composants déjà créé en Swing …

    Note: Java c'est quand même bien loupé sur plusieurs choses: Le type "Date" tout pourris, l'absence de "multimedia" (manipulation et lecture de fichiers videos ou de musicaux), pas de type "Tuple<>" super pratique pour le retour de fonction, toujours pas de lambda/closure/… mais bon c'est déja des considération "haut niveau" par rapport à C++.

    • [^] # Re: Oublie les bindings

      Posté par  . Évalué à 4.

      Je me demande si Scala/Swing ne serait pas une bonne alternative:
      1) Scala est quand même plus sympa que Java
      2) appeler des librairies Java a partir de Scala est courant.
      Gros moins de Scala:la compatibilité d'une version à l'autre n'est pas assurée il me semble..

  • # Node.js pour pas ?

    Posté par  . Évalué à 2.

    Personne n'a rebondi sur node.js mais franchement pourquoi pas ? Et voire pourquoi pas avec Java/Netty?

  • # // ----> | |[*o*] [*o*]| |

    Posté par  . Évalué à 5.

    Est-ce tu penses que je devrais arrêter de me préoccuper de tout ça et coder mes interfaces graphiques en nodejs/HTML5 et communiquer avec mon bancked à travers HTTP WebSocket ?

    Oui totalement. Enfin, précisons pour les plus obstinés, qu'il y à certains outils pour certaines tâches.
    Mais que ces technos ont certaines caractéristique intéressante.
    Une relative ancienneté qui nous ont permis d'apprécier leurs capacités à tenter d'atteindre leurs objectifs de compatibilité à travers le temps et les appareils.
    Le positionnement occupé actuellement par ces outils dans l'environnement de la production logiciel les mettent de facto à l'épreuve des balles.
    Dès aujourd'hui il y à une myriade de personnes, utilisant ces technos, qui sont concrètement confrontées à ces problèmes, qui ont concrètement besoin de solutions.
    C'est une vague de fond accompagnée et vécue par des acteurs tels que mozilla, google et d'autres.
    Des acteurs qui sont expert et leader de ce domaine technique, mais aussi, dans un certain paradoxe, expert de ces lacunes puisqu'ils vivent ces outils.
    Ils sont donc les mieux à même de comprendre le défi et d'y apporter une solution.

    C'est déjà une bonne raison de donner un peu de crédit à ces solutions il me semble.

    Ensuite, je constate avec étonnement la capacité de cross compatibilité de ces outils au regard de l'environnement hétérogène qu'ils subissent.
    Je constate que si ils sont très bruts de décoffrages, la conception générale est saine, et que nous avons bien souvent était de piètres utilisateurs, pour diverses raisons.
    Je constate aussi les difficultés avec lesquelles certains nouveautés qui semble mineure se mette en place, mais c'est pour notre bien, c'est démocratique et cross/retro-compatible, tant que faire ce peut, par un moyen ou par un autre.
    La lenteur d’exécution par certains aspect, mais aussi la formidable amélioration qu'elle connait.
    Je constate aussi toutes les directions empruntées actuellement par ces technologies le cas nodejs côté serveur, et tellement de framework côté client pour tenter de répondre à la même question : comment produire des ihm toujours plus rapidement, simplement, qualitativement, plus sexy que les précédentes.
    Ce processus semble faire l'objet d'un tâtonnement permanent, par nature lent et difficile, mais tellement plus satisfaisant.
    L'open source dans cette histoire joue un très grand rôle, et le fait que Js et Css soient deux langages overwritable au runtime aide beaucoup ces technologies à littéralement partir dans tous les sens pour répondre aux problèmes.
    Là où Java centralise, unifie, et masque les problèmes de rétro compatibilité avec ces apis (du moins j'imagine sinon à quoi bon ?)**, dans le cas du web à 95% c'est réglé côté userland de manière totalement décentralisé, au choix des spécialistes du projet.
    En quelque sorte le web est encore une fois l'expression d'une certaine horizontalité, en comparaison Java serait une technologie qui illustre les anciens systèmes verticaux.
    Alors oui ça hack un peu, peut être beaucoup il faudrait comparer(…), mais les exemples de jquery/knockout nous montre que ces solutions sont concrètement fonctionnels.

    Le tableau d'est pas totalement et idyllique, mais le projet dans son ensemble est dynamique et supporté.
    Surtout, au regard de sa formidable disponibilité présente et future, il faut croire, amTha, que ces technos resteront supportées et continueront d'aller de l'avant.

    Est-ce que tu penses que le Windows/Linux/MacOS sont morts et qu'il suffit de maitrîser l'API d'Android ?

    Je ne la connais pas, je suppose cependant qu'elle fait le liant entre le matériel et l'interface par l'utilisation de webservice ? Ou ptet une api à utiliser dans un moteur v8, je ne sais pas.

    Je dois dire que l'idée d'une api unifiée cross compatible pour accéder aux ressources de la machine me séduit beaucoup.
    Ce serait la première brique posée pour produire une IHM d'OS pouvant reposer sur ces technologies comme pierre angulaire.
    Après faut voir la capacité de webgl à convaincre.
    Et enfin, ce sont les frameworks d'ui/ux qui séduiront les développeurs.

    Le chemin est encore long, mais je signe plutôt deux fois qu'une.

    ** j'ai un peu cherché, http://stackoverflow.com/questions/4692626/is-jdk-upward-or-backward-compatible, bref je ne sais toujours pas… :)

  • # sympa la slide

    Posté par  . Évalué à 5.

    La slide que tu cites est super intéressante.
    J'ai fais trois fois du c++ dans ma vie, je comprends maintenant que c'est juste pas fais pour moi.
    http://fr.slideshare.net/olvemaudal/deep-c

    Par contre la slide est très bisounours. Croire que le type lui demandera comment s'améliorer alors qu'il *** littéralement sur ces collègues deux slides avant est une vaste blague :)

    Mais elle a le mérite de soulever cette question de l'investissement nécessaire pour appréhender les subtilités d'une technologie qui sont nécessaires pour répondre aux exigences de qualité.
    Au final cela me semble moins casse gueule de le faire dans un environnement html.

  • # Vala

    Posté par  . Évalué à 4.

    Si tu n'as rien contre GTK+, tu pourrais regarder du côté de Vala.

  • # Mouton à 5 pattes

    Posté par  . Évalué à -5. Dernière modification le 27 octobre 2013 à 17:49.

    Cette question me vient de temps en temps à l'esprit : Existe-t-il un couple langage/IHM pour faire des logiciels de gestion qui soit complet (ne pas bidouiller pour faire du B.A. BA), facile à utiliser, à installer, rapide avec une bonne IDE et debuggeur.
    C'est le mouton à 5 pattes.

    Il y a toujours quelque chose qui pèche :

    QT widget date -> ne gère pas les dates à NULL (donc bidouille)
    QT widget checkbox -> ne peut pas être en lecture seule (donc bidouille)
    Python, ruby, C, C++ : erreurs dans les calculs simplissimes ex 0.1 + 0.7 = 0.79999999
    C, C++ : dans la longueur de chaînes de caractères ex "été" = 5

    Je n'en ai pas encore trouvé dans le "Libre" mais je ne les connais pas tous.

    À moins de le créer, …

    • [^] # Re: Mouton à 5 pattes

      Posté par  (site web personnel) . Évalué à 2.

      Python, ruby, C, C++ : erreurs dans les calculs simplissimes ex 0.1 + 0.7 = 0.79999999

      Dans ces langages, les nombres à virgule flottante sont mappées sur ceux gérés par le processeur (avec les erreurs inhérentes à ce type de données), et on les utilise pour des questions de performances quand les erreurs sont acceptables (ex: 3D), et c'est très bien comme ça.
      Maintenant en Python par exemple tu as dans la bibliothèque standard (donc ça fait partie du langage) le type Decimal qui fait ce que tu veux ; pour les autres des bibliothèques qui font la même chose existent j'imagine.

      Dans Django (framework web python) ce type Decimal est fourni de base pour les modèles sauvés en base de données. On s'en sert dans CremeCRM pour la facturation par exemple, et ça fonctionne nickel.

      Maintenant les logiciels de gestion ne sont franchement pas les plus exigeants de manière générale, dans le sens où n'importe quel langage que tu apprécie peut faire l'affaire, et les problèmes que tu cites semble être des détails tout à fait anodins. Aucun des langages n'est parfait, mais une chose est sûre, si tu en créé un il sera bien plus mauvais que n'importe lequel des langages que tu as cités.

      • [^] # Re: Mouton à 5 pattes

        Posté par  . Évalué à -3.

        Maintenant en Python par exemple tu as dans la bibliothèque standard (donc ça fait partie du langage) le type Decimal qui fait ce que tu veux ; pour les autres des bibliothèques qui font la même chose existent j'imagine.

        Certes, mais pour les logiciels de gestion, ce serait tellement mieux si cela faisait partie du langage sans ajouter de librairie explicitement.

        Maintenant les logiciels de gestion ne sont franchement pas les plus exigeants de manière générale, dans le sens où n'importe quel langage que tu apprécie peut faire l'affaire.

        Je pense que tout développeur veut se simplifier la vie d'où la quantité de langages.
        Un langage spécifique aux logiciels de gestion, à mon avis, est bien plus que qu'un langage + des librairies. Tout s'articule avec harmonie : IHM + langage + accès aux bases de données et ceci simplement.

        Serais-je fainéant !!!

        • [^] # Re: Mouton à 5 pattes

          Posté par  . Évalué à -1.

          et j'oublie : les rapports.

        • [^] # Re: Mouton à 5 pattes

          Posté par  (site web personnel) . Évalué à 2.

          Un langage spécifique aux logiciels de gestion

          COBOL ;-) (bon, je viens de voir qu'il existe guicobol avec une mise à jour en avril 2013)

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # python + qt

    Posté par  . Évalué à 2.

    On part de l'assomption que tu veux écrire une interface avec Qt. Je pense que c'est un choix judicieux, reste à savoir si tu veux passer par un binding ou en C++.

    • C++: la porte d'entrée royale pour du Qt. Il faut etre patient et bien structuré, mais avec qdevelop c'est du bonheur en paté.
    • Java: comme toi, j'oublie tout de suite quand je vois les mauvaises performances en mémoire (suffit de laisser ta petite ui ouverte en java pendant des heures et elles prendra une quantité de mémoire allucinante.)
    • Python: Alors, sur ce point je suis d'accord ET pas d'accord:
      • Cython: c'est l'interpreteur par défaut, que tu utilises sans le savoir. Il est assez rapide, pas mal de projet l'utilise. MAIS! attention, multithreading pourri (because GIL de merde), et quasiment aucune optimization au runtime (deroulage des boucles, retrait des appels de fonctions inutiles => ils ne connaissent pas). Tu peux tenter pypy, qui compile le code en language machine. Cette solution me plait beaucoup, mais je ne connais pas sa stabilité.
      • Pyside: extremement facile à développer avec, un syntax un peu étrange, mais ça marche très bien.
      • binding C: ormis pour de l'algorithmie pure (codec video,…), on peut s'en passer: pour tout ce qui est expression régulière, calcul,… python propose déjà du code optimisé. Donc à réserver uniquement pour un traitement lourd ou un widget perso complet bien écrit en Qt.
      • cela dis, pour une interface graphique, QT et python vont très bien ensemble et est suffisament rapide pour les cas d'utilisation que du décrit (l'éditeur de texte sublime est écrit en python et il est extremement rapide… bon il y a des morceaux en C++ parait-il aussi).

    Ma préférence irait vers rust/Qt, le language m'a l'air extremement sexy, orienté vers le 21e siecle, mais je ne sais pas si ça existe, et surtout, vu que le compilateur rust est toujours en développement, il faudra attendre encore quelques temps avant d'avoir un binding propre.

    • [^] # Re: python + qt

      Posté par  (site web personnel) . Évalué à 3.

      Ton post entretient quelques confusions sur Python:

      • l'interpréteur par défaut s'appelle CPython. Cython est un logiciel pour compiler des bouts de Python en C pour les rendre plus rapide.

      • la GIL n'est pas "de merde", elle a aussi beaucoup d'autres qualités. Et il est tout à fait possible de faire du multithreading en Python (il y a un module pour cela). Le Multithreading marche bien sur des programmes io-bound (limités par les entrées-sorties). Il est moins bon sur des programmes CPU-bound où il vaut mieux faire du multi-process (et justement Python fournit un module très simple d'utilisation pour ça).

      • PySide, c'est la même chose que PyQt: un binding pour la bibliothèque graphique Qt.

    • [^] # Re: python + qt

      Posté par  . Évalué à 6.

      On part de l'assomption

      Je le savais! Qt est une religion!!
      -----------> [ ]

  • # Rebol 2

    Posté par  . Évalué à 1.

    Ça n'est pas libre, c'est presque open-source.

    Léger, contient tout ce qu'il faut pour une interface graphique (View), je ne parle même pas du réseau … Il me semble que pour un éditeur Markdown ou un gestionnaire de téléchargement, ça le fait.

    Le créateur, Carl Sassenrath, a fait de la version 3, en développement, un logiciel libre, mais je n'ai pas la moindre idée de ce à quoi ça ressemble.

    Hoplà ?

  • # Pharo

    Posté par  (site web personnel) . Évalué à 1.

    Pharo est multi-plateforme, Morphic tourne partout, avec de jolis modèles de description comme Magritte ( https://vimeo.com/68166920 ) qui permettent de générer la même interface en desktop et HTML5. Il y'a même des bindings GTK / Cocoa ( http://www.youtube.com/watch?v=IRdBHfq1oNk ) et surtout un super environnement de dev.

  • # en furetant dans les depeches

    Posté par  . Évalué à 2.

    J'ai trouvé cet vidéo,
    http://www.youtube.com/watch?v=TbXPPnfsq-c

    parle de html5, ou comment adobe s'investit à fond dedans. Il faut voir les exemples autour de 6-8min, ce sont des choses relativement évidente pour qui connaît le monde de la PAO.
    Mais qui sont toujours cruellement manquantes après toutes ces années de développement et tous ces experts techniques.
    Encore une fois, un géant de l'informatique apporte son expertise au projet, et avec adobe on commence à toucher des désirs très intéressants pour la maturité de la plate forme.
    Jeux, édition graphique, simplicité d'accessibilité.
    On est plus dans l’établissement de standards ouverts prôné par mozilla, ni l'amélioration technique et fonctionnelle de google, ni encore dans la popularisation de ces langages comme yahoo à pu le faire avec JS.
    Ici nous avons enfin un spécialiste de l'ergonomie et de l'édition graphique qui saute dans le bateau.

    Je pense qu'à ré inventer leur cœur de métier autour de ces technos web cela nous promet encore pas mal d'évolutions à venir. Et qu'au regard de ce qu'ils font déjà de nos css et de nos GPUS, ça va roxer du ponay comme rarement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.