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 Troy McClure (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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par X345 . É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
mallocen C++ maisnew.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 Zenitram (site web personnel) . Évalué à 4. Dernière modification le 27 octobre 2013 à 22:31.
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.
Ben disons que les gens ont compris que ça sert à rien, donc pas courant, oui.
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…
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par X345 . Évalué à 3.
Bon allez, je re réponds à ça et puis je vais m'arrêter là.
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.
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.
Non.
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 groumly . Évalué à 4.
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par barmic . Évalué à 4.
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 Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par barmic . Évalué à 2.
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 Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par groumly . Évalué à 5.
Tu t'énerves beaucoup, donc c'est durde savoir de quoi tu parles exactement, mais quand je lit ca:
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.
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 ckyl . É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.
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 groumly . É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 Antoine . Évalué à 5.
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 :
pour Mozilla : "Update (2006-06-13): The code integrating the Boehm GC in Mozilla has not been
tested for a number of years and is unlikely to work anymore" puis "The boehm gc code has been removed" (https://bugzilla.mozilla.org/show_bug.cgi?id=404396#c1)
pour Mono : "Mono has historically used the Boehm-Demers-Wiser Conservative Garbage Collector" (http://www.mono-project.com/Generational_GC)
(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…)
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par barmic . Évalué à 3.
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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par barmic . É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.
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 Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par barmic . Évalué à 2.
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).
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 X345 . Évalué à 2. Dernière modification le 28 octobre 2013 à 14:20.
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 :
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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par X345 . Évalué à 1.
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 :
GraphetNodeAprè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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par fearan . Évalué à 4.
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 barmic . Évalué à 2.
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 fearan . É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 barmic . É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 fearan . É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 freem . É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 ckyl . Évalué à 6.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par ckyl . Évalué à 3.
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 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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la réponse est évidente
Posté par ckyl . Évalué à 4.
Non c'est vrai (même si c'est pas aussi noir qu'il le dit)
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.
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…
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 barmic . Évalué à 3.
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.
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 ckyl . Évalué à 4.
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 !
Ç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 Antoine . Évalué à 3.
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.
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)
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.
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 :
[^] # Re: la réponse est évidente
Posté par freem . Évalué à 0. Dernière modification le 02 novembre 2013 à 16:42.
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 X345 . Évalué à 4.
Bonjour Zenitram.
Je vois qu'un compétiteur de qualitay s'est introduit dans le troll. Me voilà donc attelé à la lourde tâche de défendre les garbage collector.
Bien ! Pour essayer d'avancer, reprenons les points marquants de mon message précédent :
1. Incohérence de conseiller un GC puis de le critiquer
2. Les GC en C++ sont expérimentaux / En C++ on gère sa mémoire à la main.
3. Les GC désallouent bien la mémoire inutilisée sans action du développeur.
4. Java fonctionne pour développer des daemons performants (exemple Hadoop!)
Tu m'accordes le point 2 (et je t'en remercie), nous ne reviendrons donc pas dessus.
Alors, concernant le point 1, tu me réponds
Tu admettras quand même que c'est un brin tordu de recommander un truc qu'on estime inutile. On ne donner pas un exemple de GC en C++ si on estime que les GC c'est inutile. On explique directement pourquoi c'est inutile. Si j'estime qu'une voiture c'est inutile (oh… encore une analogie de voiture), je vais pas donner l'adresse d'une concession
RenaultPeugeotToyota et t'expliquer ensuite que tu ferais mieux de pas acheter de voiture. En somme, mon point 1 est valide.Si, voir les points 3. et 4. J'ai démonté l'idée selon laquelle les GC ne désallouaient pas la mémoire (une grosse partie de son message), et désolé cette partie de mon argumentation est inattaquable. Au passage, j'ai taclé la confusion entre occupation RAM et rapidité d'exécution.
J'ai également argumenté contre l'idée que Java n'était pas performant (ça on peut troller là dessus).
Bref, j'ai bien démonté une grosse partie de ses affirmations.
Tu décales légèrement le troll en affirmant un GC, ça sert à rien (i) et en disant que Java n'est pas performant (ii).
Pour te répondre sur le point (i), tu seras d'accord pour dire qu'un GC, si, ça sert à quelque chose, ça sert à désallouer la mémoire inutilisée. Tu ne peux pas prétendre le contraire, je l'ai démontré dans mon commentaire précédent (point 3.). Je suppose que ta position est plutôt : la gestion manuelle de la mémoire est préférable à une gestion par un GC.
Je pense que dans la majorité des cas, il est préférable de ne pas gérer la mémoire à la main. Premièrement parce que ça évite les erreurs et oublis, un ordinateur est beaucoup plus fiable qu'un humain pour les tâches systématiques et répétitives. Deuxièmement délester le développeur de cette tâche permet de lui permettre de faire autre chose pendant se temps là (penser à l'ergonomie de son application, etc.).
Le seul problème des garbage collector est un problème de performance. Effectivement, il faut bien faire tourner l'algo de récupération de la mémoire à un moment donné et de la manière dont c'est implémenté aujourd'hui nécessite d'arrêter complètement le programme en cours d'exécution.
Mon point est que dans la plupart des cas ce ralentissement du au garbage collector est acceptable. De nombreux langages de haut niveau et pas forcément lents utilisent un garbage collector : OCaml, Haskell, Lisp…
Évidemment dans certains cas, on veut utiliser la totalité de la capacité processeur disponible (exemple, pour faire du traitement vidéo) et le ralentissement causé par un garbage collector n'est pas acceptable. Dans ces cas, on fait du C++ et basta.
Bref, non, la gestion manuelle de la mémoire n'est pas toujours préférable, et un garbage collector, ça sert.
En ce qui concerne le point (ii), tu réponds à mon argument consistant à dire que Java est suffisamment performant puisqu'il est largement utilisé, y compris pour faire du calcul intensif. Ta thèse est de dire que Java est largement répandu parce que maintenant la majorité des dévs ne sait faire que du Java à cause du forcing de Sun. Tu continues en insinuant que Java dilapide les ressources matérielles, ce qui ferait le bonheur des vendeurs de matériel. Tout ceci sans apporter aucune preuve, aucun lien, aucun benchmark. Du beau FUD.
Donc, en plus de tes souvenirs de grand-père qui vont te rester jusqu'à la fin de ta vie, je vais te demander des benchmarks ou n'importe quoi, un article. Mon argument est le suivant : hormis optimisation spécifiques (instructions vectorielles tout ça), un code Java est 2 fois plus lent qu'un code C++ en général. Et c'est quelque chose de généralement admis, voir ce post sur stackoverflow, et l'étude Loop Recognition in C++/Java/Go/Scala ainsi que Computer Language Benchmark Game.
Enfin, si tu jettes Java à cause de la perf, alors tu jettes tout les autres langages à part C∕C++/Fortran car ils sont tous soit équivalents à Java en termes de performance (Ada, Haskell…), soit beaucoup plus lents (Python, PHP, Ruby).
Oui, pour des applications très calculatoires, CPU intensive C++ est largement meilleur (et parfois 10 fois plus rapide si on utilise des choses comme les intructions SSE). Mais coder en C++ optimisé est long et difficile.
Pour revenir sur mon argument, Java est largement suffisant pour faire la majorité des tâches dans une application graphique (je rappelle que c'est ça le sujet) avec des performances raisonnables (pas plus de deux fois plus lent qu'un code C++).
Il faut arrêter avec le FUD prétendant que Java est extrêmement lent, c'est n'importe quoi.
[^] # Re: la réponse est évidente
Posté par cedric . É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 barmic . Évalué à 4.
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 Fulgrim . É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).
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 palkeo (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 X345 . É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 Moonz . Évalué à 4.
Deluge est écrit en Python et ce n’est pas spécialement lent.
[^] # Re: Python et perfs
Posté par X345 . É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 ianux (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 X345 . É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 tyoup . Évalué à 2.
Pfff. L'expérience montrera que beaucoup de développeurs aiment "se faire plaisir"…
[^] # Re: Python et perfs
Posté par X345 . É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
Et là : https://linuxfr.org/users/nedflanders/journaux/j-ai-installe-ubuntu-sur-une-nexus-7#comment-1415553
# J'en pense que
Posté par fearan . É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 mael . Évalué à 9. Dernière modification le 25 octobre 2013 à 16:20.
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.
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 X345 . É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éthodesvirtual(et ses destructeurs hein pour éviter les fuites) , regarder comment on caste lesshared_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 moi1392 . Évalué à -1.
ç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é…
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
merdesmiettes 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 X345 . Évalué à 5.
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 ?
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.
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 moi1392 . Évalué à 2. Dernière modification le 28 octobre 2013 à 13:46.
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.
C'est pour cela qu'il y avait une seconde phrase après.. faut lire jusqu'au bout aussi…
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 Stibb . É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 tyoup . Évalué à 2.
Ben c'est un peu comme comparer un moteur de voiture avec… ok ---->[] je sors
[^] # Re: J'en pense que
Posté par fearan . Évalué à 2.
: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 Stibb . É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 tyoup . Évalué à 5.
c'est une mauvaise idée… en C++…
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 Michaël (site web personnel) . Évalué à 4.
Et les codeurs qui ont pondu ça deviennent magiquement meilleurs lorsqu'ils programment en C++ ?
[^] # Re: J'en pense que
Posté par fearan . Évalué à 2.
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 barmic . Évalué à 2.
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 fearan . É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 barmic . É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 :
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 Fabien PRORIOL . É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 fredix . É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 X345 . Évalué à 10.
Tu sais que ce n'est pas vraiment convaincant ça ?
[^] # Re: Qt/C++
Posté par fredix . Évalué à 1.
Oui enfin je voulais dire au niveau de la simplicité :)
[^] # Re: Qt/C++
Posté par tyoup . Évalué à -1.
tiens moi j'aurais comparé avec java parce que Qt c'est assez lourd…
# JavaScript sans HTML5...
Posté par Claude SIMON (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 :-) !
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: JavaScript sans HTML5...
Posté par X345 . É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 Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 dguihal . É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 X345 . É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
QMainWindowcomplète avec (avec tout plein deQLineEdit,QButton,QTreeViewetQFramededans), 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 neil . É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 X345 . É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.
[^] # Re: Tu as oublié une possibilité
Posté par Olivier Serve (site web personnel) . Évalué à 1.
Tu peux écrire ta logique en python avec PyQt / PySide.
# QML et JavaFx
Posté par Olivier Renaud . É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 palm123 (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 X345 . É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 tito (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 X345 . É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 :-)
[^] # Re: kivy et Python
Posté par Michaël (site web personnel) . Évalué à 4.
Attendons vendredi, hein! :-)
# Java/SWT
Posté par potate . É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 Maclag . É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 X345 . É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 Maclag . É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 Michaël (site web personnel) . Évalué à 1.
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 Yukito (site web personnel) . Évalué à 4.
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 Philippe F (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 X345 . Évalué à 5.
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).
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 François (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 Philippe F (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 Bruno Michel (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 Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
Smalltalk/Squeak!
# Sinon
Posté par Sekigo . É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 X345 . Évalué à 2.
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.
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 flan (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 dave_null (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 X345 . É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 dave_null (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 X345 . Évalué à 1.
Ah du coup, à trois jours d'intervalle, tu arrives à dire :
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 Zarmakuizz (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 dave_null (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.
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.
[^] # Re: Puisque l'on en vient à proposer du XUL, du TK et même du Qt…
Posté par Batchyx . Évalué à 0.
Sauf que Wireshark n'est pas une voiture, mais une dépanneuse.
C'est un peu comme les dépanneurs/remorqueurs de la SNCF qui fonctionnent à l'essence (ou à d'autres sources d'énergies qui puent) alors que les voies sont toutes électrifiées.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Interface graphique multiplateforme...
Posté par Wawet76 . Évalué à 1.
Selon mon prof d'IHM, tu peux t'en tirer avec Tcl/Tk.
# Oublie les bindings
Posté par thecat . É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 reno . É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 tyoup . Évalué à 2.
Personne n'a rebondi sur node.js mais franchement pourquoi pas ? Et voire pourquoi pas avec Java/Netty?
# // ----> | |[*o*] [*o*]| |
Posté par maboiteaspam . Évalué à 5.
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.
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 maboiteaspam . É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 ZankFrappa . Évalué à 4.
Si tu n'as rien contre GTK+, tu pourrais regarder du côté de Vala.
# Mouton à 5 pattes
Posté par ahinki . É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 GuieA_7 (site web personnel) . Évalué à 2.
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 ahinki . Évalué à -3.
Certes, mais pour les logiciels de gestion, ce serait tellement mieux si cela faisait partie du langage sans ajouter de librairie explicitement.
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 ahinki . Évalué à -1.
et j'oublie : les rapports.
[^] # Re: Mouton à 5 pattes
Posté par lolop (site web personnel) . Évalué à 2.
COBOL ;-) (bon, je viens de voir qu'il existe guicobol avec une mise à jour en avril 2013)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# python + qt
Posté par Stibb . É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++.
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 Philippe F (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 Stibb . Évalué à 1.
quel module pour faire du multi process facilement?
[^] # Re: python + qt
Posté par Philippe F (site web personnel) . Évalué à 2.
Attention, le nom est un peu alambiqué et difficile à trouver: multiprocessing
[^] # Re: python + qt
Posté par Maclag . Évalué à 6.
Je le savais! Qt est une religion!!
-----------> [ ]
# Rebol 2
Posté par LapiGNU . É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 laurent laffont (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 maboiteaspam . É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.