Personnellement j'aime les endroits où il est agréable de discuter avec les gens, qui essaient de s'aider les uns les autres et d'être ouverts et accueillants. Je préfère construire sur du positif plutôt que sur du négatif ou de la colère. Je trouve que des messages agressifs, comme il y en a partout et tout le temps sur LinuxFR, sont beaucoup plus gênant qu'une façon d'écrire qui a été pensée pour être plus ouverte et auxquels les gens font des réactions allergiques.
Tu verras, c'est comme changer de disposition clavier, au début ça demande un petit effort et après il n'y a aucun soucis. Ce n'est pas comme l'écriture SMS qui change constamment de forme et d'abréviations, mon expérience des textes féminisés c'est qu'au bout de quelque fois ça ne pose plus aucun soucis.
Je pense que la rédaction de la dépêche ne permet pas de comprendre vraiment cette annonce et ce qu'elle a d'intéressant—en bonne ou en moins bonne nouvelle.
À première lecture pour une personne qui n'est pas familière avec les technologies d'accessibilité, on lit ceci: "La société Hypra résout l'OCR pour GNU/Linux en offrant un pont (en logiciel libre) à une version spéciale d'un bon logiciel propriétaire, pour la modique somme de 150€". Ça n'est pas exactement le rêve du libriste (qui rêve d'une résolution de l'OCR par une solution entièrement libre), et donc je trouve normal que la nouvelle soit accueillie assez tièdement.
Quand on regarde de plus près on voit qu'il y a une vraie histoire qui n'est pas racontée. Hypra est bien une boîte "sociale et solidaire" qui se présente comme travaillant sur l'accessibilité du libre, en faisant du libre, dans l'intérêt de tous. Dans une précédente dépêche Texou avait parlé du "PC à accès universel", avec en particulier un système de synthèse vocal venant du milieu universitaire, mais pas vraiment libre, et on sentait bien dans son commentaire une déception et un choix du compromis—le choix d'aller chercher une solution qui rend GNU/Linux utilisable aujourd'hui peut valoir le compromis d'avoir du code partiellement propriétaire pour cela.
Voilà les questions que je pose alors et auxquelles la dépêche aurait pu répondre:
Pourquoi ce choix d'une solution OCR propriétaire ? J'imagine que les solutions libres ont été évaluées et ne répondent pas au besoin. Pouvez-vous en dire plus sur les candidats qui ont été considérés, la façon de les évaluer, et les manquements observés ? Quelle est la performance sur ces critères de la solution qui a été finalement choisie ?
Quelle est la stratégie à long terme sur l'OCR, y a-t-il un espoir de solution libre à terme ?
Expliquer le processus de décision, et pas finalement annoncer le résultat final, permettrait aux gens de mieux comprendre les problématiques et les enjeux.
Merci, c'est exactement à quoi je pensais. Maintenant c'est à nous (abonnés à d'autres journaux) de contacter les journaux pour leur demander de s'ajouter à cet effort.
(Si je devais chipoter je dirais que garantir de reverser 90% des abonnements aux journaux partenaires c'est un peu décevant, ça fait 10% de frais pour quelque chose qui devrait être un simple frontend de paiement bancaire. J'imagine qu'il faut amortir les frais de développement du site et les prises de contacts avec partenaires etc., mais sur le long terme c'est trop gros comme marge de fonctionnement. Les journaux du bouquet devraient financer collectivement l'entretien de ce portail.)
Une solution de contournement est de varier tes paiements chaque année—donc tu échelonnes en temps. Mais je suis bien d'accord sur le fait que c'est un problème.
Je pense qu'une des raisons qui fait que les journaux rechignent à avoir une offre "soutien partiel" moins chère est qu'ils pensent que ça encouragerait tout le monde à prendre ça… Je vois trois solutions:
un journal à prix libre, qui permet aux gens de choisir leur abonnement selon leur investissement et leurs moyens (mais peu de contrôle des journaux sur les flux de revenus)
des abonnements échelonnés avec niveau de privilège différent (on pourrait interdire aux abonnés les moins chers de commenter; toute mesure qui réduit les commentaires délirants peut être bonne à prendre), comme c'est fait sur LWN.net qui fait payer $7/mois de base, avec un niveau "starving hacker" $3.5/mois et un niveau premium à $14/mois
une forme de licence globale locale (et privatisée) qui permet de payer un "paquet presse" à prix fixe un fournisseur qui répartit l'argent des abonnements
La solution 3 est en fait peut-être assez facile à mettre en place à l'ère des micropaiements etc. L'idée est que le paquet coûte, par exemple, 30€/mois, et ensuite tu répartis le flux comme tu veux entre tous les journaux participants (ils peuvent fixer des minimums si ça leur chante). Comme ça les journaux savent que si tu ne leur donnes que 3€ et pas les 15€ qu'ils demandent, ce n'est pas parce que tu paies moins pour la presse mais parce que tu étales, et c'est plus facile à accepter pour eux.
À mon avis tu te méprends profondément sur la difficulté de repérer ce système. Quelques régies ont de grosses parts, et elles vont facilement voir que ton IP génère beaucoup plus de clics qu'un être humain normal—tu parles de milliers de clics par jour, personne ne fait ça. Et c'est facile pour elles d'échanger l'info sur les "faux cliqueurs" si c'est dans leur intérêt de groupe.
La seule façon d'être complètement non-repérable c'est de se comporter comme un humain normal, c'est à dire… ne pas cliquer beaucoup. Du coup tu rapportes aux sites que tu visites autant que si tu cliquais de bonne foi, c'est-à-dire… pas beaucoup. Et cette façon de financer le web reste non-viable, pousse à l'exploitation et aux contenus mouche-à-clic, etc.
Le calcul est très simple: si chaque zozo qui utilise un cliqueur randomisé se comportant comme un humain va sur ces sites, ça fait comme un zozo normal, donc ça change pas grand chose. S'il faut 10 000 visiteurs non-bloquants typiques par jour à un site pour vivre, et que tu les remplaces par ton système… il faut toujours 10 000 personnes équipées de ton système. Ça reste pas viable, et ça continue à encourager les sites à mettre du contenu attirant plutôt que de qualité.
Tu parles de financer le web "proprement", mais ça reste de l'argent sale. L'argent propre c'est celui que tu as gagné avec ton travail.
Les publicitaires et les agences de pub (dont Google) ne sont crédibles que s'ils peuvent prouver un taux de retour sur les clics qu'ils comptabilisent. Si ta solution devient plus connue, tout ce que tu vas gagner c'est qu'ils vont développer des contre-mesures pour détecter leur usage (c'est certainement déjà fait: les régies publicitaires se sont sans doute rendu compte que tu t'es mis à clicker sur des milliers de pubs par jour en passant d'un taux zéro, s'ils ne sont pas idiots ils ne comptent pas tes clics), et pénaliser les sites que tu fréquentes pour ces "faux clics". Et l'effort dépensé pour repérer les tricheurs va juste diminuer la valeur des clics et donc motiver les sites à inclure encore plus de pub…
D'ailleurs le but de AdNauseam n'est pas de générer du revenu pour les sites qui montrent la pub, mais de casser la fiabilité de ces pubs et donc de nuire aux annonceurs. Eux-mêmes n'essaient pas de dire que leur utilisation apporte de l'argent aux sites que tu visites, c'est toi qui te dupe par espoir, je pense. (Mais même pour cet usage j'ai des doutes sur l'efficacité à long terme.)
Il y a une solution simple, honnête, claire et viable: donner de l'argent aux sites que tu veux soutenir. Je soutiens la presse tout en évitant la publicité en m'abonnant aux journaux qui font un travail de qualité (et en utilisant un bloqueur de pubs). Tout le monde peu le faire, chacun à la hauteur de ses moyens—personnellement je pense que 10% de mes revenus après coûts fixes en dons est une bonne cible, mais ça n'inclus pas que la presse.
En plus avec des dons les journalistes peuvent garder la tête haute sur la façon dont ils gagnent leur vie. Ça fait quelques euros par mois gagné par un soutien de plein gré d'une personne qui apprécie leur travail, au lieu de les escroquer sur le dos d'une personne dont un publicitaire aura exploité les faiblesses pour faire naître l'envie de consommer.
La liste est déjà construire à partir de logiciels utilisés par les institutions européennes. Cf. la page wiki qui contient des informations sur la liste.
C'est bien de donner des conseils sur comment refaire ce genre d'initiatives en mieux, mais maintenant qu'il y a une proposition concrète de faite, pourquoi ne pas se renseigner sur les logiciels proposés, en discuter, et faire ton choix ?
Il manque un peu d'information sur comment les logiciels ont été sélectionnés. Mais comme ma page wiki le mentionne, les logiciels ont été choisis à partir d'une liste de logiciels utilisés ou recommandé au sein de la commission européenne:
The list has been prepared based on inventory of open source software used in the European Commission in 2014 as well as the catalogue of products available for use within the European Commission as of June 2016.
(Je me permets de faire un peu de pub sur cette page wiki: si tu veux l'éditer pour ajouter des informations sur les différents logiciels, par exemple les briques logicielles qu'ils utilisent et leur niveau de sensibilité, ça serait très utile !)
Du coup les recommendations du style "plutôt que X vous devriez avoir Y" ne sont pas forcément utiles dans le cadre de ce sondage précis : si les institutions de l'EU utilisent Drupal plutôt que Y, elles ont choisi de proposer Drupal à l'audit. Ça me semble être un choix raisonnable.
Pareil pour FileZilla / WinSCP: si les systèmes des institutions de l'EU utilisent les deux, ça fait sens d'auditer les deux. (Ça fait sens aussi de consolider un système en limitant les redondances entre logiciels utilisés, mais en même temps c'est bien aussi de laisser du choix aux techniciens qui font leur boulot.)
Bien sûr on peut discuter de s'il vaut mieux auditer des logiciels utilisés par l'EU ou utilisés par tout le monde et pas l'EU en particulier, des logiciels établis avec une grosse base d'utilisateurs ou plutôt des logiciels prometteurs qui seront plus utilisés demain, etc…. Mais là il y a une liste bien définie avec des justifications raisonnables donc je trouve que c'est utile de faire un choix dans ce qui est proposé—même s'il y a une option "Other choice" que tu peux utiliser si tu veux.
D'une part, le code est incorrect si je commence à construire des arbres de paires; en OCaml 'a peut être instancié par (int * int) par exemple. D'autre part l'encodage ne passe pas à l'échelle si j'ai plusieurs constructeurs, par exemple un constructeur pour les noeuds noirs et un pour les rouges dans un arbre rouge-noir; ou alors deux types de feuilles différentes, etc.
Je ne dis pas que c'est dur (ci-dessus je proposais des encodages qui sont relativement agréables à utiliser si le langage a du pattern-matching comme racket/match par exemple), mais je pense que trouver une représentation générique n'est pas aussi simple et risque de pêcher en performances par rapport à un runtime (et surtout un choix de représentation des valeurs) qui gère ça en dur.
Merci ! J'avais de mon côté posté un commentaire sur le billet de blog, mais "Your comment will be public soon". (Et je n'utilise pas Twitter moi-même donc c'est un canal de plus que je n'aurais pas su exploiter.)
J'ai créé une page wiki qui décrit succintement chaque projet, et qui encourage les gens à ajouter des informations sur les projets pour aider chacun à faire son choix de façon informée.
(Méta-commentaire: je regrette de passer par le service propriétaire github pour cela. J'ai essayé d'utiliser etherpad/framapad à la place mais le support Markdown est inexistant ou très mauvais, ce qui rend cette solution inutilisable en pratique, en plus du fait que Framapad montre une popup en français à tous les visiteurs—issue #9.)
P.S.: Stephen Dolan a aussi travaillé sur l'ajout de l'instrumentation pour afl-fuzz dans le compilateur OCaml, donc il est possible qu'il propose un fuzzer passant par malfunction et piloté par AFL. (AFL fait des opérations de fuzzing byte-par-byte, donc Stephen avait proposé d'écrire une fonction qui prend une chaîne d'octets et la transforme en un programme OCaml—ou Malfunction en l'occurence.)
L'implémentation OCaml n'est pas du tout vérifiée (par contre il y a des versions modifiées et simplifiées qui ont été "certifiées" au sens des normes machin il me semble, en tant que logiciel utilisé par Scade et autres produits Esterel-tech) est est pleine de bugs (comme tous les logiciels de cette ampleur), nous en corrigeons un petit peu chaque jour ou presque.
Effectivement le test aléatoire du compilo OCaml avec Malfunction serait une façon intéressante de découvrir des bugs et j'espère que quelqu'un (Stephen, moi ou quelqu'un d'autre) aura le temps de faire joujou avec ça, c'est assez marrant en plus.
EDIT: je me suis trompé de destinataire, j'ai mal cliqué pour la réponse :-.
Par ailleurs, tu es aussi très défensif, voire agressif et désagréable, dans tes arguments. C'est une discussion technique où les gens posent des questions et y répondent—il n'y a pas de désaccord de fond, au pire des incompréhensions à clarifier—c'est plus agréable pour tout le monde si tu restes calme et respectueux dans ta façon d'écrire, et si tout le monde suppose que chacun est de bonne foi et fiable dans ses affirmations.
(Par exemple: pas besoin de "je n'en ai rien à faire", pas besoin de petite pique, et pas besoin d'expliquer que les arguments des gens n'ont "aucune valeur".)
Core est un langage intermédiaire typé, donc pour pouvoir produire une représentation Core il faut construire une dérivation de typage qui montre que ton programme intermédiaire vérifie les règles de typage de Core. C'est très difficile voire impossible en pratique (sans sacrifier les performances), ce qui rend la représentation Malfunction, non typée, plus agréable comme cible.
(C'est un point de détail intéressant qui m'a été rappelé par Sam Lindley, un des implémenteurs de Links et donc une des cibles pour Malfunction. À l'inverse, avoir une représentation intermédiaire typée a aussi des avantages quand on développe un compilateur (par exemple pour débugger, et pour mieux comprendre le typage du langage de surface ou la sémantique des optimisations effectuées), donc ce n'est pas un mauvais choix de la part de GHC.)
(Après avoir regardé un peu plus en détail, d'une part il vaudrait mieux utiliser des petits entiers que des symboles dans ma proposition ci-dessus, donc '(0 leaf-value) et '(1 left right), et d'autre part Chicken Scheme a une notion de tagged pointer qui serait sans doute un meilleur choix ici, où l'information de tag pour les constructeurs non-constants serait stockée avec le pointeur plutôt qu'avec la valeur, même si ça reste une représentation nettement moins compacte—Haskell stocke le constructeur dans le pointeur parfois, mais de façon plus compacte.)
Lambda a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation intermédiaire du compilateur OCaml, qui en a)
Je veux bien te croire sur parole (étant donné qu'il n'existe pas de spécification du langage), mais cet argument est quand même bien foireux, je te le refais
ASM x86 a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation du compilateur OCaml, qui en a)
Hophophop, voilà ! Bon, j'ai retiré « intermédiaire » et changé le nom … Soit ce que tu dis est qu'il est possible de le faire simplement, ce qui est le cas dans à peu près n'importe quel langage (même x86) soit tu dis qu'il existe une syntaxe spéciale, et alors l'argument n'a aucune valeur.
Certes, x86 permet d'exprimer efficacement les types sommes. Mais la traduction n'est pas simple et demande beaucoup d'effort; ce n'est pas une représentation intermédiaire adaptée pour un compilateur. Au contraire, une représentation intermédiaire pour OCaml essaie de faciliter la représentation efficace de ce qui existe dans le langage, et de manière agréable à produire (si on suppose que le compilateur est bien conçu), donc c'est une indication forte que tous les aspects importants du langage OCaml seront bien couverts par cette représentation.
Il n'est pas du tout clair que n'importe quel langage permet de représenter les types sommes de façon efficace. En Scheme par exemple, comment coderais-tu quelque chose comme
Mes idées immédiates pour faire cela sont soit de construire des paires (tag, paramètres), c'est-à-dire une s-exp donc la tête est un symbole 'leaf ou 'node et le nombre d'éléments suivants est en fonction, ce qui donne une représentation moins efficace (OCaml met le nom de constructeur dans le mot de tête aussi utilisé par le GC, alors que là tu paies avec un mot de plus par valeur; et le test d'égalité de symboles est plus lent), ou alors essaie d'utiliser un struct et tester l'identité du type, ce qui donne encore une représentation moins efficace (le nom du type est dans un espace de nom plus grand que les constructeurs fixés ici, et donc va être plus difficile à encoder comme une série de petits entiers consécutifs).
De plus, j'ai l'impression que du confonds la syntaxe de malfunction et la syntaxe de Lambda. Qui sont apparemment deux langages différents, par exemple quand tu parles de […] C'est à propos de Malfunction, et non pas de Lambda. Or, la question porte justement sur le fait de remplacer Lambda par un Scheme.
On a dû mal se comprendre. Malfunction c'est en gros une version simplifiée (et spécifiée) de Lambda, un langage à une distance minimale qui permet d'être clair et facilement interprétable et quand même se traduire de façon très transparente vers Lambda. Quand tu proposes d'utiliser un Scheme "à la place", je comprends "à la place de Malfunction", et pas "à la place de Lambda", puisque (1) Lambda lui-même n'est pas proposé comme cible directe pour les autres langages et (2) traduire Malfunction tel qu'il est vers Lisp/Scheme serait difficile voire impossible (sans perte d'efficacité) vu l'impedance mismatch entre les représentations. Si tu veux un compilo qui vise une implem. Lisp/Scheme, il faut produire du Lisp/Scheme (ou une de leurs représentations internes), pas du Lambda-de-OCaml-simplifié.
Ou alors tu demandes peut-être si le compilateur OCaml pourrait compiler vers (la représentation intermédiaire d'un compilateur) Lisp ou Scheme, mais là c'est une question encore différente qui n'a pas vraiment de sens—en fait les premiers Caml étaient implémentés de cette façon là, et je crois qu'il y a eu un frontend Bigloo ou Stalin pour Caml, mais aujourd'hui les langages, sémantiques et attentes de domaine optimisé sont trop différentes je pense.
[Sur le fait que Lambda gère les types sommes] Je veux bien te croire sur parole (étant donné qu'il n'existe pas de spécification du langage), […]
Regarde par exemple la partie lambda_switch de l'AST Lambda, qui définit une construction de switch avec une famille de cas pour gérer les constructeurs constants (représentés comme des entiers) et les constructeurs à paramètres (boxés sur le tas, donc avec un pointeur en tête et un tag de constructeur quand on suit le pointeur).
piper un AST texte sous-entends que c'est une phase « alpha », prototype, enfin, quelque chose de pas propre. Et quand on voudra le faire proprement, […] on repose sur un truc instable, génial.
L'auteur de compilateur continue à viser la représentation Malfunction, qui est stable. C'est s'il veut appeler le compilateur OCaml directement depuis son frontend qu'il doit utiliser l'API du compilo qui n'est pas stable. Mais bon LLVM n'offre pas de stabilité entre les versions non plus et pourtant plein de compilateurs l'utilisent—souvent à raison.
Par ailleurs c'est classique dans un compilateur de produire une représentation intermédiaire dans un fichier et d'appeler derrière un outil externe—au lieu de tout avoir dans un même processus. Chicken Scheme lui-même produit du C et appelle un compilo C derrière. Beaucoup de compilateurs natifs produisent une représentation textuelle de l'assembleur généré et appellent l'assembleur système derrière. Pareil pour le linker, tu ne recodes pas, tu appelles un programme externe. Ce n'est pas fondamentalement "alpha" et ça marche bien.
Sur les macros: que tu définisses un langage propre (Malfunction) ou un ensemble de macros par dessus un langage plus simple, ça ne change pas grand chose du point de vue de l'utilisateur, c'est-à-dire l'implémenteur d'Idris, Eff ou Links. Dans tout les cas il faut produire cette représentation intermédiaire.
On ne peut pas le faire en utilisant un programme C intermédiaire ?
Ben ça dépend de comment les deux langages sont compilés et si les représentations sont compatibles. Par exemple si les types algébriques sont représentés différemment, il faut traduire d'une représentation vers l'autre, donc tu as coût important quand tu transfères des données (alors qu'avec une représentation partagée, rien à faire). Si tu as deux GCs avec des attentes incompatibles, encore une fois c'est la prise de tête et une coopération moins efficace.
Par exemple Coq utilise pas mal le fait qu'il compile vers OCaml pour écrire des programmes mixtes. (Dans Compcert par exemple, le gros du compilo est du Coq, mais il y a des parties en OCaml et c'est bien pratique (et l'efficacité est importante).
Je n'arrive pas à trouver des informations fiables sur les performances de Chicken Scheme par rapport à OCaml. C'est un des Scheme efficaces, et il y a une communauté derrière (cf. la relativement large couverture de bibliothèque (eggs) disponibles), mais très peu d'information trouvables en ligne sur les performance en pratique.
Par ailleurs pour servir de représentation intermédiaire il faut que les utilisateurs puissent écrire du code bas niveau, où des informations de typage partielles sont connues et exploitées. Il me semblait que Chicken se restreignait à R5RS. Quel est le support dans le langage pour dire qu'une donnée est un entier de 32 bits, ou ne peut pas être un pointeur, pour manipuler des flottants non boxés, etc. ? Ou alors tu as en tête l'usage d'une représentation intermédiaire utilisée par Chicken (comme le bytecode Guile par exemple), mais alors laquelle ?
La syntaxe est spécifiée pour le scheme : si le code n'utilise pas d'extensions c'est même très basique
La syntaxe n'a pas grand chose à voir avec le but de Malfunction. C'est un langage intermédiaire, pas un langage de surface pour les utilisateurs. Du moment que la syntaxe est non-ambiguë, clairement définie et facile à produire et à lire, ça pourrait être du XML ça n'aurait aucune importance.
Le compilateur est fait pour être intégré dans une application (dans le cas de chicken scheme), ce qui n'est pas le cas d'ocaml
Beuh, encore une fois le but c'est d'obtenir facilement un compilateur décent pour un langage expérimental à moindre coût, si pour cela il faut piper dans un fichier texte au milieu je ne vois pas vraiment le soucis. Par ailleurs le compilateur OCaml expose une API pour manipuler directement la compilation (mais encore une fois elle n'est pas stable) si c'est vraiment important.
Malfunction pourrait être une collections de macros qui génèrent le code adéquat pour les fonctions « haut niveau » comme le pattern matching
Je ne vois pas vraiment l'intérêt.
À priori pas de types sommes (mais dans malfunction non plus si, puisque Lambda n'en a pas … ?)
Lambda a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation intermédiaire du compilateur OCaml, qui en a). Par contre il n'y a pas de pattern-matching complexe au niveau de Lambda (seulement des switches sur les tags ou des entiers), puisque le pattern-matching est compilé en amont, après le typage.
Il me semble que Lambda ne possède pas de système de type : l'argument de l'interaction typée avec les autres programmes tombe
Imagine que j'ai un programme OCaml qui veut appeler une fonction Links (ou Eff ou Idris) ou l'inverse. Je peux vérifier que les types sont à peu près cohérents (les deux langages n'ont pas les mêmes types mais il y a sous-ensemble commun qui garantissent à peu près les mêmes comportements), compiler les deux vers Lambda et les lier ensemble. Pas besoin que Lambda lui-même soit typé, il faut seulement que les stratégies de compilation choisies pour ces types communs soient compatibles (ou qu'on sache insèrer un peu de code glue entre les deux).
Par exemple ça peut permettre d'échanger facilement des données de grande taille (par exemple un gros terme de preuve généré par Idris) sans copie/traduction, parce qu'en partageant le backend et le runtime tu as la même représentation des deux côtés.
La représentation interne Lambda (qui est bien celle que vise Malfunction) n'est effectivement pas spécifiée et peut changer d'une version du compilateur à l'autre. Par contre le langage d'entrée de Malfunction est spécifiée, et plus simple que Lambda; Malfunction va produire du code pour une version spécifique du compilateur OCaml, mais peut s'adapter pour suivre les changements de représentation du Lambda.
La question est donc : pourquoi utiliser le compilateur OCaml ? Les performances sont-elles vraiment meilleures qu'un lisp compilé ?
Je pense que les backends/runtimes des bonnes implémentations Lisp (SBCL par exemple) et de OCaml sont relativement comparables en terme de qualité aujourd'hui. La question se pose aussi dans l'autre sens: pourquoi choisir Lisp plutôt que OCaml ?
La gestion des types algébriques, avec une représentation des valeurs efficaces, peut être un argument en faveur de OCaml—à ma connaissance les Lisp n'ont pas de représentation natives pour ce genre de valeurs, qui sont très utilisées par les adopteurs potentiels (Idris, Agda, Eff, Links, etc.).
(À l'inverse certains Scheme ont des continuations efficaces, ce qui peut être important pour certains langages, mais pas les Lisps à ma connaissance.)
Un autre argument est l'interopérabilité : partager une représentation interne et le runtime ça permet aussi une communication inter-langage à moindre coûts (comme c'est facile entre les langages qui tournent sur la JVM ou le CLR), et ces langages peuvent être plus intéressés par le fait d'interagir avec un langage typé, qui permet de donner des garanties partielles de sûreté au niveau du lien entre les fragments de programmes écrits dans différents langages.
Je pense que la suggestion de c3 fait sens, dans le sens où les Scheme sont sans doute plus facilces à produire programmatiquement—et ne demandent pas au programme en entrée d'être bien typé. Mais tu peux aussi bien sûr invoquer le compilateur OCaml depuis un programme, et même utiliser compiler-libs, une bibliothèque qui permet d'appeler les fonctions internes du compilateur depuis un programme OCaml—mais il n'y a pas de garantie de stabilité de l'interface entre les versions du langage.
Cela étant, commencer cette approche dès le primaire et le secondaire ne pouvait qu'être voué à l'échec. Il ne faut pas avoir soi même d'enfant, ou avoir côtoyé des enfants pour imaginer qu'une telle méthode puisse fonctionner.
Je ne pense pas qu'on puisse dire cela puisqu'il y a des enfants qui ont, au contraire, beaucoup apprécié les maths modernes, d'une façon qui transcende la reproduction sociale—certains de ces enfants sont membres de la communauté scientifique aujourd'hui.
C'est quand même un sport ou les mecs jouent comme des gonzesses et les gonzesses comme des mecs
Je ne vois pas trop de raison de regretter les points Godwin (même pour rigoler), mais les remplacer par des commentaires sexistes c'est quand même assez triste.
[^] # Re: Bon
Posté par gasche . En réponse à la dépêche Unixcorn, trois mois plus tard : évolutions, remises en questions et stabilisation. Évalué à 3.
Personnellement j'aime les endroits où il est agréable de discuter avec les gens, qui essaient de s'aider les uns les autres et d'être ouverts et accueillants. Je préfère construire sur du positif plutôt que sur du négatif ou de la colère. Je trouve que des messages agressifs, comme il y en a partout et tout le temps sur LinuxFR, sont beaucoup plus gênant qu'une façon d'écrire qui a été pensée pour être plus ouverte et auxquels les gens font des réactions allergiques.
[^] # Re: Bon
Posté par gasche . En réponse à la dépêche Unixcorn, trois mois plus tard : évolutions, remises en questions et stabilisation. Évalué à -10.
Tu verras, c'est comme changer de disposition clavier, au début ça demande un petit effort et après il n'y a aucun soucis. Ce n'est pas comme l'écriture SMS qui change constamment de forme et d'abréviations, mon expérience des textes féminisés c'est qu'au bout de quelque fois ça ne pose plus aucun soucis.
# Il y a une belle histoire là-dessous, mais elle est mal racontée
Posté par gasche . En réponse à la dépêche GNU/Linux a son OCR de qualité. Évalué à 10.
Je pense que la rédaction de la dépêche ne permet pas de comprendre vraiment cette annonce et ce qu'elle a d'intéressant—en bonne ou en moins bonne nouvelle.
À première lecture pour une personne qui n'est pas familière avec les technologies d'accessibilité, on lit ceci: "La société Hypra résout l'OCR pour GNU/Linux en offrant un pont (en logiciel libre) à une version spéciale d'un bon logiciel propriétaire, pour la modique somme de 150€". Ça n'est pas exactement le rêve du libriste (qui rêve d'une résolution de l'OCR par une solution entièrement libre), et donc je trouve normal que la nouvelle soit accueillie assez tièdement.
Quand on regarde de plus près on voit qu'il y a une vraie histoire qui n'est pas racontée. Hypra est bien une boîte "sociale et solidaire" qui se présente comme travaillant sur l'accessibilité du libre, en faisant du libre, dans l'intérêt de tous. Dans une précédente dépêche Texou avait parlé du "PC à accès universel", avec en particulier un système de synthèse vocal venant du milieu universitaire, mais pas vraiment libre, et on sentait bien dans son commentaire une déception et un choix du compromis—le choix d'aller chercher une solution qui rend GNU/Linux utilisable aujourd'hui peut valoir le compromis d'avoir du code partiellement propriétaire pour cela.
Voilà les questions que je pose alors et auxquelles la dépêche aurait pu répondre:
Pourquoi ce choix d'une solution OCR propriétaire ? J'imagine que les solutions libres ont été évaluées et ne répondent pas au besoin. Pouvez-vous en dire plus sur les candidats qui ont été considérés, la façon de les évaluer, et les manquements observés ? Quelle est la performance sur ces critères de la solution qui a été finalement choisie ?
Quelle est la stratégie à long terme sur l'OCR, y a-t-il un espoir de solution libre à terme ?
Expliquer le processus de décision, et pas finalement annoncer le résultat final, permettrait aux gens de mieux comprendre les problématiques et les enjeux.
[^] # Re: J'attends les contentieux
Posté par gasche . En réponse au journal Nouvelles Open-Source de Bulgarie. Évalué à 10.
La loi concerne les
Je suppose que le logiciel classé secret défense n'est pas un système d'information ou un e-service.
[^] # Re: Problème du prix
Posté par gasche . En réponse au journal Financer le web proprement grâce à la pub et une paire de modules Firefox. Évalué à 3.
Merci, c'est exactement à quoi je pensais. Maintenant c'est à nous (abonnés à d'autres journaux) de contacter les journaux pour leur demander de s'ajouter à cet effort.
(Si je devais chipoter je dirais que garantir de reverser 90% des abonnements aux journaux partenaires c'est un peu décevant, ça fait 10% de frais pour quelque chose qui devrait être un simple frontend de paiement bancaire. J'imagine qu'il faut amortir les frais de développement du site et les prises de contacts avec partenaires etc., mais sur le long terme c'est trop gros comme marge de fonctionnement. Les journaux du bouquet devraient financer collectivement l'entretien de ce portail.)
[^] # Re: Problème du prix
Posté par gasche . En réponse au journal Financer le web proprement grâce à la pub et une paire de modules Firefox. Évalué à 5.
Une solution de contournement est de varier tes paiements chaque année—donc tu échelonnes en temps. Mais je suis bien d'accord sur le fait que c'est un problème.
Je pense qu'une des raisons qui fait que les journaux rechignent à avoir une offre "soutien partiel" moins chère est qu'ils pensent que ça encouragerait tout le monde à prendre ça… Je vois trois solutions:
La solution 3 est en fait peut-être assez facile à mettre en place à l'ère des micropaiements etc. L'idée est que le paquet coûte, par exemple, 30€/mois, et ensuite tu répartis le flux comme tu veux entre tous les journaux participants (ils peuvent fixer des minimums si ça leur chante). Comme ça les journaux savent que si tu ne leur donnes que 3€ et pas les 15€ qu'ils demandent, ce n'est pas parce que tu paies moins pour la presse mais parce que tu étales, et c'est plus facile à accepter pour eux.
[^] # Re: Jeu de mains, jeu de vilains. Donner c'est clair.
Posté par gasche . En réponse au journal Financer le web proprement grâce à la pub et une paire de modules Firefox. Évalué à 10. Dernière modification le 03 juillet 2016 à 00:54.
À mon avis tu te méprends profondément sur la difficulté de repérer ce système. Quelques régies ont de grosses parts, et elles vont facilement voir que ton IP génère beaucoup plus de clics qu'un être humain normal—tu parles de milliers de clics par jour, personne ne fait ça. Et c'est facile pour elles d'échanger l'info sur les "faux cliqueurs" si c'est dans leur intérêt de groupe.
La seule façon d'être complètement non-repérable c'est de se comporter comme un humain normal, c'est à dire… ne pas cliquer beaucoup. Du coup tu rapportes aux sites que tu visites autant que si tu cliquais de bonne foi, c'est-à-dire… pas beaucoup. Et cette façon de financer le web reste non-viable, pousse à l'exploitation et aux contenus mouche-à-clic, etc.
Le calcul est très simple: si chaque zozo qui utilise un cliqueur randomisé se comportant comme un humain va sur ces sites, ça fait comme un zozo normal, donc ça change pas grand chose. S'il faut 10 000 visiteurs non-bloquants typiques par jour à un site pour vivre, et que tu les remplaces par ton système… il faut toujours 10 000 personnes équipées de ton système. Ça reste pas viable, et ça continue à encourager les sites à mettre du contenu attirant plutôt que de qualité.
Tu parles de financer le web "proprement", mais ça reste de l'argent sale. L'argent propre c'est celui que tu as gagné avec ton travail.
# Jeu de mains, jeu de vilains. Donner c'est clair.
Posté par gasche . En réponse au journal Financer le web proprement grâce à la pub et une paire de modules Firefox. Évalué à 10.
Les publicitaires et les agences de pub (dont Google) ne sont crédibles que s'ils peuvent prouver un taux de retour sur les clics qu'ils comptabilisent. Si ta solution devient plus connue, tout ce que tu vas gagner c'est qu'ils vont développer des contre-mesures pour détecter leur usage (c'est certainement déjà fait: les régies publicitaires se sont sans doute rendu compte que tu t'es mis à clicker sur des milliers de pubs par jour en passant d'un taux zéro, s'ils ne sont pas idiots ils ne comptent pas tes clics), et pénaliser les sites que tu fréquentes pour ces "faux clics". Et l'effort dépensé pour repérer les tricheurs va juste diminuer la valeur des clics et donc motiver les sites à inclure encore plus de pub…
D'ailleurs le but de AdNauseam n'est pas de générer du revenu pour les sites qui montrent la pub, mais de casser la fiabilité de ces pubs et donc de nuire aux annonceurs. Eux-mêmes n'essaient pas de dire que leur utilisation apporte de l'argent aux sites que tu visites, c'est toi qui te dupe par espoir, je pense. (Mais même pour cet usage j'ai des doutes sur l'efficacité à long terme.)
Il y a une solution simple, honnête, claire et viable: donner de l'argent aux sites que tu veux soutenir. Je soutiens la presse tout en évitant la publicité en m'abonnant aux journaux qui font un travail de qualité (et en utilisant un bloqueur de pubs). Tout le monde peu le faire, chacun à la hauteur de ses moyens—personnellement je pense que 10% de mes revenus après coûts fixes en dons est une bonne cible, mais ça n'inclus pas que la presse.
En plus avec des dons les journalistes peuvent garder la tête haute sur la façon dont ils gagnent leur vie. Ça fait quelques euros par mois gagné par un soutien de plein gré d'une personne qui apprécie leur travail, au lieu de les escroquer sur le dos d'une personne dont un publicitaire aura exploité les faiblesses pour faire naître l'envie de consommer.
[^] # Re: Pour quel projet voter ?
Posté par gasche . En réponse au journal Demandez à l’UE un audit de code open source. Évalué à 6.
La liste est déjà construire à partir de logiciels utilisés par les institutions européennes. Cf. la page wiki qui contient des informations sur la liste.
C'est bien de donner des conseils sur comment refaire ce genre d'initiatives en mieux, mais maintenant qu'il y a une proposition concrète de faite, pourquoi ne pas se renseigner sur les logiciels proposés, en discuter, et faire ton choix ?
[^] # Re: Pour quel projet voter ?
Posté par gasche . En réponse au journal Demandez à l’UE un audit de code open source. Évalué à 5.
Il manque un peu d'information sur comment les logiciels ont été sélectionnés. Mais comme ma page wiki le mentionne, les logiciels ont été choisis à partir d'une liste de logiciels utilisés ou recommandé au sein de la commission européenne:
(Je me permets de faire un peu de pub sur cette page wiki: si tu veux l'éditer pour ajouter des informations sur les différents logiciels, par exemple les briques logicielles qu'ils utilisent et leur niveau de sensibilité, ça serait très utile !)
Du coup les recommendations du style "plutôt que X vous devriez avoir Y" ne sont pas forcément utiles dans le cadre de ce sondage précis : si les institutions de l'EU utilisent Drupal plutôt que Y, elles ont choisi de proposer Drupal à l'audit. Ça me semble être un choix raisonnable.
Pareil pour FileZilla / WinSCP: si les systèmes des institutions de l'EU utilisent les deux, ça fait sens d'auditer les deux. (Ça fait sens aussi de consolider un système en limitant les redondances entre logiciels utilisés, mais en même temps c'est bien aussi de laisser du choix aux techniciens qui font leur boulot.)
Bien sûr on peut discuter de s'il vaut mieux auditer des logiciels utilisés par l'EU ou utilisés par tout le monde et pas l'EU en particulier, des logiciels établis avec une grosse base d'utilisateurs ou plutôt des logiciels prometteurs qui seront plus utilisés demain, etc…. Mais là il y a une liste bien définie avec des justifications raisonnables donc je trouve que c'est utile de faire un choix dans ce qui est proposé—même s'il y a une option "Other choice" que tu peux utiliser si tu veux.
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 3. Dernière modification le 27 juin 2016 à 21:51.
D'une part, le code est incorrect si je commence à construire des arbres de paires; en OCaml
'apeut être instancié par(int * int)par exemple. D'autre part l'encodage ne passe pas à l'échelle si j'ai plusieurs constructeurs, par exemple un constructeur pour les noeuds noirs et un pour les rouges dans un arbre rouge-noir; ou alors deux types de feuilles différentes, etc.Je ne dis pas que c'est dur (ci-dessus je proposais des encodages qui sont relativement agréables à utiliser si le langage a du pattern-matching comme racket/match par exemple), mais je pense que trouver une représentation générique n'est pas aussi simple et risque de pêcher en performances par rapport à un runtime (et surtout un choix de représentation des valeurs) qui gère ça en dur.
[^] # Re: Pour quel projet voter ?
Posté par gasche . En réponse au journal Demandez à l’UE un audit de code open source. Évalué à 3.
Merci ! J'avais de mon côté posté un commentaire sur le billet de blog, mais "Your comment will be public soon". (Et je n'utilise pas Twitter moi-même donc c'est un canal de plus que je n'aurais pas su exploiter.)
# Pour quel projet voter ?
Posté par gasche . En réponse au journal Demandez à l’UE un audit de code open source. Évalué à 8.
La liste des projets proposés au vote:
J'ai créé une page wiki qui décrit succintement chaque projet, et qui encourage les gens à ajouter des informations sur les projets pour aider chacun à faire son choix de façon informée.
(Méta-commentaire: je regrette de passer par le service propriétaire github pour cela. J'ai essayé d'utiliser etherpad/framapad à la place mais le support Markdown est inexistant ou très mauvais, ce qui rend cette solution inutilisable en pratique, en plus du fait que Framapad montre une popup en français à tous les visiteurs—issue #9.)
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 3.
P.S.: Stephen Dolan a aussi travaillé sur l'ajout de l'instrumentation pour afl-fuzz dans le compilateur OCaml, donc il est possible qu'il propose un fuzzer passant par malfunction et piloté par AFL. (AFL fait des opérations de fuzzing byte-par-byte, donc Stephen avait proposé d'écrire une fonction qui prend une chaîne d'octets et la transforme en un programme OCaml—ou Malfunction en l'occurence.)
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 3.
L'implémentation OCaml n'est pas du tout vérifiée (par contre il y a des versions modifiées et simplifiées qui ont été "certifiées" au sens des normes machin il me semble, en tant que logiciel utilisé par Scade et autres produits Esterel-tech) est est pleine de bugs (comme tous les logiciels de cette ampleur), nous en corrigeons un petit peu chaque jour ou presque.
Effectivement le test aléatoire du compilo OCaml avec Malfunction serait une façon intéressante de découvrir des bugs et j'espère que quelqu'un (Stephen, moi ou quelqu'un d'autre) aura le temps de faire joujou avec ça, c'est assez marrant en plus.
Un autre truc que j'aimerais faire c'est fuzzer le type-checker, mais bien sûr pour cela Malfunction ne peut pas être utilisé. Un autre travail récent qui pourrait aider sur ce sujet est décrit dans A Type Checker for Annotated OCaml Abstract Syntax Trees, or An Effective Type System for OCaml par Pierrick Couderc, Michel Mauny, Grégoire Henry et Fabrice Le Fessant.
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 5.
Par ailleurs, tu es aussi très défensif, voire agressif et désagréable, dans tes arguments. C'est une discussion technique où les gens posent des questions et y répondent—il n'y a pas de désaccord de fond, au pire des incompréhensions à clarifier—c'est plus agréable pour tout le monde si tu restes calme et respectueux dans ta façon d'écrire, et si tout le monde suppose que chacun est de bonne foi et fiable dans ses affirmations.
(Par exemple: pas besoin de "je n'en ai rien à faire", pas besoin de petite pique, et pas besoin d'expliquer que les arguments des gens n'ont "aucune valeur".)
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 3.
Core est un langage intermédiaire typé, donc pour pouvoir produire une représentation Core il faut construire une dérivation de typage qui montre que ton programme intermédiaire vérifie les règles de typage de Core. C'est très difficile voire impossible en pratique (sans sacrifier les performances), ce qui rend la représentation Malfunction, non typée, plus agréable comme cible.
(C'est un point de détail intéressant qui m'a été rappelé par Sam Lindley, un des implémenteurs de Links et donc une des cibles pour Malfunction. À l'inverse, avoir une représentation intermédiaire typée a aussi des avantages quand on développe un compilateur (par exemple pour débugger, et pour mieux comprendre le typage du langage de surface ou la sémantique des optimisations effectuées), donc ce n'est pas un mauvais choix de la part de GHC.)
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 2.
(Après avoir regardé un peu plus en détail, d'une part il vaudrait mieux utiliser des petits entiers que des symboles dans ma proposition ci-dessus, donc
'(0 leaf-value)et'(1 left right), et d'autre part Chicken Scheme a une notion de tagged pointer qui serait sans doute un meilleur choix ici, où l'information de tag pour les constructeurs non-constants serait stockée avec le pointeur plutôt qu'avec la valeur, même si ça reste une représentation nettement moins compacte—Haskell stocke le constructeur dans le pointeur parfois, mais de façon plus compacte.)[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 2.
Certes, x86 permet d'exprimer efficacement les types sommes. Mais la traduction n'est pas simple et demande beaucoup d'effort; ce n'est pas une représentation intermédiaire adaptée pour un compilateur. Au contraire, une représentation intermédiaire pour OCaml essaie de faciliter la représentation efficace de ce qui existe dans le langage, et de manière agréable à produire (si on suppose que le compilateur est bien conçu), donc c'est une indication forte que tous les aspects importants du langage OCaml seront bien couverts par cette représentation.
Il n'est pas du tout clair que n'importe quel langage permet de représenter les types sommes de façon efficace. En Scheme par exemple, comment coderais-tu quelque chose comme
Mes idées immédiates pour faire cela sont soit de construire des paires
(tag, paramètres), c'est-à-dire une s-exp donc la tête est un symbole'leafou'nodeet le nombre d'éléments suivants est en fonction, ce qui donne une représentation moins efficace (OCaml met le nom de constructeur dans le mot de tête aussi utilisé par le GC, alors que là tu paies avec un mot de plus par valeur; et le test d'égalité de symboles est plus lent), ou alors essaie d'utiliser unstructet tester l'identité du type, ce qui donne encore une représentation moins efficace (le nom du type est dans un espace de nom plus grand que les constructeurs fixés ici, et donc va être plus difficile à encoder comme une série de petits entiers consécutifs).[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 3.
On a dû mal se comprendre. Malfunction c'est en gros une version simplifiée (et spécifiée) de Lambda, un langage à une distance minimale qui permet d'être clair et facilement interprétable et quand même se traduire de façon très transparente vers Lambda. Quand tu proposes d'utiliser un Scheme "à la place", je comprends "à la place de Malfunction", et pas "à la place de Lambda", puisque (1) Lambda lui-même n'est pas proposé comme cible directe pour les autres langages et (2) traduire Malfunction tel qu'il est vers Lisp/Scheme serait difficile voire impossible (sans perte d'efficacité) vu l'impedance mismatch entre les représentations. Si tu veux un compilo qui vise une implem. Lisp/Scheme, il faut produire du Lisp/Scheme (ou une de leurs représentations internes), pas du Lambda-de-OCaml-simplifié.
Ou alors tu demandes peut-être si le compilateur OCaml pourrait compiler vers (la représentation intermédiaire d'un compilateur) Lisp ou Scheme, mais là c'est une question encore différente qui n'a pas vraiment de sens—en fait les premiers Caml étaient implémentés de cette façon là, et je crois qu'il y a eu un frontend Bigloo ou Stalin pour Caml, mais aujourd'hui les langages, sémantiques et attentes de domaine optimisé sont trop différentes je pense.
Regarde par exemple la partie lambda_switch de l'AST Lambda, qui définit une construction de switch avec une famille de cas pour gérer les constructeurs constants (représentés comme des entiers) et les constructeurs à paramètres (boxés sur le tas, donc avec un pointeur en tête et un tag de constructeur quand on suit le pointeur).
L'auteur de compilateur continue à viser la représentation Malfunction, qui est stable. C'est s'il veut appeler le compilateur OCaml directement depuis son frontend qu'il doit utiliser l'API du compilo qui n'est pas stable. Mais bon LLVM n'offre pas de stabilité entre les versions non plus et pourtant plein de compilateurs l'utilisent—souvent à raison.
Par ailleurs c'est classique dans un compilateur de produire une représentation intermédiaire dans un fichier et d'appeler derrière un outil externe—au lieu de tout avoir dans un même processus. Chicken Scheme lui-même produit du C et appelle un compilo C derrière. Beaucoup de compilateurs natifs produisent une représentation textuelle de l'assembleur généré et appellent l'assembleur système derrière. Pareil pour le linker, tu ne recodes pas, tu appelles un programme externe. Ce n'est pas fondamentalement "alpha" et ça marche bien.
Sur les macros: que tu définisses un langage propre (Malfunction) ou un ensemble de macros par dessus un langage plus simple, ça ne change pas grand chose du point de vue de l'utilisateur, c'est-à-dire l'implémenteur d'Idris, Eff ou Links. Dans tout les cas il faut produire cette représentation intermédiaire.
Ben ça dépend de comment les deux langages sont compilés et si les représentations sont compatibles. Par exemple si les types algébriques sont représentés différemment, il faut traduire d'une représentation vers l'autre, donc tu as coût important quand tu transfères des données (alors qu'avec une représentation partagée, rien à faire). Si tu as deux GCs avec des attentes incompatibles, encore une fois c'est la prise de tête et une coopération moins efficace.
Par exemple Coq utilise pas mal le fait qu'il compile vers OCaml pour écrire des programmes mixtes. (Dans Compcert par exemple, le gros du compilo est du Coq, mais il y a des parties en OCaml et c'est bien pratique (et l'efficacité est importante).
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 3.
Je n'arrive pas à trouver des informations fiables sur les performances de Chicken Scheme par rapport à OCaml. C'est un des Scheme efficaces, et il y a une communauté derrière (cf. la relativement large couverture de bibliothèque (eggs) disponibles), mais très peu d'information trouvables en ligne sur les performance en pratique.
Par ailleurs pour servir de représentation intermédiaire il faut que les utilisateurs puissent écrire du code bas niveau, où des informations de typage partielles sont connues et exploitées. Il me semblait que Chicken se restreignait à R5RS. Quel est le support dans le langage pour dire qu'une donnée est un entier de 32 bits, ou ne peut pas être un pointeur, pour manipuler des flottants non boxés, etc. ? Ou alors tu as en tête l'usage d'une représentation intermédiaire utilisée par Chicken (comme le bytecode Guile par exemple), mais alors laquelle ?
La syntaxe n'a pas grand chose à voir avec le but de Malfunction. C'est un langage intermédiaire, pas un langage de surface pour les utilisateurs. Du moment que la syntaxe est non-ambiguë, clairement définie et facile à produire et à lire, ça pourrait être du XML ça n'aurait aucune importance.
Beuh, encore une fois le but c'est d'obtenir facilement un compilateur décent pour un langage expérimental à moindre coût, si pour cela il faut piper dans un fichier texte au milieu je ne vois pas vraiment le soucis. Par ailleurs le compilateur OCaml expose une API pour manipuler directement la compilation (mais encore une fois elle n'est pas stable) si c'est vraiment important.
Je ne vois pas vraiment l'intérêt.
Lambda a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation intermédiaire du compilateur OCaml, qui en a). Par contre il n'y a pas de pattern-matching complexe au niveau de Lambda (seulement des switches sur les tags ou des entiers), puisque le pattern-matching est compilé en amont, après le typage.
Imagine que j'ai un programme OCaml qui veut appeler une fonction Links (ou Eff ou Idris) ou l'inverse. Je peux vérifier que les types sont à peu près cohérents (les deux langages n'ont pas les mêmes types mais il y a sous-ensemble commun qui garantissent à peu près les mêmes comportements), compiler les deux vers Lambda et les lier ensemble. Pas besoin que Lambda lui-même soit typé, il faut seulement que les stratégies de compilation choisies pour ces types communs soient compatibles (ou qu'on sache insèrer un peu de code glue entre les deux).
Par exemple ça peut permettre d'échanger facilement des données de grande taille (par exemple un gros terme de preuve généré par Idris) sans copie/traduction, parce qu'en partageant le backend et le runtime tu as la même représentation des deux côtés.
[^] # Re: Représentations intermédiaires du compilateur OCaml
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 3. Dernière modification le 26 juin 2016 à 15:55.
La représentation interne Lambda (qui est bien celle que vise Malfunction) n'est effectivement pas spécifiée et peut changer d'une version du compilateur à l'autre. Par contre le langage d'entrée de Malfunction est spécifiée, et plus simple que Lambda; Malfunction va produire du code pour une version spécifique du compilateur OCaml, mais peut s'adapter pour suivre les changements de représentation du Lambda.
Je pense que les backends/runtimes des bonnes implémentations Lisp (SBCL par exemple) et de OCaml sont relativement comparables en terme de qualité aujourd'hui. La question se pose aussi dans l'autre sens: pourquoi choisir Lisp plutôt que OCaml ?
La gestion des types algébriques, avec une représentation des valeurs efficaces, peut être un argument en faveur de OCaml—à ma connaissance les Lisp n'ont pas de représentation natives pour ce genre de valeurs, qui sont très utilisées par les adopteurs potentiels (Idris, Agda, Eff, Links, etc.).
(À l'inverse certains Scheme ont des continuations efficaces, ce qui peut être important pour certains langages, mais pas les Lisps à ma connaissance.)
Un autre argument est l'interopérabilité : partager une représentation interne et le runtime ça permet aussi une communication inter-langage à moindre coûts (comme c'est facile entre les langages qui tournent sur la JVM ou le CLR), et ces langages peuvent être plus intéressés par le fait d'interagir avec un langage typé, qui permet de donner des garanties partielles de sûreté au niveau du lien entre les fragments de programmes écrits dans différents langages.
[^] # Re: model
Posté par gasche . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 4.
Je pense que la suggestion de c3 fait sens, dans le sens où les Scheme sont sans doute plus facilces à produire programmatiquement—et ne demandent pas au programme en entrée d'être bien typé. Mais tu peux aussi bien sûr invoquer le compilateur OCaml depuis un programme, et même utiliser compiler-libs, une bibliothèque qui permet d'appeler les fonctions internes du compilateur depuis un programme OCaml—mais il n'y a pas de garantie de stabilité de l'interface entre les versions du langage.
[^] # Re: Unicode et Haskell
Posté par gasche . En réponse à la dépêche Le compilateur GHC Haskell en version 8.0.1. Évalué à 2.
Je ne pense pas qu'on puisse dire cela puisqu'il y a des enfants qui ont, au contraire, beaucoup apprécié les maths modernes, d'une façon qui transcende la reproduction sociale—certains de ces enfants sont membres de la communauté scientifique aujourd'hui.
[^] # Re: LinuxFR est pro-Systemd
Posté par gasche . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 3.
Je ne vois pas trop de raison de regretter les points Godwin (même pour rigoler), mais les remplacer par des commentaires sexistes c'est quand même assez triste.