anaseto a écrit 2229 commentaires

Que le support final soit un fichier texte n'a rien à voir avec la résilience, l'important c'est comment ce fichier est manipulé.

Je suis bien d'accord, c'est juste que parfois utiliser une base de données (relationnelle ou pas) qui fait ce genre de travail, et même si c'est pas très compliqué en soi, c'est plus simple que de le refaire soi-même pour un cas particulier, mais peut-être qu'aller jusqu'à une base relationnelle que pour ça est exagéré, je ne vais pas de contredire sur ce point (ceci dit, ce n'est pas forcément parce qu'un programme propose des fonctionnalités que tu n'utilises pas, qu'il y a plus de bugs dans celles que tu utilises, ça dépend de beaucoup de facteurs: comment les fonctionnalités interagissent entre elles, combien elles sont testées, etc.).

Personnellement, la seule fois où j'ai utilisé sqlite c'est pour écrire un petit moteur de forum (où pour le coup c'est bien pratique). Après, je suis totalement d'accord qu'une base de données relationnelle uniquement pour remplacer un unique fichier de clé = valeur c'est très exagéré. Ça se comprend mieux s'il y a au moins plusieurs tables (ou si l'utilisation d'index est utile). Après, je ne vais pas te défendre le cas particulier de firefox, dont je n'ai pas forcément une très bonne expérience: la seule fois où j'ai voulu récupérer mes bookmarks, je me suis aperçu que l'export en JSON ne donnait pas un résultat particulièrement simple, au point que je me suis contenté d'un export en html puis de substitutions et macros avec vim pour pouvoir les réutiliser avec un autre navigateur.

Et je crains que ça soit trop souvent utilisé pour juste stocker de la configuration (n'est-ce pas firefox?)…

J'apprécie en général quand la configuration est dans un fichier texte, mais il faut voir qu'une base de données peut avoir ses avantages parfois : plus facile de faire des requêtes plus compliquées, on est sûrs que les modifications sont atomiques, que l'état de la configuration va être consistant tout le temps, et on est un peu protégés d'un crash ou d'une coupure d'électricité au moment d'écriture (en l'occurrence, ça n'empêche pas de faire des backups, bien sûr, mais c'est quand même des propriétés intéressantes qui sont pourvues par un truc fiable et très testé). Et puis sqlite c'est quand même une base de donnée avec un seul fichier et zéro configuration à faire, c'est plutôt sympa comme fichier de stockage, je trouve. Après, c'est bien quand le logiciel propose d'exporter et d'importer facilement à partir d'un format texte compréhensible par un humain (ce qui n'est peut-être pas tout à fait le cas avec firefox).

Il n'y a pas de rebase en fossil. C'est possible de réussir à faire la même chose avec des efforts, mais c'est contraire à la philosophie du logiciel (tout les artifacts doivent être immutables et l'historique est censé représenter le plus possible la réalité, pas ce qu'on aurait voulu qu'elle soit).

Ce n'est pas vraiment le poids, mais je n'aime pas avoir des programmes qui font doublon, ou dont je sais qu'il y a peu de chances que j'utilise la moitié des fonctionnalités de base.

Dans l'idée je suis d'accord, mais en même temps, c'est un peu inévitable (je ne connais pas de loin la moitié des fonctionnalités de git non plus, ni de beaucoup de programmes que j'utilise). Et il faut voir aussi est-ce que certains composants sont très réutilisés ailleurs ou non (par exemple sqlite et libcrypto, il y a de bonnes chances que tu en aies besoin pour pas mal de logiciels), donc je pense qu'il faut relativiser suivant les cas.

Je ne sais pas si j'ai été clair : tout le monde a un repo complet en local. C'est juste que par défaut, si tu fais un commit en local, tu fais aussi un push automatiquement vers le dépôt à partir duquel tu as cloné (si c'est possible), ce qui incite les développeurs à synchroniser plus souvent leur travail, tester le code des autres plus souvent et pas trop diverger (mais ce n'est pas un paramètre à activer dans toutes les configurations, bien sûr).

