gasche a écrit 1151 commentaires

Je pense que c'est à peu près "ça que je veux dire", même si ton truc est un peu ambigu donc je suis pas certain. Par contre si ton code pour récupérer le résultat pour chaque champ est un peu gros, t'as intérêt stylistiquement à déclarer des variables locales avant, un truc du genre

Elem ("field", infos, fils) ->
let name_f = parse_name(infos) in
let type_field = parse_type(fils) in
...
{ name_f = name_f; type_field = type_field; .. }

C'est la même chose, bien sûr. Et bien sûr t'es pas obligé de déclarer une fonction séparée pour par exemple parse_name si sa définition est très simple, c'était juste pour dire de pas forcément tout mettre dans le tuple.

Bon déjà les deux commentaires évident :
- essaie de respecter la règle des 80 colonnes, ton type "field" est pas lisible
- tu as regardé les outils déjà existant qui parsent directement Java -> Ocaml ? Ça existe sûrement, pas mal de gens font de l'analyse statique de Java en OCaml, après leur AST est peut-être pas exactement comme le tien, mais ça me semblerait la méthode la moins fatiguante pour toi


Sinon, bah tu n'as pas le bon point de vue : pour toi on donne le "field en cours de construction" aux sous-fonctions qui vont explorer les fils de ton noeud XML pour rajouter les infos. Ça suppose des effets de bords et des trucs pas nets. Il vaut mieux faire l'inverse : ta fonction qui parse les fields _appelle_ les sous-fonctions (c'est elle qui dirige le flot de contrôle, pas les fils), récupère tous les résultats d'un coup et s'en sert pour construire l'enregistrement, en une seule fois.

Entre nous je pense pas que l'approche XML soit la plus simple pour ton truc. Dans 90% tu as des arbres qui ont "un seul enfant de tel type", en XML tu as une liste d'enfants tous types mélangés, tu dois filtrer sur l'attribut et gérer le cas où il n'y en a aucun/plusieurs, c'est pas très pratique. Tu tiens vraiment à ton frontend XML ?


PS : pourquoi il me fait chier en quotant les guillements, le moteur qui affiche la prévisualisation ? Quand je fais "sans HTML" c'est pire, il pourrit mes accents en plus.

« ça pue, c'est pas libre »

Deux remarques :
- le meilleur score n'est pas 1, il me semble que 1 décrit la valeur moyenne; il peut y avoir des scores négatifs, et les meilleurs scores sont (dans les sous-classements) souvent supérieurs à 2
- il y a deux classements, la france n'est en tête que de l'un des deux

Les deux classements sont Activity et Environment. Activity représente l'état actuel du libre dans un pays, et Environment les "potentialités de développement du libre". La France est en tête du classement Activity, mais pas si bien placé dans Environment (environ 15e si je me souviens bien). Ce bon classement est du à notre excellent score Government.

Ironie, Dadvsi et Hadopi et un bon score Government ? Non, parce que :
- des mesures locales (de régions et/ou de grandes villes) sont aussi prisent en compte
- l'étude principale qui donne les chiffre Government se base sur des faits entre 2000 et 2005
environ, il me semble que la situation actuelle n'entre pas en jeu

Pour le reste, les pays européens et les USA sont globalement bien classés, surtout l'Allemagne et certains pays nordiques.

J'ai passé un peu de temps à farfouiller sur le site de Red Hat et les divers papiers à ce sujet, et j'en ai conclu que les résultats n'étaient pas encore exploités de façon satisfaisante. L'étude précise bien que les scores ne sont pas pondérés pour l'instant, je pense qu'il faut attendre que les gens décident d'une pondération pertinente pour avoir des résultats vraiment utiles.

De plus, les critères "Environment" sont à mon avis assez discutables : ils comptent des choses comme le nombre d'ordinateurs par habitant, ou l'accès internet par habitant, qui favorisent énormément les pays développés. Ce n'est pas idiot (un pays où tout le monde a accès à internet a plus de chance d'avoir des développeurs impliqués dans le libre), mais ça n'est pas non plus une mesure fiable du "potentiel du libre dans les pays" à mon avis : je vois beaucoup plus de potentiel pour des pays émergents qui veulent réduire leurs coût logiciel que dans un pays développé ancré dans ses habitudes propriétaires.

En bref, cette étude est une bonne démarche et a permis de rassembler des données intéressantes, mais je pense qu'il ne faut pas en tirer de conclusion hâtives tant que ces différentes données n'ont pas été analysées plus en profondeur, correctement pondérées et interprétées.

