J'ai cru que cette nouvelle annoncait le support tant attendu de X-Window pour le vénérable éditeur Ed (logiciel) . Après Vi et Emacs, pourquoi Ed n'aurait-il pas droit à une interface graphique digne de ce nom ?
J'aime bien la réflexion derrière asm.js et derrière dart en général. D'ailleurs, je m'interroge sur le fait que le choix du sous-ensemble de javascript utilisé par asm.js doit être tout aussi facile à optimiser pour SpiderMonkey que pour V8, non ?
Autre question si qq'un a la réponse : pourquoi un outil comme dart2js ne génère-t-il pas de l'asm.js ? Ca peut être une façon détournée de faire un gain en performance sur Firefox.
Par exemple, si l'on cultive des plantes sélectionnées qui ont un rendement deux fois supérieur, on peut nourrir deux fois plus de personnes avec les mêmes ressources naturelles.
Si tu penses que ça n'est pas naturel ou que c'est contraire aux lois de la nature, tu est sur une position religieuse ou philosophique.
Ou sur une position scientifique tout simplement: rien ne se perd, rien ne se crée.
Ce qui est contraire au lois de la nature, c'est de penser qu'on peut faire plus avec la même quantité de départ.
Si un plant sélectionné de légume est deux fois plus gros qu'un autre, il a pompé deux fois plus de ressources pour se développer: eau, nutriments, etc. La seule ressource infinie qu'il a utilisé est la lumière du soleil, le reste ce sont des ressources naturelles finies qui ont été consommées par la plante.
Certes, une partie de ces nutriments peut-être apportée par des engrais mais pas tous. L'autre partie a été pompée dans le sol (eau, …) et peut conduire si on l'utilise intensément (ce qu'on fait depuis une cinquantaine d'année maintenant) à un appauvrisement du sol. Il ne devient plus capable de "nourrir" correctement les légumes qu'il produit, et ceux-ci, par un effet pervers demandent encore plus d'apports externes pour se développer normalement.
Tu as donc l'impression de faire un gain de productivité et d'avoir augmenté ton rendement mais en fait, tu condamnes ton milieu de production à long terme.
Autre possibilité, ton légume est plus gros, mais en fait, il est gonflé à l'eau, et contient la même quantité, voire moins de nutriments qu'un légume plus petit. L'illusion d'optique fonctionne, sauf que le légume ne rassasie plus et tu es obligé d'en manger plus pour arriver à te nourrir [1].
J'ai pas d'études scientifiques sous la main, mais il a été clairement analysé que les légumes produits de façon non intense (typiquement, en bio) contiennent plus de matière sèche qu'un légume produit de façon intense (typiquement, aux étals de grandes surfaces). Au final, tu as utilisé plus de nutriments et d'intrants chimiques, alors que la personne mangerai un légume petit et boirait un vers d'eau et aurait le même résultat.
Donc tu n'a pas résolu ton problème.
Tu créées même des effets pervers, puisque le cerveau emmagasine une fausse information, qu'il faut manger plus pour arriver à la sensation de satiété, alors que le problème vient de la qualité. En plus de la taille du légume, les industriels vont bien sur jouer sur tous les paramètres possibles pour créer une dépendance psychologique accrue à ce "faux" légume : couleur standardisée, un peu plus de sucre pour stimuler les zones de plaisir, un peu de brillant pour qu'il ressemble à une photo de papier glacé, suppression des légumes avec des "défauts" pour que la personne oublie même que cela existe. Tous ces facteurs font que au final, tu crois faire un gain de productivité alors que tu ajoutes un maillon à la chaîne de la surconsommation, qui crée un appauvrissement global de notre monde.
Donc je m'élève en faux contre cette affirmation, de la possibilité de la croissance infinie: « on peut nourrir deux fois plus de personnes avec les mêmes ressources naturelles ».
[1]: je n'ai que mon expérience personnelle et mon entourage pour vous dire que manger un légume bio rassasie mieux. Le goût est plus intense, et au final on en consomme moins. Pour avoir la même sensation de satiété avec des légumes non bio, j'ai besoin d'en manger plus…
Tiens, petite anecdote à propos de cette approche de lien symbolique. Au temps de KDE 2, je me souviens qu'ils avaient travaillé sur l'optimisation du temps de lancement de KDE. Ils avaient constaté que certains services KDE qui sont lancés par Shell étaient lancés avec /bin/sh mais en fait étaient lancés par /bin/bash à cause des liens symboliques, et bash prenaient énormément de temps à démarrer, parce que le shell est bien plus compliqué que sh.
Au final, trouver le vrai sh ou remplacer les scripts triviaux par un programme en C plus simple avait fait un gain significatif sur le temps de lancement.
Il y a le vieux trucs de rappeler régulièrement dans l'application que c'est une version on enregistrée et qu'il faut payer pour l'utiliser.
Façon WinRar, avec le bouton de la souris positionné par défaut sur "j'achète" et un déplacement aléatoire de ce bouton pour que tu ne puisses pas avoir un geste mécanique "je clique sur le bouton du haut".
Ou façon SublimeText où quand tu sauves ton programme, régulièrement (2-3 fois par jours), il te rappelle de t'enregistrer.
Après, je sais pas si ça marche. Vu l'acharnement de WinRar, j'aurai tendance à dire que l'auteur était pas tout à fait satisfait du rapport "nombre de personnes qui achètent" / "nombre de personnes qui l'utilisent".
Si je résume: quand une personne qui fait passer un test de programmation à un candidat et connait bien son métier par ailleurs, ça laisse une bonne impression au candidat. Quand elle n'y connait rien, ça laisse une mauvaise impression. Finalement, cette histoire de test, c'est un peu comme les bons chasseurs…
Perso, j'ai fait passer des tests pour recruter des stagiaires. C'est normalement entre 15 et 30 minutes et ça suffit largement pour se faire une idée des qualités de développeurs du candidat. Par contre, 3h, c'est un truc de malade! Je ferai un truc comme ça en phase 2 ou 3 du recrutement à la rigueur.
Sur un test de 15 minutes on voit immédiatement quelques paramètres objectifs:
est-ce que le candidat pose des questions lorsqu'il manque des informations pour réaliser sa tâche ?
est-ce qu'il a suffisamment écouté pour réaliser l'exercice correctement (dans 90% des cas, non).
est-ce qu'il aborde le problème de façon structurée ?
est-ce qu'il comprend ce qu'il écrit ?
est-ce qu'il arrive à écrire un programme qui marche ?
est-ce qu'il est réellement familier avec le langage qu'il prétend maitriser ?
Ensuite, on discute de son programme, on identifie ensemble des points faibles ou forts, on réfléchit à la gestion mémoire (c'est à dire, est-ce qu'il connait les concepts en dessous des outils qu'il utilise ?), à la souplesse du programme, etc.
C'est un exercice participatif, constructif et très révélateur du niveau général du candidat.
J'avais regardé et j'avais trouvé le langage plutôt plaisant. Il permet de faire ce que je fais d'habitude avec une certaine simplicité, souplesse et robustesse.
La doc est un peu minimaliste mais on s'en sort.
Par contre, je voulais en profiter pour faire un projet loisir avec une interface graphique et là, c'est la misère. C'est plus orienté système.
Et vu la structure du langage, je vois pas bien comment ils vont me faire mon binding préféré, le goqt …
J'ai longtemps pensé que l'approche à la WxWidget était la bonne, car le portage vers une nouvelle plate-forme voulait uniquement dire de faire rentrer les contrôles existants dans l'api de WxWidget. Toute la partie look devenait natif et suivait la plate-forme (ce qui faisait taire les râleurs).
A l'inverse Qt, pour un nouveau portage, doit redévelopper un système d'affichage bas-niveau. Et quand il y a des nouveaux moteurs de look (Win98 -> XP -> Vista -> Seven), il faut redévelopper le moteur de thème pour tirer partie des derniers moteurs. C'est un problème en particuliers quand une plate-forme non majeur sort un nouveau moteur, il se peut que les développeurs de Qt ne soient pas rapides à l'intégrer et on voit alors des trolls surgir sur Linuxfr.
J'ai cependant complètement changé d'avis avec le temps et à l'utilisation de Qt. Au fur à mesure que Qt a pris en maturité, les contrôles/widgets sont devenus de plus en plus élaborés, bien plus que ceux qu'on trouve en natif sur la plate-forme, battant en brèche un des avantages de WxWidget.
De plus en terme de debug, les widgets de Qt sont débuggés une fois pour toute, le code étant commun à plusieurs plate-formes, alors qu'il est régulier que Wx se traîne des bugs spécifiques à des plate-formes. Et je ne peux pas les blâmer pour ça, qui peut garantir que par exemple les ascenseurs Windows, MacOs et Gtk soient complètement "unifiables" en terme d’événements envoyés à la pile graphique.
Au final, la stratégie de Qt paye sur le long terme. Au fur à mesure que le nombre de plate-forme augmente, et le nombre de widget aussi, l'effort de développement côté Qt reste relativement linéaire avec une pente assez douce, car dès que le moteur graphique est porté, tous les widgets suivent instantanément. De même, pour un nouveau look'n feel, Qt a maintenant un moteur de style suffisamment costaud pour absorber beaucoup des dernières nouveautés.
Pour Wx, chaque nouvelle plate-forme multiple de façon exponentiel le travail de maintenance et d'évolution, car il faut gérer des nouveaux comportements des widgets natifs.
En tout cas, on constate que :
Wx utilise l'approche Qt pour un certain nombre de Widget avancés, qui ne sont pas communs à toutes les plate-formes et doivent être fait en natif.
Qt utilise l'approche de Wx pour un très petit nombre de briques, où le choix est proposé entre la version par défaut de Qt ou la version native: dialgue de fichier, system tray, et je sais plus quoi d'autre.
Tout le monde peut donc se faire des bisous, tout va bien.
Il y a vraiment deux approches différentes entre WxWidget et Qt.
Qt émule le look'n feel des contrôles des différentes environnements. Donc un ComboBox Qt par exemple, est avant-tout un combo-box écrit par Qt en C++, et un certain nombre de ses comportements sont adaptés selon la plate-forme.
WxWidget au contraire, se targue d'utiliser les contrôles natifs de la plate-forme cible. Donc en théorie, en combo-box en WxWidget sous Windows, c'est un combo-box de Windows, sous MacOs, c'est l'OS qui fourni le combo-box, etc etc.
Dans la théorie, ça crée une émulation plus fidèle des contrôles de la plate-forme, mais au risque de d'introduire des bugs qui sont spécifiques à la plate-forme à cause de comportements légèrement différents d'une plate-forme à l'autre. Un autre inconvénient, c'est qu'on se retrouve vite à faire du nivellement par le bas: telle plate-forme ne fournit pas un contrôle donné, donc soit Wx ne le fournit pas, soit Wx doit l'émuler et prend la même démarche que Qt, faire un codage interne. J'ai vu traîner dans la documentation ce genre de cas mais j'ai plus d'exemples en tête.
Au final, il me semble que WxWidget fournit pas mal de Widget maison (approche à la Qt) et des widgets natifs uniquement pour les contrôles de base. Et surtout, sur un certains nombre de plate-forme, c'est plus vraiment les widgets natifs qui sont utilisés. Les explication sur MacOs me font supposer que sous MacOs, c'est en fait le port Gtk qui est utilisé et non pas les widget natifs Cocoa mais je m'avance.
En tout cas, en Python, c'est un des GUI les plus populaires (loin devant PyQt il me semble).
Un gros problème indirect de WxWidget, c'est le fait que WxPython ne fonctionne qu'en Python 2. Ca commence à être génant pour certains projets.
Plutôt que de porter le code actuel, ce qui est prévu est une réécriture complète du générateur de binding Python, pour supporter à la fois Python 2 et Python 3, avec une syntaxe légèrement différent. Ca a pris le nom de "Projet Phoenix": http://wxpython.org/Phoenix/docs/html/
Comme tous les gros projets de réécriture, il tarde à se matérialiser…
Je suis 100% d'accord. Je rêve d'un vrai clavier orienté programmation. Le plupart des langages de programmation utilisent un jeu de caractère assez réduit qui devrait être facile d'accès.
Pour le Python, par order d'importance: ()[]:.,+-/*<>
Pour le C: ;{}()<>[].,+-/*:
En ruby, le jeu de caractères très util est plus vaste il me semble…
Pour le LISP: ()
Pour Emacs: ALT, SHIFT, ESC, META, CONTROL
Après, un clavier pour le français, un clavier pour la programmation, l'azerty quand tu es sur le PC d'un pote en France, le qwerty quand tu boot ton linux, ça commence à faire beaucoup de claviers. J'ai déjà du mal à savoir lequel j'utilise lorsque je suis en train de taper. Et à chaque fois que ma femme a besoin de mon ordi j'ai droit au "c'est où déjà pour changer de clavier ?" .
Je note le fork de console2, ça peut valoir le coup. Pour les multi-bureau, j'utilise VirtuaWin. Très sobre (rien à voir avec Compiz et autre), il me suffit amplement au quotidien.
Sinon, Windows, avec un cygwin, Thunderbird, vim, Console2, VirtuaWin, ça commence à être vivable… Je dis ça, ça doit bien faire quelques années que j'ai pas booté un linux sur mes ordi de bureau.
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.
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 !
Les applications/fenêtres/dialogues qu'on peut pas redimensionner, c'est pas un jeu Gtk vs Qt, c'est juste le développeur qui doit utiliser les bons outils.
Techniquement, Qt savait le faire avant Gtk (on parle des version 1.0). WireShark étant très ancien, les problèmes que tu décris proviennent peut-être du fait qu'ils ont utilisé Gtk a un moment où c'était mal disponible.
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 ?
La réalité est qu'une caisse enregistreuse, c'est plus qu'un simple logiciel. En tout qu'outil qui manipule de l'argent, l'état veut garder un œil sur ce qui s'y fait et vérifier que les gens ne font pas n'importe quoi.
Pour prendre un exemple que je connais, on pourrait aussi dire que les certifications Visa et Carte Bleue pour les cartes à puce de paiement sont de la c******rie, et laisser les banques acheter leur cartes à n'importe quel fournisseur. Sauf que … on aurait de la fraude massive, des cartes qui se cassent facilement quand tu les tords (et surtout, on pourrait plus dégivrer son pare-brise avec sa carte bleue [1], une grande perte pour l'industrie bancaire !).
Une certification crée certes une barrière à l'entrée dans un marché mais aussi une certaine perrenité et standardisation dans les usages. Il y a du pour et du contre.
Quand je vois ce que tu écris, tu m'as l'air de rater la partie liée au pour et être plutôt en mode "c'est rien que des méchants qui veulent m'empêcher de faire mon bo logiciel".
[1]: les tests de certification des cartes prévoient toutes sortes de torsion pour les cas "carte stockée dans la poche arrière du jean", "porte-feuille tellement bourré que tout est déformé à l'intérieur". Et aussi des tests à -5 degré ou plus, un peu de trempage dans de l'eau, tout ça pour le cas "je dégivre mon pare-brise". Il me semble qu'il y a aussi des test résister de façon raisonnable à un passage en machine à laver. Tout ça pour faire un moyen de paiement… Imaginez comment les premiers fabricants de carte à puce se sont pris la tête!
J'ai entendu des esprits sceptiques dire que si on étudiant les risques liés au tabagisme comme on étudie aujourd'hui les risques liée au téléphone portable (et à la saturation d'onde en général), on en arriverait à la même conclusion: a priori pas dangereux pour un usage modéré.
Difficile sans être un expert et y consacrer beaucoup de temps de se faire une réelle opinion. Mais je reste sceptique de mon côté sur l'innocuité globale à long terme du truc.
Bah, c'est un héritage. C'est un peu comme la syntaxe des Makefile dont on parlait il y a peu, ou le format des .mailfilter , ou les autoconf, ou la syntaxe de sh pour faire des expressions booléennes. C'est pourri mais on fait avec parce que c'est ce qui est disponible partout et par défaut.
Après, aux autres de prendre la place. Apache n'est pas encore détroné mais a perdu beaucoup de terrain, le système d'init vénérable de Unix est aussi détroné, lilo est détroné. On se débarrasse de plein de vieilleries avec le temps…
C'est bien ce que je dis: un bug, quelques semaines de dev, deux fois plus les tests et lire la doc, et encore deux fois plus pour en discuter sur Python-dev. Et au final, une PEP, pour un truc où 99.99% des gens ne sauront jamais qu'il y avait eu un problème avant. Respect!
Ce que je trouve intéressant en suivant python-dev, c'est qu'on voit d'une part l'attachement très fort des développeurs à ne rien casser (j'imagine qu'ils en ont mangé pas mal par le passé), d'autre part on voit la réflexion de fond sur le long terme et l'attention à chaque détail. On arrive d'ailleurs toujours à la conclusion (sur des fonctionnalités pointues) qu'à un moment, Python ne peut pas résoudre tout et les problèmes de l'OS ou les différences de fonctionnement des OS en dessous finissent par se voir. Ca s'est vu sur la clock monotonic, sur l'unicode ou sur l'héritage des file descripteurs.
J'aime aussi beaucoup lire le travail de cette communauté: les développeurs sont globalement très moteurs, acceptent les critiques et sont prêts à se remettre en question, même quand le travail est en amont est très conséquent.
On pourrait parfois penser que Python est assez complet et très stable, mais il y a toujours des propositions d'évolutions très importantes.
Et si on rajoute en plus les PEP où Antoine contribue fortement sous forme de commentaires et revues, plus ceux où il est PEP Dictateur, plus les autres contributeurs français, on peut dire que les français font avancer Python à grand pas !
Victor, je voulais d'ailleurs te dire mon respect pour plonger dans les sujets aussi tordus que ceux que tu abordes (unicode à tous les étages, héritage des descripteurs, etc), qui demandent vraiment d'aller creuser tous les cas tordus dans toutes les plate-formes. C'est un travail de fourmi, avec très peu de retombées visibles, qui rendent pourtant Python beaucoup plus solide.
# Ed avec le support X-Window
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le code source d’edX est disponible sous AGPLv3. Évalué à 2.
J'ai cru que cette nouvelle annoncait le support tant attendu de X-Window pour le vénérable éditeur Ed (logiciel) . Après Vi et Emacs, pourquoi Ed n'aurait-il pas droit à une interface graphique digne de ce nom ?
Je suis déçu…
[^] # Re: asm.js...
Posté par Philippe F (site web personnel) . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 3.
J'aime bien la réflexion derrière asm.js et derrière dart en général. D'ailleurs, je m'interroge sur le fait que le choix du sous-ensemble de javascript utilisé par asm.js doit être tout aussi facile à optimiser pour SpiderMonkey que pour V8, non ?
Autre question si qq'un a la réponse : pourquoi un outil comme dart2js ne génère-t-il pas de l'asm.js ? Ca peut être une façon détournée de faire un gain en performance sur Firefox.
[^] # Re: Rien de nouveau à l'horizon
Posté par Philippe F (site web personnel) . En réponse au journal Google Robotics. Évalué à 3.
Ou sur une position scientifique tout simplement: rien ne se perd, rien ne se crée.
Ce qui est contraire au lois de la nature, c'est de penser qu'on peut faire plus avec la même quantité de départ.
Si un plant sélectionné de légume est deux fois plus gros qu'un autre, il a pompé deux fois plus de ressources pour se développer: eau, nutriments, etc. La seule ressource infinie qu'il a utilisé est la lumière du soleil, le reste ce sont des ressources naturelles finies qui ont été consommées par la plante.
Certes, une partie de ces nutriments peut-être apportée par des engrais mais pas tous. L'autre partie a été pompée dans le sol (eau, …) et peut conduire si on l'utilise intensément (ce qu'on fait depuis une cinquantaine d'année maintenant) à un appauvrisement du sol. Il ne devient plus capable de "nourrir" correctement les légumes qu'il produit, et ceux-ci, par un effet pervers demandent encore plus d'apports externes pour se développer normalement.
Tu as donc l'impression de faire un gain de productivité et d'avoir augmenté ton rendement mais en fait, tu condamnes ton milieu de production à long terme.
Autre possibilité, ton légume est plus gros, mais en fait, il est gonflé à l'eau, et contient la même quantité, voire moins de nutriments qu'un légume plus petit. L'illusion d'optique fonctionne, sauf que le légume ne rassasie plus et tu es obligé d'en manger plus pour arriver à te nourrir [1].
J'ai pas d'études scientifiques sous la main, mais il a été clairement analysé que les légumes produits de façon non intense (typiquement, en bio) contiennent plus de matière sèche qu'un légume produit de façon intense (typiquement, aux étals de grandes surfaces). Au final, tu as utilisé plus de nutriments et d'intrants chimiques, alors que la personne mangerai un légume petit et boirait un vers d'eau et aurait le même résultat.
Donc tu n'a pas résolu ton problème.
Tu créées même des effets pervers, puisque le cerveau emmagasine une fausse information, qu'il faut manger plus pour arriver à la sensation de satiété, alors que le problème vient de la qualité. En plus de la taille du légume, les industriels vont bien sur jouer sur tous les paramètres possibles pour créer une dépendance psychologique accrue à ce "faux" légume : couleur standardisée, un peu plus de sucre pour stimuler les zones de plaisir, un peu de brillant pour qu'il ressemble à une photo de papier glacé, suppression des légumes avec des "défauts" pour que la personne oublie même que cela existe. Tous ces facteurs font que au final, tu crois faire un gain de productivité alors que tu ajoutes un maillon à la chaîne de la surconsommation, qui crée un appauvrissement global de notre monde.
Donc je m'élève en faux contre cette affirmation, de la possibilité de la croissance infinie: « on peut nourrir deux fois plus de personnes avec les mêmes ressources naturelles ».
[1]: je n'ai que mon expérience personnelle et mon entourage pour vous dire que manger un légume bio rassasie mieux. Le goût est plus intense, et au final on en consomme moins. Pour avoir la même sensation de satiété avec des légumes non bio, j'ai besoin d'en manger plus…
[^] # Re: systemd
Posté par Philippe F (site web personnel) . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 5.
Tiens, petite anecdote à propos de cette approche de lien symbolique. Au temps de KDE 2, je me souviens qu'ils avaient travaillé sur l'optimisation du temps de lancement de KDE. Ils avaient constaté que certains services KDE qui sont lancés par Shell étaient lancés avec /bin/sh mais en fait étaient lancés par /bin/bash à cause des liens symboliques, et bash prenaient énormément de temps à démarrer, parce que le shell est bien plus compliqué que sh.
Au final, trouver le vrai sh ou remplacer les scripts triviaux par un programme en C plus simple avait fait un gain significatif sur le temps de lancement.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Philippe F (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 1.
Il y a le vieux trucs de rappeler régulièrement dans l'application que c'est une version on enregistrée et qu'il faut payer pour l'utiliser.
Façon WinRar, avec le bouton de la souris positionné par défaut sur "j'achète" et un déplacement aléatoire de ce bouton pour que tu ne puisses pas avoir un geste mécanique "je clique sur le bouton du haut".
Ou façon SublimeText où quand tu sauves ton programme, régulièrement (2-3 fois par jours), il te rappelle de t'enregistrer.
Après, je sais pas si ça marche. Vu l'acharnement de WinRar, j'aurai tendance à dire que l'auteur était pas tout à fait satisfait du rapport "nombre de personnes qui achètent" / "nombre de personnes qui l'utilisent".
[^] # Re: Oui!
Posté par Philippe F (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 4.
Et tu en vies ? Zenitram arrive apparamment à vivre de son logiciel.
Et Bruno Coudoin ? Et toi ?
[^] # Re: je suis à la recherche d'un dev PHP
Posté par Philippe F (site web personnel) . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 3.
Si je résume: quand une personne qui fait passer un test de programmation à un candidat et connait bien son métier par ailleurs, ça laisse une bonne impression au candidat. Quand elle n'y connait rien, ça laisse une mauvaise impression. Finalement, cette histoire de test, c'est un peu comme les bons chasseurs…
Perso, j'ai fait passer des tests pour recruter des stagiaires. C'est normalement entre 15 et 30 minutes et ça suffit largement pour se faire une idée des qualités de développeurs du candidat. Par contre, 3h, c'est un truc de malade! Je ferai un truc comme ça en phase 2 ou 3 du recrutement à la rigueur.
Sur un test de 15 minutes on voit immédiatement quelques paramètres objectifs:
Ensuite, on discute de son programme, on identifie ensemble des points faibles ou forts, on réfléchit à la gestion mémoire (c'est à dire, est-ce qu'il connait les concepts en dessous des outils qu'il utilise ?), à la souplesse du programme, etc.
C'est un exercice participatif, constructif et très révélateur du niveau général du candidat.
# Quid des gui
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 3.
J'avais regardé et j'avais trouvé le langage plutôt plaisant. Il permet de faire ce que je fais d'habitude avec une certaine simplicité, souplesse et robustesse.
La doc est un peu minimaliste mais on s'en sort.
Par contre, je voulais en profiter pour faire un projet loisir avec une interface graphique et là, c'est la misère. C'est plus orienté système.
Et vu la structure du langage, je vois pas bien comment ils vont me faire mon binding préféré, le goqt …
[^] # Re: je n'ai jamais utilisé wxWidgets
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 3.0. Évalué à 10.
J'ai longtemps pensé que l'approche à la WxWidget était la bonne, car le portage vers une nouvelle plate-forme voulait uniquement dire de faire rentrer les contrôles existants dans l'api de WxWidget. Toute la partie look devenait natif et suivait la plate-forme (ce qui faisait taire les râleurs).
A l'inverse Qt, pour un nouveau portage, doit redévelopper un système d'affichage bas-niveau. Et quand il y a des nouveaux moteurs de look (Win98 -> XP -> Vista -> Seven), il faut redévelopper le moteur de thème pour tirer partie des derniers moteurs. C'est un problème en particuliers quand une plate-forme non majeur sort un nouveau moteur, il se peut que les développeurs de Qt ne soient pas rapides à l'intégrer et on voit alors des trolls surgir sur Linuxfr.
J'ai cependant complètement changé d'avis avec le temps et à l'utilisation de Qt. Au fur à mesure que Qt a pris en maturité, les contrôles/widgets sont devenus de plus en plus élaborés, bien plus que ceux qu'on trouve en natif sur la plate-forme, battant en brèche un des avantages de WxWidget.
De plus en terme de debug, les widgets de Qt sont débuggés une fois pour toute, le code étant commun à plusieurs plate-formes, alors qu'il est régulier que Wx se traîne des bugs spécifiques à des plate-formes. Et je ne peux pas les blâmer pour ça, qui peut garantir que par exemple les ascenseurs Windows, MacOs et Gtk soient complètement "unifiables" en terme d’événements envoyés à la pile graphique.
Au final, la stratégie de Qt paye sur le long terme. Au fur à mesure que le nombre de plate-forme augmente, et le nombre de widget aussi, l'effort de développement côté Qt reste relativement linéaire avec une pente assez douce, car dès que le moteur graphique est porté, tous les widgets suivent instantanément. De même, pour un nouveau look'n feel, Qt a maintenant un moteur de style suffisamment costaud pour absorber beaucoup des dernières nouveautés.
Pour Wx, chaque nouvelle plate-forme multiple de façon exponentiel le travail de maintenance et d'évolution, car il faut gérer des nouveaux comportements des widgets natifs.
En tout cas, on constate que :
Tout le monde peut donc se faire des bisous, tout va bien.
[^] # Re: je n'ai jamais utilisé wxWidgets
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 3.0. Évalué à 2.
au temps pour moi…
[^] # Re: je n'ai jamais utilisé wxWidgets
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 3.0. Évalué à 10.
Il y a vraiment deux approches différentes entre WxWidget et Qt.
Qt émule le look'n feel des contrôles des différentes environnements. Donc un ComboBox Qt par exemple, est avant-tout un combo-box écrit par Qt en C++, et un certain nombre de ses comportements sont adaptés selon la plate-forme.
WxWidget au contraire, se targue d'utiliser les contrôles natifs de la plate-forme cible. Donc en théorie, en combo-box en WxWidget sous Windows, c'est un combo-box de Windows, sous MacOs, c'est l'OS qui fourni le combo-box, etc etc.
Dans la théorie, ça crée une émulation plus fidèle des contrôles de la plate-forme, mais au risque de d'introduire des bugs qui sont spécifiques à la plate-forme à cause de comportements légèrement différents d'une plate-forme à l'autre. Un autre inconvénient, c'est qu'on se retrouve vite à faire du nivellement par le bas: telle plate-forme ne fournit pas un contrôle donné, donc soit Wx ne le fournit pas, soit Wx doit l'émuler et prend la même démarche que Qt, faire un codage interne. J'ai vu traîner dans la documentation ce genre de cas mais j'ai plus d'exemples en tête.
Au final, il me semble que WxWidget fournit pas mal de Widget maison (approche à la Qt) et des widgets natifs uniquement pour les contrôles de base. Et surtout, sur un certains nombre de plate-forme, c'est plus vraiment les widgets natifs qui sont utilisés. Les explication sur MacOs me font supposer que sous MacOs, c'est en fait le port Gtk qui est utilisé et non pas les widget natifs Cocoa mais je m'avance.
En tout cas, en Python, c'est un des GUI les plus populaires (loin devant PyQt il me semble).
# Et python 3 ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 3.0. Évalué à 10.
Un gros problème indirect de WxWidget, c'est le fait que WxPython ne fonctionne qu'en Python 2. Ca commence à être génant pour certains projets.
Plutôt que de porter le code actuel, ce qui est prévu est une réécriture complète du générateur de binding Python, pour supporter à la fois Python 2 et Python 3, avec une syntaxe légèrement différent. Ca a pris le nom de "Projet Phoenix": http://wxpython.org/Phoenix/docs/html/
Comme tous les gros projets de réécriture, il tarde à se matérialiser…
Philippe
[^] # Re: Bepo et programmation ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le Bépo en console inclus de base sous GNU/Linux. Évalué à 6.
Je suis 100% d'accord. Je rêve d'un vrai clavier orienté programmation. Le plupart des langages de programmation utilisent un jeu de caractère assez réduit qui devrait être facile d'accès.
Pour le Python, par order d'importance: ()[]:.,+-/*<>
Pour le C: ;{}()<>[].,+-/*:
En ruby, le jeu de caractères très util est plus vaste il me semble…
Pour le LISP: ()
Pour Emacs: ALT, SHIFT, ESC, META, CONTROL
Après, un clavier pour le français, un clavier pour la programmation, l'azerty quand tu es sur le PC d'un pote en France, le qwerty quand tu boot ton linux, ça commence à faire beaucoup de claviers. J'ai déjà du mal à savoir lequel j'utilise lorsque je suis en train de taper. Et à chaque fois que ma femme a besoin de mon ordi j'ai droit au "c'est où déjà pour changer de clavier ?" .
# Surviving on Windows for linux freaks
Posté par Philippe F (site web personnel) . En réponse au journal Quelques outils pour Windows. Évalué à 8.
Dans la même démarche que toi, j'avais fait une page wiki sur le sujet:
http://www.freehackers.org/Surviving_on_Windows
Je note le fork de console2, ça peut valoir le coup. Pour les multi-bureau, j'utilise VirtuaWin. Très sobre (rien à voir avec Compiz et autre), il me suffit amplement au quotidien.
Sinon, Windows, avec un cygwin, Thunderbird, vim, Console2, VirtuaWin, ça commence à être vivable… Je dis ça, ça doit bien faire quelques années que j'ai pas booté un linux sur mes ordi de bureau.
[^] # Re: python + qt
Posté par Philippe F (site web personnel) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 2.
Attention, le nom est un peu alambiqué et difficile à trouver: multiprocessing
[^] # Re: python + qt
Posté par Philippe F (site web personnel) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. É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: Déprimant
Posté par Philippe F (site web personnel) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. É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 !
[^] # Re: Pas les premiers à changer et pas les derniers
Posté par Philippe F (site web personnel) . En réponse à la dépêche Wireshark passe à Qt. Évalué à 5.
La grosse blague…
Les applications/fenêtres/dialogues qu'on peut pas redimensionner, c'est pas un jeu Gtk vs Qt, c'est juste le développeur qui doit utiliser les bons outils.
Techniquement, Qt savait le faire avant Gtk (on parle des version 1.0). WireShark étant très ancien, les problèmes que tu décris proviennent peut-être du fait qu'ils ont utilisé Gtk a un moment où c'était mal disponible.
[^] # Re: Déprimant
Posté par Philippe F (site web personnel) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. É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 ?
# Et d'autres...
Posté par Philippe F (site web personnel) . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 10.
TortoiseHG a fait la migration aussi il y a un an ou deux. Et il y a un environnement de dev Python dont le nom m'échappe qui passe aussi à Qt.
Je saute sur mon destrier à remonter le temps et je m'en vais de ce pas nourrir les trolls d'il y a 10 ans avec ces nouveaux arguments imparables !
Sinon … on vous l'avait tous dit il y a longtemps mais vous ne vouliez pas nous croire!
[^] # Re: Agrément ministériel (reste du monde)
Posté par Philippe F (site web personnel) . En réponse à la dépêche Logiciel de caisse Pastèque, version Datte. Évalué à 2.
Que de hargne envers le monde…
La réalité est qu'une caisse enregistreuse, c'est plus qu'un simple logiciel. En tout qu'outil qui manipule de l'argent, l'état veut garder un œil sur ce qui s'y fait et vérifier que les gens ne font pas n'importe quoi.
Pour prendre un exemple que je connais, on pourrait aussi dire que les certifications Visa et Carte Bleue pour les cartes à puce de paiement sont de la c******rie, et laisser les banques acheter leur cartes à n'importe quel fournisseur. Sauf que … on aurait de la fraude massive, des cartes qui se cassent facilement quand tu les tords (et surtout, on pourrait plus dégivrer son pare-brise avec sa carte bleue [1], une grande perte pour l'industrie bancaire !).
Une certification crée certes une barrière à l'entrée dans un marché mais aussi une certaine perrenité et standardisation dans les usages. Il y a du pour et du contre.
Quand je vois ce que tu écris, tu m'as l'air de rater la partie liée au pour et être plutôt en mode "c'est rien que des méchants qui veulent m'empêcher de faire mon bo logiciel".
[1]: les tests de certification des cartes prévoient toutes sortes de torsion pour les cas "carte stockée dans la poche arrière du jean", "porte-feuille tellement bourré que tout est déformé à l'intérieur". Et aussi des tests à -5 degré ou plus, un peu de trempage dans de l'eau, tout ça pour le cas "je dégivre mon pare-brise". Il me semble qu'il y a aussi des test résister de façon raisonnable à un passage en machine à laver. Tout ça pour faire un moyen de paiement… Imaginez comment les premiers fabricants de carte à puce se sont pris la tête!
[^] # Re: rien de neuf ?
Posté par Philippe F (site web personnel) . En réponse au journal Rapport Anses sur les effets des OEM sur la santé. Évalué à 1.
J'ai entendu des esprits sceptiques dire que si on étudiant les risques liés au tabagisme comme on étudie aujourd'hui les risques liée au téléphone portable (et à la saturation d'onde en général), on en arriverait à la même conclusion: a priori pas dangereux pour un usage modéré.
Difficile sans être un expert et y consacrer beaucoup de temps de se faire une réelle opinion. Mais je reste sceptique de mon côté sur l'innocuité globale à long terme du truc.
[^] # Re: BIND
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le programme de Google pour améliorer la sécurité des logiciels libres. Évalué à 7.
Bah, c'est un héritage. C'est un peu comme la syntaxe des Makefile dont on parlait il y a peu, ou le format des .mailfilter , ou les autoconf, ou la syntaxe de sh pour faire des expressions booléennes. C'est pourri mais on fait avec parce que c'est ce qui est disponible partout et par défaut.
Après, aux autres de prendre la place. Apache n'est pas encore détroné mais a perdu beaucoup de terrain, le système d'init vénérable de Unix est aussi détroné, lilo est détroné. On se débarrasse de plein de vieilleries avec le temps…
[^] # Re: Autres PEP de développeurs français
Posté par Philippe F (site web personnel) . En réponse au journal L'interpréteur de Python 3.4 sera plus interactif. Évalué à 6.
C'est bien ce que je dis: un bug, quelques semaines de dev, deux fois plus les tests et lire la doc, et encore deux fois plus pour en discuter sur Python-dev. Et au final, une PEP, pour un truc où 99.99% des gens ne sauront jamais qu'il y avait eu un problème avant. Respect!
Ce que je trouve intéressant en suivant python-dev, c'est qu'on voit d'une part l'attachement très fort des développeurs à ne rien casser (j'imagine qu'ils en ont mangé pas mal par le passé), d'autre part on voit la réflexion de fond sur le long terme et l'attention à chaque détail. On arrive d'ailleurs toujours à la conclusion (sur des fonctionnalités pointues) qu'à un moment, Python ne peut pas résoudre tout et les problèmes de l'OS ou les différences de fonctionnement des OS en dessous finissent par se voir. Ca s'est vu sur la clock monotonic, sur l'unicode ou sur l'héritage des file descripteurs.
J'aime aussi beaucoup lire le travail de cette communauté: les développeurs sont globalement très moteurs, acceptent les critiques et sont prêts à se remettre en question, même quand le travail est en amont est très conséquent.
On pourrait parfois penser que Python est assez complet et très stable, mais il y a toujours des propositions d'évolutions très importantes.
Bref, du beau boulot !
[^] # Re: Autres PEP de développeurs français
Posté par Philippe F (site web personnel) . En réponse au journal L'interpréteur de Python 3.4 sera plus interactif. Évalué à 6.
Et si on rajoute en plus les PEP où Antoine contribue fortement sous forme de commentaires et revues, plus ceux où il est PEP Dictateur, plus les autres contributeurs français, on peut dire que les français font avancer Python à grand pas !
Victor, je voulais d'ailleurs te dire mon respect pour plonger dans les sujets aussi tordus que ceux que tu abordes (unicode à tous les étages, héritage des descripteurs, etc), qui demandent vraiment d'aller creuser tous les cas tordus dans toutes les plate-formes. C'est un travail de fourmi, avec très peu de retombées visibles, qui rendent pourtant Python beaucoup plus solide.
Un merci à toi et autres contributeurs.
Philippe (fan de python-dev)