Une autre particularité de fossil, est que par défaut les branches sont publiques (donc clonées automatiquement par tout le monde). Il faut être explicite pour une branche privée.

Pire, c'est de l'édition de liens dynamique, si ça se trouve la moitié du code dans les lib chargées par fossil n'est pas utilisé. Il faudrait des binaire liés en statique, pour en avoir vraiment le cœur net.

Ce n'est pas une méthode de mesure idéale, non :) Ceci dit, chez moi fossil n'importe pas autant de trucs (en particulier pas readline), et git par contre importe libcryto (qui semble faire presque toute la différence chez toi). Enfin, peut-être que mesurer le nombre de lignes de code ou un autre truc serait plus utile, mais dans les deux cas ça ne me semble pas être des logiciels particulièrement lourds au point que ça puisse être un critère pour en choisir un ou l'autre ;)

Je ne comprend pas… tu veux dire qu'à chaque commit, tout est balancé sur le web sur un répo central? Ça casse un des arguments majeurs en faveur des DVCS, qui est de pouvoir coder dans le train (entres autres).

Tu peux aussi (s'il n'y a pas de connexion il fera juste un commit local), et c'est juste un paramètre. Ceci dit, sur des petits projets c'est assez pratique de pouvoir parfois adopter un style de commit sur un dépôt central, pour éviter de faire des forks inutiles qui rendent les merges plus compliqués par la suite.

(pas trouvé a l'époque comment mettre la couleur, et je ne peux pas me passer de ça).

Pas de couleurs maintenant non plus, ça n'a pas changé sur ce point il me semble (perso, ça ne me gêne pas trop dans ce cas).

Autres inconvénients majeurs à mes yeux: celui qui veut utiliser un autre gestionnaire de projet (et non de code) se retrouve du coup avec du bloat (code inutile) en la présence justement du wiki et du bugtracker intégrés.

Fossil est distribué comme un unique binaire, bien plus petit que celui de git (chez moi 1.6M contre 1.9M pour git et 2.2M pour libgit.a, sans compter d'autres binaires et fichiers qui viennent avec git comme la doc (qui est incluse aussi dans le binaire dans le cas de fossil)), donc « bloat » c'est vraiment pas le mot que j'emploierais pour ce logiciel.

Et pour finir, je ne connais pas de forge (service) proposant fossil, hors, ce dont on parle quand on parle de forge, c'est le plus souvent du service de forge, et non des logiciels derrière.

Il y a Chisel, qui utilise du logiciel libre en plus.

Le truc le plus utile du bouzin (je veux dire le gros avantage) nécessitait de bidouiller du SQL brut

Je n'ai jamais eu à utiliser de requêtes SQL manuellement (d'ailleurs c'est déconseillé fortement : c'est la seule façon de risquer de corrompre le dépôt ou de faire une bêtise). Parce que pour le reste, les dépôts fossils sont très fiables, en partie du fait justement d'utiliser sqlite qui a fait ses preuves (probablement la base de données la plus déployée), et de l'utilisation de checks d'intégrité supplémentaires lors des opérations (ce qui ne fait peut-être par contre pas de fossil le plus rapide des DVCS).

Un peu HS, mais je suis toujours un peu surpris de voir à quel point git est prépondérant parmis les gestionnaires de version, alors que sous certains aspects ça ne semble pas le truc le plus simple à déployer. Fossil a moins de fonctionnalités donc ne peut convenir à tous les projets probablement (plus adapté a des projets de petite ou moyenne envergure), mais propose par contre de lui-même (pas un truc externe) gestion de bugs et wiki de façon décentralisée (le tout stocké dans un seul fichier sqlite), et des options par défaut qui me semblent plus adaptées aux petits projets (push automatique après commit par exemple), donc je suis surpris qu'il n'ait pas plus d'utilisateurs.

De ce que j'ai cru comprendre, les optimisations d'OCaml sont assez bien choisies (bon compromis résultat/complexité de mise en œuvre), et le modèle d'évaluation étant assez simple comme a dit Michaël, ça donne de bons résultats sans besoin de faire particulièrement attention (contrairement à Haskell). Et en ce moment il y a de nouvelles passes d'optimisations qui sont faites à l'aide d'un nouveau langage intermédiaire dans le compilateur (de l'inlining surtout, je crois), donc le coût d'utiliser certaines abstractions devrait diminuer encore.

J'ai l'impression que des choses similaires doivent pouvoir être dites de go (qui me semble donner des performances très correctes avec des optimisations pas très poussées, même si ils sont en cours d'ajouter des optims en plus en utilisant un langage intermédiaire plus adapté à des optimisations plus poussées).

Après, pour passer de « très bonnes performances » à « performances à la GCC », j'ai l'impression qu'en pratique ça passe inévitablement par beaucoup de complications et chaque petit pourcentage de plus demande beaucoup d'énergie.

Techniquement ce n'est pas = qui est en faute ici, mais la sémantique de += ;)

Aussi :)

Oui, c'est vrai, mais il n'est pas forcement nécessaire de comprendre une abstraction pour s'en servir et l'utiliser. Prend l'exemple des parseurs type Parsec, je trouve la syntaxe plutôt simple… Pourtant derrière cela utilise des Monades plutôt trapues.

Parsec fait partie de mes librairies préférées en Haskell, et l'interface est simple, je suis d'accord. Je pensais plus à des choses comme ceci : si on veut faire un petit truc simple avec du xml, c'est vraiment une mauvaise idée (je crois que j'avais trouvé un petit tuto dans le haskell wiki et ça s'est sans doute étoffé depuis, mais la documentation officielle est juste impossible à appréhender rapidement, même en connaissant les Arrows probablement).

J'aurais eu une fonction non documenté mais avec un type sérieux, j'aurais été plus heureux ;)

Je suis d'accord qu'en l'absence de documentation, les types c'est mieux que rien :)