Il s'agit d'un gain observé sur un benchmark spécifique, c'est à dire un petit bout de code fait exprès pour tester intensivement certaines caractéristiques du compilateur. D'une part, ne t'attends pas à observer des gains similaires sur les "programmes normaux", et d'autre part les gains ne sont pas forcément spécifiques aux Athlon (la personne cité parle des Athlon, soit parce qu'il a testé dessus, soit parce que des particularités de l'architecture font que c'est une optimisation spécialement pertinente dessus, mais le code ne dépend pas de l'architecture).

En gros, c'est une manière de dire : "Pour ce petit programme très spécialisé, mon optimisation tue tout ce qu'on sait faire pour l'instant, donc c'est une super optimisation". Ça veut pas dire que les gains seront tellement énorme en pratique (peut-être, mais ne rêve pas trop).

Pour les cadres graphiques, les images et les polices différentes ce n'est pas une fonctionnalité que j'attends d'un éditeur de texte. Pour un traitement de texte, pourquoi pas, mais emacs se présente comme un éditeur de texte il me semble.

Quand tu crées un document LaTeX sous emacs (avec AucTeX-mode roxx), et que tu utilises le mode "preview" qui remplace dynamiquement les formules mathématiques que tu insères par leur "vrai rendu" (des images donc), c'est tellement plus agréable à relire pour repérer les erreurs que tu es bien content d'avoir un éditeur de texte qui sait afficher des images.

J'ai aussi trouvé ça techniquement très réussi, mais pour ce qui est de l'histoire, je dois dire que j'ai beaucoup moins accroché qu'à Elephant Dreams.

En haskell :

attaque :: perso -> perso -> resultat
robert `attaque` martin

attaque :: perso -> perso -> arme -> resultat
avec a b = a b
robert `attaque` martin `avec` manchette

[aussi disponible en version avec manchette (robert `attaque` martin), pour une autre définition de avec ou de attaque]

Excellente idée, une petite introduction à Haskell.

Pour ceux qui ne l'ont pas encore, essayez de ne pas vous y prendre à la dernière minute, GHC c'est pas rapide rapide à compiler :-'

Oh oui, je vois d'ici les nouveaux trolls Qt/GTK Emacs/Vim KDE/Gnome KDE3/KDE4 (new !) Firefox/Konqueror/Epiphany sur la consommation mémoire.

Ça sera peut-être utile aux développeurs, ou au moins tout à fait excitant.

Je conseille moi aussi OCaml, mais pas exactement pour les mêmes raisons.

OCaml est en effet un langage très puissant, très rapide, portable, toussa.
C'est très bien pour un langage, mais je dirais que c'est pas non plus l'essentiel quand veut apprendre un paradigme de programmation.
Plus exactement, je souhaite expliquer dans le reste de mon post pourquoi OCaml serait le meilleur choix même s'il était moche et lent :p


