paul a écrit 146 commentaires

Salut,

je profite du sujet pour poser une question à la tribune qui s'y connaît certainement mieux que moi. Dans le cadre de mon boulot, je dois lire beaucoup de contenus sur écran (un LCD rétro-éclairé standard), et ça m'arrache les yeux au bout de quelques heures. J'aimerais transférer ça sur un écran de liseuse pour limiter ma fatigue, seulement il me faudrait un appareil qui puisse ouvrir les PDF et les contenus web, au moins via un rendu simplifié. Savez-vous si ce type d'appareil existe ? Merci.

Oui oui, et puis mieux vaut un bon programme qu'un mauvais programme.

C'est vrai, mais je pense que zenitram voulait surtout mettre en avant le côté mainstream de C++. C++ est tellement répandu dans l'existant et dans l'industrie qu'il est, de fait, indéboulonnable pour encore un bon moment. Un peu comme Java ou Python.

Ce n'est pas le cas de Haskell, qui ne pèse pratiquement rien dans l'industrie, et dont la communauté est tellement petite qu'il ne s'y trouve personne de suffisamment motivé pour faire des bindings pour Qt :)

Sinon j'ai l'impression que les bindings WxWidgets (également écrit en C++) sont bien plus courants que les bindings pour Qt. Une explication à cela ?

Clair. Je suis bien d'accord pour dire que Java est un langage de merde, mais ce n'est pas franchement lent. Sur les tests du shootout, Java se situe dans une fourchette 1 à 3 par rapport à C++. Pourtant ces tests sont des sections de code extrêmement discriminantes sur le plan calculatoire. Sur un programme classique, je doute qu'on puisse percevoir une différence de vitesse d’exécution.

Pour la gestion de la mémoire sans tracasserie, un bon ramasse-miette reste ce qui se fait de plus simple pour le programmeur. Ça existe depuis un bon moment en plus, il n'y a pas besoin d'attendre la finalisation de C++14 :)

Je contrôle, occasionnellement, le taux de charge du ramasse-miette dans mes programmes. Ça ne dépasse généralement pas 2% de l'activité du programme. Ce n'est pas 0%, je suis bien d'accord. Mais en échange de ces 2%, je ne m'occupe de rien niveau mémoire, et je peux faire de la prog fonctionnelle l'esprit tranquille, notamment pour ce qui concerne la gestion des données référencées dans les fermetures lexicales.

Salut Zenitram,

si tu connais bien le C++, que tu as fait des tas d'applications, que tu as tes librairies aux petits oignons, que tu as déjà rencontré toutes les situations compliquées … bref, si tu es super expérimenté, je comprends parfaitement que tu utilises ce langage même pour des applis utilisateur.

Moi qui n'ai pas cette compétence, et qui ai du mal à garder une vision claire de la sémantique de mon programme quand le code est rempli de boucles, de gestion de la mémoire, d'effets de bord variés … bref, moi qui manque clairement d'expérience en langages bas niveaux, je suis totalement improductif en C++.

Je fais la grande majorité de mes programmes en Haskell depuis 4 ans, et je n'ai pas prévu de changer avant longtemps. On peut être moderne et fidèle ;)

Un jour probablement, dans 15 ans de ça, je connaîtrai ce langage sur le bout des doigts, et malgré l'existence de nouveaux langages plus adaptés à mes besoins, je continuerai à démarrer des nouveaux projets en Haskell, par habitude. Mais ce n'est pas pour ça que ce sera un bon choix pour la nouvelle génération :)

C'est bien de comparer les librairies, c'est très instructif. Cela dit, ça aurait été plus accessible de le résumer sur une page web, plutôt que de passer des heures à troller avec son public comme le fait Dirk dans cette vidéo.

Moi j'aime bien Qt, c'est clean et ça fait du bon boulot. Mais dans la plupart des cas, les interfaces graphiques sont destinées à des applications de bureau. Je ne sais pas pour vous, mais moi ça fait belle lurette que je ne code plus ce genre d'applications avec C ou C++. L'informatique a évolué en quelques décennies.