Juste pour savoir, quelle langage passe par défaut des références?

Par défaut c'était beaucoup dire, je faisais référence par exemple au fait que les tableaux sont souvent passés par référence, et par exemple en Python dans l'exemple donné par Guillaum une copie b = a d'un tableau ne crée pas une copie du tableau, juste une copie de la référence au tableau (ce qui peut être surprenant, car la même syntaxe crée une vraie copie pour les nombres). Mais bon, c'est pas non plus vraiment un défaut, ce genre d'irrégularités a ses raisons d'être (par exemple, en Perl le fait de rendre plus explicite les références devient parfois verbeux), c'est juste que ça peut être surprenant.

Je pense que c'est justement là le point le plus difficile en programmation: exposer une interface assez simple et claire pour être compréhensible rapidement. Je doute que changer de langage change ça, c'est plus du niveau de l'architecture logicielle?

Ce que je veux dire c'est que si l'interface est pas claire, tu risque de passer un pire moment en Haskell (pas forcément non plus), mais surtout que même si elle est bien faite, il y a plus de chances qu'elle fasse appel à des notions théoriques nouvelles pour être comprise (par exemple la notion d'Arrow permet de voire certaines choses comme faire un filtre sur du xml de façon assez élégante, mais on comprend pas immédiatement pourquoi ça peut être bien, d'ailleurs je ne me souviens plus très bien). Et puis après, d'expérience, j'ai l'impression que plus un langage propose des moyens de documenter automatiquement et formellement (signatures des fonctions, etc.), moins il y a d'exemples dans la doc en moyenne (c'est loin d'être un théorème ce que je dis là, juste une impression et qui a sans doute plus à voir avec les habitudes et traditions du public du langage en question, il y a des exceptions).