Au niveau du langage (ses fonctionnalités, ce qu'il te permet de faire, ce qu'il t'encourage à faire) OCaml est un juste milieu admirable. Il est fonctionnel, mais pas uniquement : si tu veux faire du code impératif par moment, parce que c'est plus adapté au problème, tu peux le faire simplement.

Je pense qu'il est plus facile d'approcher efficacement la programmation fonctionnelle avec OCaml (ou Caml, ou sans doute SML) qu'avec Scheme/Lisp :
- c'est un langage qui met plus en avant la programmation fonctionnelle (listes mutables par défaut, etc...)
- il possède des features qui n'existent pas de base en Lisp/Scheme, et qui sont assez cruciales dans la programmation fonctionnelle moderne : typage fort (et en plus, inféré), types algébriques et filtrage de motifs

Je pense qu'il est aussi plus facile d'aborder OCaml que Haskell, surtout quand on vient de l'impératif :
- on peut "facilement" faire de la programmation impérative, ou en partie impérative. Ça permet à mon avis une adaptation plus en douceur (mais sans complaisance : la plupart des camliens favorisent fortement le style fonctionnel). L'équivalent Haskell (les monades) est vraiment difficile à comprendre pour un débutant en programmation fonctionnelle, et assez lourd à utiliser.
- l'évaluation est stricte par défaut : tu n'as pas à apprendre en plus directement l'évaluation paresseuse, qui (malgré ses nombreuses qualités par ailleurs) vient avec un coup de compréhension non négligeable, et pose de nombreux problèmes (et pas seulement aux débutants). Elle n'est absolument pas nécessaire pour apprendre la programmation fonctionnelle, et par ailleurs je pense même qu'il est plus facile de l'aborder calmement dans un langage où elle est explicite (comme en OCaml) que dans un langage où elle est implicite (comme en Haskell).

Bref, je pense que OCaml est un compromis idéal entre la simplicité et la représentativité des concepts de programmation fonctionnelle moderne.

"programmation fonctionnelle" est un terme qui a beaucoup de significations différentes. Une définition (légèrement caricaturale) qui a tendance a ne fâcher personne serait :
la programmation fonctionnelle, c'est l'utilisation en programmation de techniques d'abstraction puissantes, rigoureuses, belles et érotiques, inspirées des mathématiques

Tu auras donc forcément un peu de mathématiques à un moment ou un autre. Si tu n'as pas de mathématiques, tu auras au moins des concepts qui utilisent franchement la même (voire les mêmes) parties du cerveau. Si tu ne peux pas *du tout* blairer les mathématiques, tu risques d'avoir de problèmes (mais, qui sait, c'est peut-être aussi le moment d'une révélation ?).

Après, il y a maths et maths, tu peux trouver des approches de la programmation fonctionnelle très formelles, d'autres moins. Si un document t'as semblé trop mathématique (tu aurais un lien à ce sujet ?), tu pourras sûrement trouver plus abordable.

Mysql m'apporte

- La liberté d'exécuter le programme, pour tous les usages
- La liberté d'étudier le fonctionnement du programme, et de l'adapter à mes besoins
- La liberté de redistribuer des copies, donc d'aider mon voisin
- La liberté d'améliorer le programme et de publier mes améliorations, pour en faire profiter toute la communauté

En quoi ne serait-il "pas fondamentalement libre" ? Ça te gêne qu'ils fassent de l'argent à côté ?

Justement, c'est une des options que les développeurs KDE sont libres d'accepter maintenant :
« Are you okay with the KDE e.V. deciding on a future licensing change to your code, should that be necessary ? »

Honnêtement, j'ai lu l'article et je ne vois pas ce qui mérite un ton aussi "sec" (pas tellement le journal lui-même, mais surtout le premier commentaire assez agressif).

Certes, l'article n'est pas distant et impartial. Mais c'est normal, c'est un édito. À part quelques phrases un peu dramatiques ("Tout ce qui est interdit aux médias classiques écrits et audiovisuels est permis sur Internet") je trouve le contenu assez civilisé.

En particulier, contrairement à ce que tu dis, il ne me semble pas du tout clair que Wikipédia soit visée dans tout l'article. Il en parle au début (il se raccroche à un fait d'actualité pour lancer sa diatribe, normal), mais les citations que tu donnes sont à la fin (Big brother, recul démocratique...) et entre les deux, de l'eau à coulé sous les ponts. Dès le début du deuxième paragraphe déjà, on parle clairement d'Internet en général et plus de la seule wikipédia :

Le Net est bien sûr un outil formidable de travail et de communication.

Enfin, le ton général est en effet un peu alarmiste, mais je n'y vois rien de rétrograde, et au contraire une question tout à fait pertinente : les nouvelles technologie offrent de nombreuses possibilités, en bien comme en mal, peut-on profiter des bons côtés et se protéger des mauvais ? C'est pas bien original comme réflexion, mais ça n'est pas non plus "stupide".

Pour en revenir au cas particulier de la wikipédia, je peux comprendre dans une certaine mesure la frustration des gens. Je n'aimerais pas que la première page proposée par Google quand on demande des informations sur moi affiche des informations relevant de la sphère privée et qui me gênent. Attaquer la wikipédia n'est pas la chose à faire (et en ce sens le jugement me semble très positif vu qu'il limite l'insécurité juridique globale de l'encyclopédie), mais il reste quand même un problème dans le fond, et il n'est pas inutile que des gens cherchent à en discuter.

Je suis toujours agréablement surpris par la qualité du "Kernel Corner" de Gnu/Linux Magazine France. C'est très détaillé, très accessible (je ne connais pas spécialement la conception de noyaux), et très riche : je suis le RSS de KernelTrap quotidiennement, et pourtant j'apprend encore des choses dans le Kernel Corner.

Le reste du journal ne m'intéresse pas beaucoup en général (ça concerne des domaines que je ne connais pas et qui ne m'intéressent pas forcément beaucoup), mais ces quelques pages sont un véritable plaisir à lire, et justifieraient presque (à mon avis) un achat rien que pour ça :p

Quand un auteur diffuse son oeuvre, il choisit la licence. Il n'y est pas lui-même soumis. Il peut la changer quand il le souhaite (c'est à dire diffuser de nouvelles versions sous une autre licences, les versions précédemment distribuées n'étant pas, à ma connaissance, rétro-activement relicenciables).