Du coup se pose la question de la disponibilité des bindings requis pour faire fonctionner le toolkit graphique avec son langage. Et là, hélas, on a rarement le choix. Dans les langages que j'ai utilisés dernièrement, les bindings Gtk étaient fonctionnels et à jour, et les bindings Qt obsolètes ou absents.

Si Dirk, Linus, et leur pote de plongée mainteneur de Qt pouvaient par exemple, entre deux paliers de décompression, coder et maintenir des bindings Qt pour Haskell, on leur en saurait gré.

Merci à eux :)

allez, je suis bonne pâte, malgré la mauvaise notation de mon commentaire précédent, je retente d'apporter un peu d'information. Voici donc une vraie explication (en anglais par contre) :

http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html

Merci, mais la brève ne me paraît pas très claire. Si je comprends bien il s'agit simplement d'un copier-coller depuis ruby-lang, avec la typo "à début des" telle quelle :)

Il m'arrive souvent d'attendre que ma copine finisse son cours de danse, et je ne confirme pas tes propos. Perso, je ne trouve pas non plus le choix de l'exemple de la dépêche particulièrement fin, pertinent ou même drôle.
J'ai cessé d'aller dans les soirées entre informaticiens parce-que j'étais fatigué d'entendre toujours les mêmes blagues et les mêmes références grasses tourner en boucle. Contrairement à ce qui est dit plus bas sur les sportifs, quand je vais à des soirées avec mon club de sport, ça ne se passe pas de la même façon.
Quand je dis que je suis informaticien, je sens que je suis étiqueté « lourd », et c'est franchement pénible. Quand ma copine ou des amis extérieurs se trouvent dans mon groupe d'informaticiens, ça ne change rien au niveau des vannes. À défaut de pouvoir connaître le niveau en mon absence, je peux au moins dire que quand je me trouve dans le groupe de mes amis ou avec les amies de ma copine, je suis épargné.
Donc non, vraiment, ce n'est pas mon expérience :)

Aux dernières nouvelles ESR va bien.

La perception des langages dépend des goûts, et pour ma part je trouve Haskell 98 très simple et minimaliste, donc tout sauf abscons.
Pour le compilo en revanche, je suis tout à fait d'accord avec ton analyse, ça fait une sacré dépendance si c'est juste pour configurer son WM ;)

XMonad, un autre gestionnaire de fenêtres, parvient à combiner tous ces avantages également. La technique est proche, et demande donc également de disposer d'un compilo. Avec 2 ans de recul là dessus, je trouve que c'est une approche excellente pour les projets qui demandent une configuration fine et stable.
En parlant d'XMonad, c'est 1200 lignes de code, et un système de modules optionnels gravitant autour. En moins de 2000 lignes en tout, on a toutes les dispositions et fonctionnalités nécessaires. Et sans erreur de segmentation ;)

Salut,

Je ne crois pas qu'il y ait de telle rumeur, il y a juste des gens qui communiquent sur l'importance de la cohérence entre les notions de Données Publiques, d'OpenData, d'OpenStreetMap, de Logiciel Libre et de plateforme ouverte. Et ces gens, dont je fais partie en tant que co-développeur de Mobi’Rennes, participent au concours avec entre autres ces motivations.

Je suis d'avis que ceux pour qui le logiciel libre compte se soutiennent dans ce concours, car ça augmentera les chances de faire entendre ce point de vue. Pour moi, ça ne signifie pas forcément de faire un inventaire de tous le monde à chaque fois qu'on présente ce qu'on a fait. Mais juste un brin de courtoisie sur les journaux des autres sera déjà très apprécié, et permettra probablement d'ouvrir une discussion constructive sur les moyens de promouvoir le libre à l'occasion du concours.