Juste une chose, je ne défend pas Haskell bec et ongles, je gagne ma vie en faisant du C++, j'ai contribué et je contribue encore a Python où à des projets en Python et j'apprécie Haskell.

Je précise aussi que je suis loin de détester Haskell, c'est un des premiers langages que j'ai appris parce que le côté mathématique m'attirait (je suis mathématicien à la base), et il y a bien des choses que j'apprécie dans ce langage (en fait, je suis capable sans problème d'aimer des langages aux philosophies totalement opposées :) ).

me fait peur avec ses deux ;;

Les ;; c'est que pour la REPL uniquement, normalement on n'en écrit jamais. Ceci dit, pour Hello World j'exagère un peu en ce qui concerne Haskell, mais pour des choses un poil plus compliquées, si on comprend pas ce qu'est la monade IO dont on ne peut pas sortir, il y a de quoi s'étonner, quand même (quelqu'un qui veut débugger une fonction avec un print aura une mauvaise surprise, par exemple).

Blague à part, je n'ai jamais fais de OCaml car en voyant que tous les étudiants de prépas "prestigieuses" en faisait, j'ai eu l'impression que c'était un langage théorique pour matheux, surtout sachant que c'était poussé par l'INRIA.

Je crois que tu te fais des idées : OCaml c'est à peu près le même public que Haskell, j'ai l'impression, avec un bon pourcentage de public académique qui aime les systèmes de types dans les deux cas. Ceci dit, Haskell a un système de types plus compliqué qu'OCaml, et a un modèle pour l'IO moins simple. Par exemple, utiliser des tableaux mutables (parfois c'est nécessaire) est une plaie en Haskell (soit IO soit ST, dans les deux cas ça ne s'intègre pas très naturellement avec le reste), alors que c'est simple en OCaml et dans la plupart des langages. Tout est question de compromis, et là où Haskell perd il gagne ailleurs, mais comme c'est sur des choses assez atypiques, ça surprend.

J'étais initialement d'accord avec toi. Finalement, je trouve agréable le fait qu'un fold représente vraiment une opération de plus haut niveau. Puis une boucle, c'est ENORMEMENT de concepts d'un coup. Aux heures sombres de ma vie, j'ai enseigné à l'IUT, la fac et en école d'ingénieur à des groupes de débutant et je peux t'assurer que les boucles ce n'est pas une mince affaire, les étudiants oublient de l'initialiser, d’incrémenter l'iterateur, ne comprennent pas ce que cela fait vraiment.

Par boucle je pensais à des boucles de plus haut niveau permettant d'itérer sur une liste, par exemple, pas une boucle for C. Et je dis pas que le fold c'est mal, je dis juste que dans ces cas là, par rapport à une boucle de haut niveau, c'est à peu près pareil à l'usage, avec des chances similaires de faire des erreurs, juste qu'au lieu d'avoir une syntaxe spécifique on doit se rappeler de la signature de fold (fold_left, bien sûr). Après, personnellement, mon problème avec le fold, c'est que je ne me souviens jamais de l'ordre des arguments entre l'élément initial et la liste (je me souviens juste qu'en Coq c'est l'inverse d'OCaml, et comme j'utilise les deux assez souvent ça n'aide pas :) ).

Ça c'est deux bonnes heures d'explication à des étudiants en stress énorme… Même après plus de 12 ans de python, je me plante encore des fois sur ce genre de bêtise…

J'aime pas spécialement la sémantique de copie de référence non plus (je suis plus habitué au Perl qui passe par valeur et fait des vraies copies à moins de créer explicitement des références).

Bref, là où je veux en venir c'est que je suis d'accord Haskell est un language complexe, comme beaucoup, mais pas forcement plus compliqué à comprendre que d'autre, c'est juste que les problèmes sont autre part.

Je suis bien d'accord. D'ailleurs, du C++ je n'en ai fait qu'une seule fois, et ça m'a semblé le genre de langage que si on n'en fait pas pendant un an, il faut réapprendre (comme Haskell). Ceci dit, comme tu dis, les points difficiles ne sont pas au mêmes endroits.

Oui… Et non… Si l'abstraction est bien faite, tu peux comprendre ce que le code représente sans pour autant comprendre comment cela fonctionne.

Oui, mais des fois c'est pas évident de comprendre une abstraction : de temps en temps si l'abstraction ou la doc ne sont pas suffisamment claires et qu'il te faut regarder le code (ou l'abstraction n'est pas totale et te fait manipuler des Lens explicitement ou autre, ou t'expose une API pour faire du xml avec des Arrows), là tu dois vraiment potasser un peu avant de comprendre de quoi il retourne.