Si tu achètes le travail d'un développeur, tu peux acheter le copyright (dans le droit français il y a des droits inaliénables qui ne sont pas vendables, il me semble, mais c'est pas grave ici), et donc devenir la personne qui a le droit de changer la licence si elle le souhaite. De même, si tu paies des développeurs pour travailler sur un projet (ils sont embauchés), tu peux avoir les droits sur leur travail (enfin ça dépend du contrat qu'ils ont signé).

Évidemment, tant que tu n'as pas le copyright de l'ensemble du logiciel, tu es soumis aux obligations des parties sous GPL des autres auteurs (du point de vue desquelles tu es un utilisateur acceptant la licence). Il faudrait donc acheter les copyright de chaque contributeur (du moins de toutes les contributions qui sont sous GPL), ou retirer leur code du logiciel.

Pour régler ce problèmes, certains projets ont une politique de "don de copyright" (je ne sais pas si c'est le terme exact) : quand tu contribues, tu acceptes de donner en même temps les droits sur ton travail aux développeurs principaux (ou à la boite qui gère ça, comme Novell pour Mono par exemple). Ça leur permet une plus grande flexibilité à ce niveau là.

L'intégration à Gnome c'est très bien, si les gens se sentent à l'aise avec l'interface, pourquoi pas.
Mais je vois que GIMP commence à utiliser en profondeur des bibliothèques GNOME. On passe de l'intégration de l'interface à une dépendance plus profonde au niveau du logiciel.

Moi qui n'utilise pas GNOME, je n'ai pas les bibliothèques du projet GNOME. Ça veut dire que pour installer Gimp à l'avenir, il me faudra prendre en plus des dépendances qui ne m'intéressent pas des masses.

Je suis bien conscient de l'utilité pour les développeurs de pouvoir se reposer sur des bibliothèques déjà existantes pour certaines utilisation. On ne peut pas les blâmer de profiter de l'environnement de bureau construit autour du toolkit dont ils sont l'origine.

Cependant, en tant que non-utilisateur de GNOME, je suis un peu inquiet par ce rapprochement. C'est un peu comme si on disait demain "Le logiciel Blender a décidé d'utiliser Plasma pour son interface graphique". Évidemment, je ne suis pas très au courant de l'architecture GNOME, et je sur-estime peut-être cette dépendance. Un peu d'éclaircissement là-dessus serait bienvenu.

Je pense qu'un peu de neutralité au niveau de l'interface serait bien utile pour le logiciel qui est actuellement l'outil graphique de prédilection des bureaux libres *en général*. Si GIMP s'éloigne des autres bureaux, ne risquent-ils pas de s'éloigner de GIMP à leur tour ?

Ce qui m'intéresse personnellement dans cette histoire, c'est le concept d'utiliser des outils pour étudier des points précis de la Wikipédia (et donc potentiellement de l'améliorer).

Je sais que cette approche est mise en avant depuis longtemps (j'avais vu que les gens de MediaWiki proposaient des moyens de coder des machins en python, mais j'ai pas trop regardé), et j'ai vu passer quelques trucs très très intéressants; je pense à http://www.research.ibm.com/visual/projects/history_flow/ind(...) , et surtout http://dbpedia.org/docs/ .

Je pense que cette voie est très prometteuse, et que c'est en quelque sorte une des meilleures manières dont on peut, en tant qu'informaticien/cherceur, contribuer à wikipédia.

Et pis bientôt, du simple fait que quelqu'un se connecterait d'un réseau d'entreprise un peu connu, il n'aurait plus le droit de mettre à jour des pages wikipedia, parce qu'après on dirait "tiens, un gars de chez TEL-BOÎTE donne son avis sur TEL-SUJET", même si ce sujet n'a rien à voir avec la boîte?

Ce qu'il faut bien comprendre, c'est qu'on ne stigmatise pas les gens *pour la simple raison* qu'ils contribuent en appartenant à telle ou telle entreprise.
L'outil n'est pas fait (enfin, c'est mon analyse) pour qu'on dise "bouh les gens de la CIA éditent quand ils sont au boulot, scandale", mais pour qu'on repère, parmis ces contributions, celles qui constituent *réellement* une atteinte à l'impartialité et la qualité des articles, permettant de les corriger ainsi plus facilement.

Comment les incultes des commentaires précédent ont ils fait pour ne pas voir la référence explicite à Frag, le seul et unique FPS (libre) fait dans un langage qui se respecte ?

http://haskell.org/haskellwiki/Frag

Miguel de Icaza, celui qui dirige le projet Mono ?

Celui qui a dit après l'annonce de l'accord Novell-Microsoft :
« In my personal opinion, I think that we have to give it the benefit of the doubt, try to turn the hand that has been dealt into the best possible outcome for everyone. Or as Benjamin Zander would say, I will give them an A, and work from there. »

Il n'est peut-être pas à la solde de MS, mais ce n'est pas non plus celui qui a du faire le plus de concessions pour penser du bien de OOXML.

En gros, tu proposes de ne rien faire, et de dire ensuite « on vous l'avais bien dit !» ?

Pas très convaincant.

un listing des fautes d'orthographes à bluestorm point dylc chez gmail serait parfait.

On est toujours le con de quelqu'un.