Sinon, je suis en ce moment même sur le site de bus de rennes en ligne, et je ne trouve aucune information concernant le code du service ni sa licence. Ai-je mal regardé ? Est-ce un oubli ?

En tout cas, comme le suggère le journal, il faut aller voter pour les applis, c'est facile, ça motive les développeurs et ça fera forcément parler des technos et licences employée :)

merci pour la correction, c'est clair sauf pour la phrase suivante qui porte à confusion :
iMatix a pendant un temps développé OpenAMQ, mais soutient et développe désormais ce projet.

Ce type d'outil promet de permettre de remplacer le stockage de blobs dans le système de fichier par un stockage via un service, lequel se débrouillera pour être fiable. L'idée est très plaisante !

Je ne parle pas Breton, mais je suis enthousiaste devant de telles initiatives. Voila qui apporte un peu de charme à ce monde informatique, bien terne quand trop aligné derrière les cultures dominantes.

À ceux qui ne voient pas l'intérêt de parler Breton car c'est une langue aujourd'hui minoritaire, je recommande d'oublier également le français et de se mettre au mandarin ou à l'anglais exclusivement, ainsi qu'à Microsoft Windows, ce sera plus simple, plus efficace et plus uniforme.

Ironie à part, les langues ne sont pas des normes ou des protocoles informatiques. Elles sont chargées d'histoire, de culture et de poésie. Les balayer avec mépris parce qu'elles ne se sont pas imposées par la force au reste du monde me semble étroit d'esprit, et surprenant de la part d'un libriste !

Bonne continuation à l'équipe de traduction, merci pour cette diversité rafraichissante !

Erlang est également un bon candidat pour tes besoins, et il fait de la vraie concurrence sans partage de mémoire, donc il permet trivialement de distribuer le travail. Il existe des exemples de serveurs HTTP en Erlang.

Hoy,

c'est long à compiler certainement, mais à la fin t'as du code machine, donc la valeur ajoutée de la compilation ne se limite pas à l'analyse statique. Le facteur de gain en vitesse d'exécution entre une implem ruby MRI 1.9 et Haskell GHC 6.10 est de l'ordre de 50 en moyenne ... Je suis prêt à attendre 3 minutes que mon projet compile pour un tel gain. Le gain en mémoire est considérable également. Mon job est de développer et d'héberger des applis en RoR. Quand je vois comme c'est lent et tout ce que ça mange comme mémoire, malgré l'utilisation de toutes les optimisations possibles, je ne trouve pas que ce soit un problème secondaire.

Le temps requis pour aboutir à du code fonctionnel à 90% est inférieur en ruby qu'en haskell. Mais je pense que le temps pour aboutir à 99% est inférieur en haskell qu'en ruby ;)

Enfin, un système de types tel que celui de Hindley-Milner (cf journal récent) permet d'exprimer une grande partie de la logique de ton programme avec des types. Peu importe si la représentation sous-jacente est à chaque fois une chaîne de caractères, tu peux définir un type nom, un type prénom et un type numéro de téléphone, et l'analyse validera leur utilisation dans ton programme.

Le typage valide est une condition nécessaire à la fiabilité du code bien qu'elle ne soit pas suffisante, c'est vrai. Une couverture de tests complète est indispensable pour faire la qualité. Seulement, il y a des choses que tu ne pourras pas faire avec des tests, parce que ce serait trop long. Par exemple, hier j'ai voulu recompiler 'gitit', un wiki correctement conçu, avec la nouvelle version d'une librairie SMTP. Cette dernière venait de changer d'interface. Paf, les types avaient changé et les noms de fonctions aussi. Le compilo m'a directement dit que ça ne passerait pas, inutile de continuer. Sans cette analyse statique, il aurait fallu que je relance toute la couverture de test après coup, et franchement non merci ... En plus, je n'ai pas envie d'écrire de façon systématique des tests destinés à mettre en évidence des erreurs qui peuvent être détectées par une analyse statique.
Sinon, je manipule régulièrement 3 langages : haskell, ruby et scheme. Ces deux derniers sont très proches, certes. De façon générale, j'écris nettement moins de lignes de code en haskell pour faire la même chose. La vérification statique est poussée et les performances sont incomparables avec les deux derniers. Ça me fait bien réfléchir, après 6 ans de ruby et 3 de rails ...
Enfin, je ne veux pas juger les développeurs, il y a mille contraintes dans les projets qui peuvent pousser à devoir utiliser telle ou telle techno. Mais je ne me gène pas pour juger les langages, et PHP en l'occurrence, est grossier, car il cumule tous les défauts de tous les langages, sans en avoir la moindre qualité :)