Parce que les projets non documentés en python avec des API qui acceptent des chaînes de caractères à la place d'un Enum et pour lesquelles tu dois chercher dans le code source pour savoir quels sont les valeurs possibles et qui ne pètent pas le jour où la valeur choisie disparaît de la lib.

Peut-être, je n'ai jamais utilisé beaucoup plus que la librairie standard en Python. Peut-être que je suis trop habitué au Perl, où l'habitude de mettre un Synopsis avec des exemples est très encrée dans la culture. Il faut dire que contrairement à Haskell ou OCaml, ou un langage avec au moins des signatures plus formelles, il n'y a pas trop le choix, car pas de documentation automatique des signatures et pas moyen du coup d'imaginer comment agencer quoi que ce soit, du coup ça incite peut-être à mettre des exemples et écrire une documentation moins automatique et plus pragmatique.

Ça reviens à ce que je disais, les langages fonctionnels sont complexes, peu naturels. Dire à quelqu'un qu'il va apprendre la programmation pour écrire des programmes qui n'interagissent avec rien, ça me semble difficilement motivant.

D'un autre côté, Haskell n'est pas le langage fonctionnel le plus simple pour commencer. OCaml est par exemple bien plus accessible (afficher un "Hello world" ne fait pas apparaître des concepts compliqués, contrairement à Haskell avec la monade IO). Haskell ne vise pas à être un langage facile à apprendre, c'est un peu comme C++ (ou Rust), mais dans un genre plus mathématique, ce qui fait que les interactions avec le monde extérieur ne sont pas la première chose mise en avant.

Le fait qu'un langage soit fonctionnel ne le rend pas complexe ou peu naturel en soi. En fait, je trouve par exemple que l'utilisation de fonctions courantes d'ordre supérieur sur les listes est plutôt sain, et je ne m'en prive pas non plus lorsque j'écris dans un langage non particulièrement fonctionnel qui les propose (même si c'est toujours une question de limite : par exemple, autant map et filter me semblent vraiment apporter quelque chose, je n'ai pas toujours l'impression que les fold_left apportent beaucoup par rapport à une boucle). Dans le cas de Haskell, c'est aussi un peu un terrain de prototypage pour plein d'idées sur les système de types, du coup il y a plein d'extensions, c'est complexe et on se cogne à un moment ou à un autre avec des concepts théoriques. D'autres langages comme OCaml sont un peu plus conservateurs (ça veut pas dire que tout code OCaml va être compréhensible pour un néophyte non plus, et ces derniers temps il y a pas mal de nouveautés).

Ceci dit, ce qui en pratique freine le plus sont des choses pas vraiment liées aux langages en soi : le fait que le langage offre des possibilités complexes ne veut pas dire que faire des choses simples va devenir compliqué. Mais en prenant un livre un peu au hasard sur Lisp ou Haskell, il y a de bonnes chances qu'une bonne partie du livre, surtout l'introduction, soit dédiée à expliquer pourquoi le langage est si génial (super macros ou super système de types), ce qui a de bonnes chances d'arrêter quelqu'un qui n'a pas assez de patience ou de temps pour arriver au stade où il peut écrire des choses utiles de base avant de faire des choses géniales. Et puis même une fois les bases du langage maîtrisées, c'est facile de tomber sur un package documenté à l'aide seul de la signature de ses fonctions et une ligne de description pour chacune (ou zéro), et c'est pas souvent que l'on trouve des exemples tout prêts qui permettent d'emblée de se faire une idée de comment on va utiliser le truc : on attend souvent de l'utilisateur qu'il étudie l'API et réfléchisse lui-même à la bonne façon d'agencer les types, et ça fait perdre du temps.

Il y a aussi le fait que ce n'est pas parce qu'on commence à comprendre Haskell et faire des choses utiles facilement que l'on va être capable de lire le code des autres (si ça se trouve, ils utilisent des Lens ou des Arrows ou autre nouveauté, et il faut potasser un peu de théorie avant de pouvoir faire quelque chose :) ). Et ça peut parfois être un inconvénient. On reproche souvent quand quelqu'un fait des choses « trop intelligentes ». Eh bien avec Haskell ça arrive assez souvent (moins avec OCaml, je pense), ce qui a du bon comme du mauvais, mais peut être déroutant et faire perdre du temps en pratique suivant l'utilisation que l'on en fait (c'est pour ça qu'après avoir utilisé un serveur web Haskell faisant usage des Lens un moment, j'étais passé ensuite à du Perl pour reposer les neurones et être sûr qu'au bout d'un an j'ai pas oublié la théorie).

M'enfin, ça prouve bien que c'est juste une mauvaise idée que d'utiliser les regex quand on veut détecter une syntaxe, du coup.

Ça ne prouve rien du tout, ça dépend juste du type de syntaxe que l'on veut matcher, et si l'on veut juste répondre par oui ou non, ou bien expliquer pourquoi ça ne matche pas (auquel cas une expression régulière à elle toute seule ne suffira pas). Pour le cas des expressions régulières pour les ipv4 et traitant les différents cas, ça existe. Par contre l'expression régulière donnée dans le message juste avant n'est pas exacte (elle matche des trucs en plus qui ne sont pas des ips, en partie parce qu'elle traite le dernier groupe comme les premiers, ce qui permet de mettre un caractère à la fin).

Existe-t-il une regex permettant de valider une regex ?

Si on se limite aux expressions rationnelles au sens strict, non : par exemple le simple fait de pouvoir utiliser des parenthèses pour faire des groupes demande de savoir reconnaître si une expression est bien parenthésée, ce qu'une expression rationnelle ne peut pas faire. Pour ça il faut un automate à pile, car les expressions bien parenthésées ont une grammaire algébrique, mais pas rationnelle (en gros, il faut pouvoir compter, ce qu'une expression régulière ne sait pas faire).