... me fait penser aux mouvements des langages dynamiques avec typage dynamique voir typage faible, qui présentent l'incapacité d'analyse statique comme une qualité !
Ce mouvement surf sur la frustration qu'on peut ressentir à devoir respecter tout un tas de contraintes pour aboutir à une structure validée, que ce soit un programme correctement typé ou une base de donnée avec des relations valides. C'est un peu, de façon générale, le mouvement noRTFM. On ne veut plus étudier et concevoir, on ne veut plus de contraintes statiques, on veut retarder au maximum le verdict, on veut des outils les plus souples possibles et puis après tout, si on a envie d'y mettre n'importe quoi on a le droit, on s'en rendra compte nous même. Peut-être un jour en production parce que, dans le meilleur des cas, le code plantera et dans le pire il donnera une info erronée parce que 1 + null == 1.
J'ai testé CouchDB et tenté de l'appliquer à un programme. Constat : c'est plus proche d'un système de fichier spécialisé que d'une base de donnée relationnelle. C'est pratique pour certains cas, je n'en doute pas, mais qu'on arrête de dire que ça va concurrencer des bases relationnelles. Si le résultat c'est que les scripteurs PHP qui subissaient le relationnel abandonnent tout simplement le relationnel au lieu de l'apprendre, ce ne sera pas vraiment un progrès :)

Ah, pour être tout à fait honnête, il y a un aspect qui m'a beaucoup séduit : la réplication. Je suis fan de décentralisé, donc j'aimerais que les BDD relationnelles proposent des mécanismes de réplications aussi simples que ce que propose CouchDB. Il suffirait probablement que les clefs primaires ne soient plus séquentielles. Savez-vous ce qui existe pour cela ?

Real Men Use Functional Programming : http://happs.org/ http://happstack.com

Je voudrais juste signaler que je ne retrouve pas *du tout*, dans mon entourage, les chiffres effrayants de taux d'infection avancés par le gouvernement. C'est peut-être du à mon groupe socio-professionnel, mais je ne connais *personne* chez qui cette fameuse grippe a été diagnostiquée ...
Et vous ?

Les chefs d'état n'en finissent pas d'organiser des conférences, des sommets, des grenelles de s'agiter. Ça a commencé en 92 à rio, tout le monde était d'accord, mais pas d'objectif chiffré ... c'était donc il y a 17 ans. Depuis, les travaux scientifiques convergent vers un modèle dont les résultats font peur, n'en déplaise aux autruches. Malgré cela, on enchaîne les sommets, la com', les accords de principe, mais sans aucun engagement concret, donc sans aucun résultat. Le climat se soucie peu des effets médatiques des chefs d'état, il n'y a pas 36 mesures à prendre, il faut *diviser par 4* les émissions de GES mondiales pour espérer contenir le dérèglement à un niveau supportable. Voila, donc maintenant faut s'engager sur des mesures et s'y tenir, sinon point de résultat.

Derniers relevés vs prévisions modèles : http://france.meteofrance.com/france/actu/actu?portlet_id=50(...)

Une analyse du sommet de copenhague : http://tempsreel.nouvelobs.com/speciales/environnement/le_so(...)

Une dépêche bien rédigée avec des termes français clairs et appropriés, c'est très agréable à lire, merci !