En pratique les « regex » (qui n'en sont pas vraiment), permettent de faire ce genre de choses grâce aux diverses extensions. Les expressions régulières Perl permettent théoriquement de faire quoi que ce soit étant donné que l'on peut exécuter conditionnellement du code quelconque si une partie de regex a matché. D'autres (comme PCRE) permettent au moins de faire des appels récursifs à des groupes, ce qui permet par exemple de décrire les expressions bien parenthésées, les palindromes, etc.

Une étoile plutôt (.*).

Il y a aussi le modificateur + qui permet d'interdire le backtracking, et du coup aaa ne matche pas l'expression régulière a++a, car le a++ prend tous les a.

(en Perl en tous cas, parce que ces modificateurs n'existent pas dans toutes les implémentations des regexps, ni le ?, d'ailleurs).

Une qui serait fort utile, éviterait de nombreuses erreurs et arrachages de cheveux aux dév, c'est une classe [:email:] !

Comme les autres te l'ont fait remarqué, des classes de caractères ne servent pas à définir une classe de chaînes, mais une classe de caractères. Par contre, dans les langages qui permettent de combiner des regexps précompilées, on peut réutiliser des regexps exportées par un module (comme Regexp::Common). Après, pour des choses comme une adresse mail, un module avec une fonction qui le valide peut être suffisant si l'on a pas besoin de combiner ça avec une autre regexp. Et comme ça, pas besoin de savoir si c'est implémenté par une regex ou autre ; et d'ailleurs une simple regexp a ses limites pour donner un bon message d'erreur pour expliquer pourquoi l'adresse n'est pas valide (même si en Perl c'est faisable vu qu'on peut exécuter du code lorsque telle ou telle partie de la regexp a déjà matché).

Tu as une idée de la difficulté de prouver un tel lien de cause à effet?

Le truc qui me chiffonne avec ces histoires, c'est qu'on pourrait aussi attendre l'inverse : une preuve que leurs nouveaux produits ne sont pas nocifs. Dans l'absence de vrai « preuve », on pourrait se contenter d'un test pendant plusieurs décennies par des volontaires conscients de ce qu'ils font, avant de donner cela au grand public sans prévenir (histoire d'offrir des garanties similaires à celle que nous offre l'expérience historique des produits plus traditionnels). Bien sûr, pour des raisons d'argent, il n'y a aucune chance que ça se fasse comme ça, et pourtant, ce serait bien plus raisonnable.

Je suis d'accord que c'est mieux quand tout le monde se comporte de façon responsable, mais en vouloir autant aux mauvais piétons qu'aux mauvais conducteurs me semble simplificateur : la situation n'est pas du tout symétrique à la base. Tout d'abord, il y a un fait tout simple : avant les voitures, la route était aux piétons. Maintenant, ils n'ont plus que le trottoir, et des passages pour piétons partagés avec les voitures, et en général le feu est vert beaucoup plus de temps pour les voitures que pour les piétons (quand il est pas vert pour les deux à la fois…). Le deuxième point important, c'est que celui qui risque sa peau, c'est le piéton, pas le conducteur, et risquer sa peau c'est sans doute pas bien, mais risquer celle des autres me semble plus grave.

Je ne sais pas s'il existe un préprocesseur qui fait ça avec markdown (ça a l'air raisonnable de penser qu'avec latex il doit y avoir quelque chose comme ça, mais je ne connais pas non plus). Par contre, ça a l'air relativement facile de faire un truc à sa sauce, d'au moins deux façons.

La moins ambitieuse, mais probablement plus rapide : écrire un script Perl (ou Python, shell, etc.), qui cherche heuristiquement les bouts de code à coup de regexp (parser markdown rigoureusement c'est vraiment difficile, cf méthode 2 plus bas), les extrait, les compile et tout ça, puis ajoute des liens vers les images produites. Il existe aussi la possibilité de s'en sortir en n'écrivant pas directement du markdown, mais en utilisant un préprocesseur comme m4 (ça a l'air bête, mais des fois c'est pratique m4), qui peut faire appel vers des commandes quelconques (donc un petit script qui renvoie ce qu'on veut, par exemple).

Plus ambitieusement, tu peux utiliser pandoc (c'est utilisable comme librairie, et on peut manipuler l'AST généré par le source markdown) et repérer ainsi les bouts de code, puis faire un truc similaire à la méthode 1, mais par contre ça demande de réfléchir un peu plus, je pense.

Les spec principales sont definies, le langage en lui même est définit, il y a une implementation qui respect une très grande partie de ces spec.

D'un point de vue correction et fonctionnalités, ça me semble plutôt bon (les trucs qui restent à faire n'existent pas dans la plupart des langages de script), et à chaque fois que je teste un peu rakudo, je suis très agréablement surpris par la qualité des messages d'erreurs, en particulier pour les erreurs de syntaxe (contrairement à Perl 5, si on oublie un point virgule, l'erreur va pointer direct au bon endroit, par exemple), qui à la fois sont compréhensibles et abordables par un débutant, tout en donnant aussi des infos sur les types quand c'est opportun, qui peuvent être utiles pour quelqu'un de plus aguerri.

Par contre, en dehors d'un écosystème de modules un peu chaotique pour le moment (mais j'ai confiance que ce point va s'arranger), ce qui me bloque un peu pour l'utiliser plus couramment, c'est les performances sur tout ce qui a trait aux manipulations de chaînes de caractères, ce qui ironiquement le rend peu utilisable pour certains des cas historiques d'utilisation les plus typiques de Perl 5, dès que c'est un peu intensif. Par exemple, un simple comptage de mots dans un gros fichier va être plusieurs dizaines de fois plus lent que Perl 5 actuellement. Mais j'espère que ça va s'améliorer un de ces jours sur ce point, parce que le support pour grammaires de Perl 6 (qui servent à parser Perl 6 lui-même avec d'excellents messages d'erreur) donne vraiment envie d'utiliser ce langage pour manipuler du texte.

Ça veut dire que ton $param->{$k} n'est pas défini (ligne 152), donc que parse_paramfile ne fait pas ce que tu crois.

Si je comprends bien, on reproche que certaines données sont issues d'études partielles (par exemple étudier que quelques dizaines de glaciers, mais pas tous [faute de moyens peut-être ?]), d'utiliser parfois des graphiques incomplets (au sens, sur un intervalle de temps pas assez long, choisi exprès pour tromper selon l'article), et d'essayer de rechercher des corrélations absurdes (dont il ne dit jamais qu'elles représentent des vérités).

Eh bien, étudier 58 glaciers c'est peut-être pas idéal, j'en conviens, mais c'est quand même mieux que nos médias, qui souvent se contentent de nous en montrer 1 (dans les Pyrénées par exemple, choix ridicule vu que ça s'est surtout formé à la dernière petite période froide d'il y a trois cent ans), et de conclure à la catastrophe. Il ne dit d'ailleurs à aucun moment « Les glaciers ne fondent pas, donc pas de réchauffement » (comme reproche ton article).

Faire commencer à l'année 98 pour montrer le plateau actuel de températures me semble logique, vu que 98 est le début du plateau, et qu'avant la température augmentait évidemment (ce qui est visible sur bien d'autres graphiques du site déjà, c'est pas comme s'il ne contenait qu'une demi douzaine de graphiques…). Je n'ai vu nulle part qu'il essaye d'expliquer que le climat se refroidit… juste qu'il ne se réchauffe pas en accord avec les modèles actuels.

Je vois que l'article n'ose quand même pas lui reprocher de parler de l'accroissement (non mesurable) des évènements climatiques extrêmes (cyclones, etc.) ces dernières années.

Bref, je trouve qu'au final, ils ne lui reprochent pas grand chose, et se contentent de choisir quelques graphiques parmi des centaines pour dire qu'il ne dit que ce qui va dans son sens (en oubliant le reste). Ceci dit je trouve quand même très bien qu'ils essayent de remettre en cause tout ce qu'il écrit (souvent c'est juste des traductions d'articles faits par d'autres personnes, d'ailleurs, donc c'est loin d'être une seule personne). Puissent-ils seulement en faire autant vis-à-vis de leurs propres convictions.

Faire des sciences, c'est émettre des hypothèses, chercher des corrélations, modéliser puis attendre que les observations valident ou non avant de conclure, et savoir reconnaître quand les modèles sont à retravailler car insuffisants (comme c'est le cas actuellement). Le site en question est peut-être clairement biaisé contre les médias officiels, mais il ne prétend au moins pas connaître la vérité sur le climat, et se contente de faire des observations, pas de prédire le climat du siècle à venir à l'aide d'une moyenne sur des modèles qui n'est clairement, d'après les données officielles, pas suivie par les observations depuis quinze ans… Ça veut pas dire que le CO2 n'est pas un paramètre intéressant, juste qu'il a été surestimé.