gasche a écrit 1151 commentaires

Le typage statique optionnel
C'est juste que ça rend possible le débuggage et facilite l'intégration dans un IDE un peu évolué. Par exemple cela peut aider pour du refactoring.

C'est une idée reçue convaincante, mais en pratique les premiers IDE évolués à proposer ce genre de chose étaient des environnement de développement pour Smalltalk et Lisp. Il est absolument faux de dire que le debug n'est "pas possible" dans un langage sans typage statique, et à ma connaissance Lisp et Smalltalk restent toujours inégalés dans ce domaine.

(Exemple qui m'a toujours fait rêver : avec les exceptions resumable de Lisp, quand un programme lance une exception qui n'est pas rattrapée il se fige, le programmeur peut inspecter le problème (explorer les valeurs etc.), corriger le code, et revenir au point du programme qui avait lancé l'exception, le tout sans arrêter le programme.)

Ce qui rend le débuggage difficile, ce sont les langages qui avec type erasure, où l'information de typage n'est pas conservée à l'exécution. Tous les langages qui font ça sont des langages typés statiquement (même si beaucoup de langages typés statiquement ne le font pas); ceci dit, ça a des avantages en performance, donc c'est un compromis à faire.

L'idée selon laquelle le typage est nécessaire pour les IDE, le refactoring et le debug est historiquement fausse.

Il parle bien de la valeur NULL, et il l'argumentation sur pourquoi c'est un soucis est donné au début de son post : Tony Hoare a déclaré que son invention était sa "Billion-dollar mistake". Plus d'explications par exemple sur programmer stackexchange (lien trouvé en googlant "NULL Billion-dollar mistake").

(Merveille des notes LinuxFR : je ne comprends pas pourquoi son commentaire, qui est argumenté et apporte du contenu, est masqué, alors que ta question, qui est légitime mais qui n'est pas follement trépidante en elle-même, est à 6. À choisir je préférerais que ce soit l'inverse.)

CoffeeScript a un défaut impardonnable, l'absence de mot-clé "let" ou "var" pour une définition de variable locale, qui fait qu'il ne permet pas de masquer localement des variables existantes. Ça force un programmeur travaillant dans un bloc à être conscient de toutes les variables déjà présent dans le contexte, ce qui pose des problèmes de maintenabilité; par exemple, il est risqué par exemple de copier/coller un bout de code qui change des variables, on risque en le déplaçant de changer la sémantique de l'ensemble du programme et donc d'introduire des bugs.

Le reste des changements sont raisonnables, c'est principalement du sucre syntaxique par dessus JS (donc sans aucune influence sur la sémantique des programmes). Ils auraient dû se cantonner à du sucre, au lieu de jouer avec la sémantique. Même si c'est un problème qui n'est pas toujours gênant en pratique (si on se force à éviter les portées imbriquées), ça reste un problème fondamental pour un langage de programmation, un peu du même genre que choisir la liaison dynamique plutôt que lexicale par erreur. J'espérais que ce genre d'erreur était derrière nous.

Un développeur d'x264 n'est pas un développeur d'H.264. Ça fait toute la différence.

Tu as tout à fait raison. C'est une des rares personnes compétentes dans le domaine à s'être exprimé sur le sujet, et on le critique parce qu'il développe un logiciel libre pour gérer un format concurrent.

C'est facile de rejeter une critique en dénonçant la partialité. Il n'empêche que ses avis étaient argumentés et techniquement justifiés, et que les gens n'ont à opposer qu'un maigre "oui mais Google ils savent ce qu'ils font, c'est forcément génial leur truc".

Donnez-moi un lien vers un développer également compétent et qu'on soupçonne d'être biaisés dans une autre direction (par exemple un développeur pour du software WebM). Je serai ravi de lire ses contres-arguments. En attendant, les gens qui ont des arguments techniques sont convaincants.

Ceci dit, NativeClient fonctionne déjà sur x86/amd64/arm, ce qui représente une grosse partie des architectures utilisées aujourd'hui. Et puis si ils ont réussi à porter sur 3 architectures, y'a pas de raison que ça ne soit pas portable ailleurs.

D'après ton document, la méthode utilisée par PNaCL pour obtenir cette portabilité est de viser l'intersection des choses supportées par ces trois architectures : que des adresses 32 bits, little-endian, un modèle mémoire ultra-rigide (sequential consistency), etc.

Ça limite donc intrinsèquement sa portabilité : si demain l'architecture Quvz devient populaire et ne respecte pas ses présupposés, elle ne pourra pas utiliser (sans une couche d'émulation) les bitcodes LLVM générés pour PNaCL.

Par ailleurs (mais ce n'est pas lié à ma remarque d'ordre général sur LLVM), le problème de NaCL c'est qu'il y a une interface très large et très lourde entre le processus NativeClient et le browser; elle dépend du fonctionnement de Chrome et n'est donc pas si portable que ça vers les autres browsers. Brendan Eich ne veut pas entendre parler de leur Pepper API et c'est donc un peu mort pour l'intégration dans Mozilla (et ce n'est pas seulement une question politique, le choix technique peut se comprendre, même s'ils pourraient faire des efforts pour essayer de faire changer ces aspects-là; ils ne sont pas intéressés).

Je ne suis pas convaincu par ton argumentation, dans les sens où tes trois points me semblent faux.

1. La facilité de la sérialisation dépend avant tout d'un choix d'implémentation du langage, celui de trimballer ou pas de l'information de typage au runtime. Les langages objets ont tendance à le faire (entre autres parce parce que leurs systèmes de typage souvent incorrects ne suffisent pas et il faut parfois un garde-fou dynamique), les langages fonctionnels ne le font souvent pas par défaut (on peut l'encoder par dessus, cf. Data.Typeable en Haskell). Les langages qui ont cette information sont favorisés, qu'ils soient statiquement typés ou non.

2. Un type algébrique à la ML (ou une hiérarchie de classe si tu veux du lourd) permet(tent) de représenter un valeur qui peut avoir plusieurs formes différentes. Si tu veux cacher cette conversion (mot-clé -> truc-paramètre-de-filtrage), tu peux utiliser des conversions implicites; ce n'est en rien incompatible avec le typage statique (cf. les implicites de Scala).

3. Je ne vois pas en quoi la présence ou non de typage statique change le statut des arguments optionnels. Une fonction précise combien d'arguments elle attend, éventuellement des valeurs par défaut pour ses arguments, et c'est la sémantique opérationnelle (à l'exécution) qui précise ce qui se passe si un argument n'est pas fourni. Le typage statique ne pose aucun problème. Il peut par contre parfois être un peu utile, quand on utilise des formes de surcharge basées sur le typage : par exemple si la fonction attend un entier, une chaîne de caractères et un objet, on peut l'appeler en passant seulement l'entier et l'objet, et le typeur comprend que c'est la chaîne de caractères qui n'a pas été renseignée. Je ne dis pas que c'est une bonne idée, mais qu'à priori le typage "aide" les arguments optionnels plus qu'il ne les gêne.

Pour les fonctions à nombre d'argument multiple, on peut en fait typer ça correctement (après la façon de typer dépend de la façon dont la fonction utilise ses arguments), mais le fait est que ça ne fait pas partie de la plupart des langages de programmation typé. C'est bien le seul point de ton argumentaire qui me semble recevable, sachant que par ailleurs je n'aime pas trop les fonctions à nombre d'argument multiple et je pense qu'il y a souvent moyen de faire mieux et plus propre en s'en passant (si le langage est suffisamment expressif).

Ceci dit je ne suis pas fondamentalement contre l'utilisation de Scheme/Racket/Guile comme langage de configuration (si on pouvait éviter Elisp par contre, qui n'est de loin pas le Lisp le plus réussi). C'est juste que je ne vois pas d'argument conseillant, dans l'absolu, d'éviter les langages ayant du typage statique.

Ils essaient d'obtenir quelque chose de performant. C'est contradictoire avec certains de leurs choix techniques (le typage qui ne donne aucune garantie), mais quand même prendre Parrot ce serait se tirer dans le pied.

Le problème technique principal de LLVM c'est qu'il n'est pas portable (le bytecode produit dépend de l'architecture prise en compte par le compilateur en amont, et on ne génère pas le même bytecode vers des architectures différentes); de plus, sa sémantique est assez mal spécifiée, repose beaucoup sur les spécificités de C (forcément la force de travail autour de LLVM vient de Clang aujourd'hui).

Ça n'empêche pas Brendan Eich de faire de la pub pour emscripten, l'évaluateur de bytecode LLVM codé en Javascript, mais aujourd'hui LLVM directement n'est pas une solution très viable pour cet usage (pour lequel il n'a pas été prévu).

Qu'entends-tu par "historiquement" ? Le langage ML original a été développé dans les années 70. Il existait des langages dynamiques à l'époque (Lisp et Forth au moins), mais je pense que l'inférence de types est tout aussi "historique", d'autant qu'elle s'appuie sur de la recherche qui a été effectuée (dans un autre cadre) dans les années 50.

Ils veulent quelque chose de performant, donc je ne suis pas convaincu que la VM Erlang soit un bon choix technique. Elle scale bien, gère bien la distribution, mais pour les performances brutes c'est ça, quitte à prendre une machine virtuelle Hotspot fait nettement mieux. Ceci dit, le design actuel de Dart n'est pas non plus très adapté à la performance...

Comme je l'ai dit, il me semble que c'est une convention sociale, d'habitude implicite, et fondée plus sur la tradition (peut-être liée à la religion, je ne sais pas) que sur un raisonnement rationnel et pragmatique. Là où la raison dit qu'on peut toujours la vérité, mon sens de la politesse, qui est personnel mais en pratique partagé par une majorité, me dit que précisément à l'occasion de la mort de quelqu'un on peut faire un petit effort pour se retenir et se donner un peu de temps "je fais des efforts pour considérer que c'était une personne formidable, ou alors ça m'est égal et alors je m'abstiens tout simplement".

C'est un peu caricatural mais j'ai l'impression que les informaticiens/geeks ne sont pas forcément très pourvus en sens de ces choses là (ce n'est pas un jugement de valeur, ni une remarque sur toi Zenitram en particulier, par contre oui c'est une généralisation hâtive). Sur LinuxFR on se fait visiblement moinsser quand on dit qu'il vaut mieux éviter de dire du mal de quelqu'un à l'occasion de sa mort. Pourquoi pas, ce n'est pas quelque chose de vital (sic) de toute façon.
Et ça a cet aspect des coutumes et des conventions qui fait qu'il est difficile de les justifier rationnellement à une personne prête à tout remettre en cause, pas forcément à tort d'ailleurs; c'est comme ça qu'on fait, voilà tout. Pour ma part je ne vois pas l'intérêt de déroger à cette règle implicite (comme je l'ai dit, j'ai l'impression d'avoir largement assez de temps, avant et après, pour dire ce que je veux et même le dire de façon agressive, irrespectueuse, etc.), et par contre je vois des inconvénients (passer pour un rustre, blesser des gens qui étaient proches de la personne morte, etc.).

C'est une question de conventions et de bon goût. Au lendemain de la mort d'une personne, on pense avant tout aux gens pour qui sa disparition est une perte. Tu as largement assez de temps, avant et après sa mort, pour expliquer par A+B que c'était un type détestable. Mais au moment de sa mort, tu essaies de parler surtout de ses points positifs, ou tu t'abstiens. C'est un élément de politesse de base, me semble-t-il.

Avant tout, je suis conscient que la dépêche a demandé un travail important et je respecte cette investissement.

En lisant une dépêche Steve Jobs sur LinuxFR, je m'attendais à un troll sur l'aspect fermé des logiciels Apple. Ça aurait été un peu gênant, un peu délicat peut-être (surtout certains trolleurs pas subtils) quand c'est au sujet de la mort de quelqu'un, ce n'est clairement pas le bon moment pour lui casser du sucre sur le dos. Mais ça aurait aussi été intéressant, parce que je pense que l'histoire d'Apple et de Steve Jobs soulève une question importante :

« Pourquoi des gens intelligents et techniquement compétents ont-ils fait le choix de fermer au maximum leur logiciel et leur matériel, choix qui va à l'encontre des principes de bases des libristes ? Cela est-il lié à leur succès ? »

La question n'est pas posée dans l'article, pas discutée, et je trouve que c'est bien dommage. Les photos d'iPod, honnêtement, on s'en fout.

Après il y a des questions plus personnelles qu'on se pose sur l'homme lui-même. C'est bien gentil de l'élever en héros de l'informatique ordinaire, mais qu'a-t-il vraiment fait ? Quelles étaient ses qualités propres ? C'est pas facile de faire la différence entre les choses qu'on lui attribue et qui ne sont pas de lui, et les choses qui viennent vraiment de lui.
C'était un excellent présentateur, ça se voit au succès de ses présentations Apple. De là on peut déduire qu'il était sans doute doué en "sens du commerce", le marketing mais aussi le fait de deviner où va se tourner le marcher et quels sont les besoins des gens. Était-ce aussi un technicien ? Est-ce qu'il connaissant bien lui-même le fonctionnement des systèmes qu'il a fait vendre, et peut-être aussi poussé à concevoir ? On parle plutôt souvent de Wozniak comme le techie de la bande; qu'en est-il de Jobs ?

Aujourd'hui, s'enthousiasmer sur les bienfaits de Steve Jobs est de rigueur. Mais a-t-il vraiment rendu service ? En quoi le fait de vendre des iPhones a-t-il rendu le monde meilleur ? Le jour où Bill Gates décédera, est-ce qu'on le montera aux nues comme cela lui aussi ?

Je pose des questions honnêtes auxquelles je n'ai pas la réponse (je ne connais pas Steve Jobs ni vraiment son travail au sein de Apple); ce ne sont pas des questions réthoriques et je ne sous-entend pas que c'est un vilain. Mais c'est ce genre de choses que j'aurais aimé apprendre dans une dépêche.

On peut lire beaucoup de trucs sur Steve Jobs au lendemain de sa mort. J'ai bien aimé pour ma part cette retranscription de ce qu'Eric Schmidt dit de Jobs à cette occasion.

Le message ironique n'était pas nécessaire, le fait que le commentaire ait été moinssé suffit pour se marrer un bon coup.

Je suis parti un avant ces coups de théâtre, quand on pouvait déjà sentir que la situation était pourrie jusqu'à la moelle. Je suis déçu de ne pas trouver trace de ces problèmes de gouvernance très importants dans "l'histoire" présentée par la dépêche.

J'aimerais bien savoir si la situation a changé. L'insupportable fondateur a-t-il récupéré les pleins pouvoirs comme il l'espérait, et ont-ils finalement trouvé des développeurs pour remplacer ceux qui étaient partis ?

Je suis aussi intéressé par des nouvelles sur le statut de Portage. À l'époque où je suis parti c'était assez ridicule, il y avait un fork raisonnable, Paludis (sur la base "nous en code en C++ et pas Python et du coup c'est nettement moins lent"), mais les développeurs des deux solutions se battaient âprement et l'utilisation de Paludis était régulièrement compliquée par des ebuild malformés que Portage acceptait et que les développeurs ne corrigeaient pas trop vite.

Et surtout, comment ça se compare à Github, Gitorious ou Bitbucket. Je sais qu'en théorie une forge gère plus de fonctionnalités, etc. etc., mais mon expérience pratique est que les développeurs préfèrent largement github ou bitbucket, jugés plus légers et plus facile d'utilisation.

Pour moi les forges classiques ont un gros problème d'interface utilisateur (ces onglets partout, c'est pas très attirant, pareil le "Issue tracker" de github est sensiblement plus agréable à utiliser), et elles risquent simplement de disparaître s'il n'y a pas de gros progrès là-dessus.

Ton évaluation du langage est intéressante mais inutilement aigrie. Tous les langages ont leurs défauts, et il est important de bien en être conscient. Mais ce n'est pas une raison pour être inutilement négatif : si tu arrives à convaincre des gens par des arguments non rationnels, tu ne leur rends pas service (puisqu'ils vont faire un autre choix de langage en croyant éviter les problèmes, pour découvrir ensuite qu'ils ont les mêmes problèmes ou d'autres).

La lib standard est totalement vide.

La bibliothèque standard est minimaliste. Pas "vide", mais pas suffisante. Comme tu le dis, il existe d'autres bibliothèques de base, dont je ne sais pas si elles "règlent le problème" (elles restent moins étendues par exemple que la bibliothèque standard Python).

Sauf que c'est essentiellement un faux problème : le problème n'est pas la taille de la bibliothèque standard (qui a la plus grosse ?) mais la relative difficulté d'adoption des bibliothèques tierces. Ce qui fait la force de Perl ce n'est pas en soit la bibliothèque standard (qui dans mon souvenir n'a rien d'extraordinaire), mais le CPAN qui permet d'accéder à un énorme écosystème facilement.
Alors oui ça manque pour OCaml (par rapport à Perl, Haskell (cabal), Python etc.) mais c'est un problème de communauté plutôt que de langage. C'est en travail : GODI n'a pas su convaincre, maintenant on parie sur Oasis-DB.

Par ailleurs pour le détail, "@@" et "@$" ne sont sérieusement utilisés que par asmanur à ma connaissance (donc "tout le monde" on repassera), et ta façon de compter est un peu discutable puisque Batteries est une extension conservatrice par dessus Extlib. Tu ne comptes pas "Core" et "Core Extra" comme deux bibliothèques. Enfin je ne comprends pas "ce n'est pas une excuse", peux-tu développer ?

Pas de gestionaire de packages par défaut.

Qu'est-ce que ça veut dire ? De nos jour tout le monde utilise findlib. On juge les langages sur leur "distribution de base" maintenant ? Je pense que tu as mieux à critiquer que les choix de packaging des distributions.

Rien de plus chiant que de compiler de l'OCaml.

Forcément, quand on part d'un script qui envoie *.ml à la chaîne de compilation, c'est chiant. Par contre si on fait des choses un poil propres (oui, il faut respecter l'ordre de dépendance), il n'y a pas de problème selon mon expérience personnelle (et encore moins de problèmes depuis ocamlbuild qui, si si, possède une documentation). En particulier j'ai jamais eu à coder un tri topologique (buggué ou non :-) pour ça, et je trouve un peu douteux de projeter vos propres erreurs de conception sur le langage lui-même.

Tu pourrais répondre à ma critique d'au dessus « ocamlbuild ». Où est la doc ?

http://brion.inria.fr/gallium/index.php/Ocamlbuild

Combine l'absence de documentation à l'utilisation d'extensions syntaxiques qui ont été crées uniquement pour ce projet.

Je ne comprends pas. OCamlbuild n'utilise pas à ma connaissance d'extensions syntaxiques particulières. Tu parles de la difficulté à compiler un projet qui utilise ses propres extensions syntaxiques ? Selon mon expérience (Macaque par exemple) ce n'est encore une fois pas un problème (car contre attention à la combinaison camlp4 + ocamldoc, qui font mauvais ménage ensemble; en règle générale j'évite de préprocesser les .mli pour éviter tout soucis de ce genre).

En gros, si tu veux avoir un truc portable, tu es coincé sous 3.11.

Ben non, tu peux très bien compiler 3.12 sous windows (la raison pour laquelle personne ne se plaint c'est que la plupart des windows-users font ça; après je comprends que tu trouves ça pas cool pour les débutants). Si tu as envie de proposer un binaire un peu portable en téléchargement, fais-toi plaisir. (Bah oui c'est facile de se plaindre du manque de communauté et de tout faire dans son coin derrière)

Et si tu veux avoir un truc portable avec des Big_int, tu es donc coincé dans la mocheté à moins d'utiliser des extensions Camlp4

Bof. Depuis la 3.12 tu peux te faire tes smooth operators si ça t'amuse, et en vrai (+/) n'est pas spécialement moche (un peu lourd syntaxiquement, mais pas moins par exemple que l'émulation du pattern matching dans un langage qui ne le propose pas).

En parlant de camlp4, c'est devenu quoi camlp5 ?

Bien vu, il y a des problèmes politiques autour de camlp4/5. Je doute que ça ait une grande importance sur le langage OCaml dans son ensemble, et en tout cas ce n'est pas la question du nom du logiciel qui importe.

Pas de support des threads natifs si j'ai bien compris : tu es coincé avec un programe monothreaded car le GC n'est pas concurrent.

Marrant de mentionner ça dans une news sur Perl, à ma connaissance ni Perl ni Python ni Ruby n'ont mieux à proposer dans ce domaine. Et dans tous ces langages, comme pour OCaml, on répond en cœur aux gens d'utiliser le multi-processing, et curieusement le net n'est pas noirci de blog "c'est un scandale, les programmes python sont monothreaded". John Harrop est bon pour répandre du FUD quand ça l'arrange, mais je trouve dommage qu'ensuite les gens se focalisent là-dessus.

Il y a effectivement un choix qui a été fait de ne pas favoriser la concurrence par mémoire partagée au sein d'un même processus. Les développeurs OCaml ont évalué que le coût de développement d'un runtime concurrent était bien trop élevé par rapport aux bénéfices que ça représente, en particulier parce que (a l'époque du choix et toujours aujourd'hui) on n'a pas de bons outils de programmation de la mémoire concurrente.
Je ne vais pas écrire un pavé sur le sujet mais je pense honnêtement qu'ils ont fait le bon choix.

En pratique ça handicape certains programmes qui tiennent sur du multi-core (et n'ont pas besoin de passer à l'échelle sur un cluster par exemple) et utilisent beaucoup de partage de donnée (donc ne sont pas trop efficaces en passage de messages à la Erlang).
Ça n'est pas le cas de l'ensemble des programmes concurrents (par exemple le cas classiques des problèmes naturellement parallèles passent très bien avec du multi-processing); en réalité, seule une minorité d'usages est concernée. C'est dommage pour les gens qui veulent programmer précisément ça (et dans ce cas je leur conseille de changer de langage), mais ça n'est pas une raison pour fuir le langage pour tous les usages.

Par ailleurs, si tu veux faire de la programmation concurrente "salement" comme en C, je pense qu'un bon choix aujourd'hui pour OCaml est Netmulticore (de OCamlnet). Il manque clairement pour l'instant des bibliothèques haut niveau pour utiliser ça facilement, mais ça vient (et ça vient d'autant plus que des gens participent).

Je me permets donc de finir cette remarque par une question concrète : as-tu un exemple réel de situation où les différents outils disponibles en OCaml pour le parallélisme ne permettaient pas de résoudre un problème, alors que c'était le cas par exemple des outils Haskell ou .NET ? Je suis intéressé par un exemple que tu as réellement vécu, et pas par un lien vers John Harrop. Je ne dis pas ça pour prouver que ces exemples n'existent pas, je suis persuadé qu'il y en a, mais je pense qu'ils sont en fait assez rares (c'est à dire que certains besoins les rencontrent, mais la plupart non) et qu'il serait donc étrange de changer globalement de langage pour cette seule raison.

De nos jours Haskell est bien plus soutenu par tout le monde qu'OCaml.

C'est vrai que la communauté Haskell est plus active, et surtout que le développement est (un peu) plus communautaire. À mon avis la relative fermeture du développement est le plus gros défaut de OCaml aujourd'hui, plus sérieux que tout le reste que tu as cité.

Ce n'est pas non plus une raison pour dire n'importe quoi. De nombreuses entreprises ou institutions utilisent très sérieusement OCaml, et à ma connaissance plus que pour Haskell. Je pense par exemple au CEA, à Dassault, à la Société Générale, Jane Street que tu as cité et Lexifi, XenSource, Airbus, Microsoft (qui a utilisé OCaml pour faire de la vérification statique de drivers avant de développer F#; je crois qu'une partie de leur code est toujours en OCaml, mais je n'en sais rien)...
Toutes ces informations sont assez facilement trouvables sur le net. Je me demande comment tu as fait pour croire qu'il n'y a qu'une seule entreprise soutenant OCaml.

Par ailleurs, je ne veux pas faire une course, mais quelle entreprise visible "soutient" Haskell, à part les excellents gens de chez Galois ?

Enfin je pense qu'il y a un aspect du langage que tu as oublié de citer: le compilateur produit du code performant de base mais optimise assez peu. Par rapport à Haskell, ça a l'avantage qu'il est assez facile de prévoir les performances du programme (pas de mauvaises surprises en général), mais l'inconvénient que certaines abstractions ont un coût important qui ne disparaît pas, ce qui pousse les utilisateurs à éviter certaines choses pourtant agréables comme les bibliothèques de combinateurs.

.

Je pense que pour apprécier, aussi bien que pour critiquer, un langage, il faut avoir une idée de ce qu'on en attend et de notre besoin dans l'utilisation du langage. Tous les langages ont leurs défauts et OCaml (ou Haskell ou Python ou Perl ou...) n'est pas épargné. L'important c'est de savoir quand ces défauts seront gênants pour l'utilisation qu'on en fait (problème), et quand ça ne l'est pas. Selon mon expérience, la plupart des défauts que tu as cités ne sont un problème que pour un petit nombre d'utilisateurs.

J'ai déjà vu des gens critiquer OCaml pour ses problèmes de parallélisme par exemple, alors qu'ils ne comprenaient même pas quels cas posaient problème, et n'avaient de toute façon pas besoin d'écrire ce genre d'applications. Je crois que quand on est face à ce genre de défauts il faut savoir rester objectif au lieu de choisir le "camp" du langage qui a le moins de détracteurs bruyants.

J'apprécie beaucoup Haskell et OCaml comme langages et je pense qu'ils sont relativement complémentaires. Je comprends très bien que des gens préfèrent utiliser Haskell et je les y encourage, mais je ne suis pas persuadé qu'il y ait des "années de différence" par rapport à OCaml, et je regrette un peu cette formulation négative.

Bon c'est un peu hors-sujet mais cette nouvelle m'a poussé à jeter un coup d'œil à GCstar. Je cherche un logiciel (libre, évidemment) pour stocker des articles scientifiques et je voulais savoir s'il répondrait à mes besoins.
Je trouve très difficile de trouver des informations sur le site web :

• je n'ai pas trouvé facilement une description des fonctionnalités du logiciel, à part les différents types de collections gérées

• les "screenshots" proposés ne montrent qu'une seule fonctionnalité (une liste de collection avec une description un peu plus précise d'un item), et n'utilise que les collections "Films" et "Jeux vidéos" (je veux bien croire que ce soient les plus impressionnants graphiquement, mais j'aimerais mieux me faire une idée plus complète du logiciel)

• du coup je suis tombé sur les pages "pour les développeurs" et je peux signaler que le lien liste des tâches en cours pour GCstar sur cette page est mort. (Par ailleurs j'ai aussi eu du mal à savoir dans quel langage était développé l'application. Un faisceau d'indices suggère que c'est majoritairement du Perl, mais pas d'information claire).

Il y a une documentation qui a l'air relativement raisonnable mais je n'ai pas trouvé une description d'ensemble des fonctionnalités et de la philosophie du logiciel, qui puisse me donner une idée rapidement de si ça correspond un peu à ce que je veux ou pas. J'imagine que le moyen le plus fiable d'obtenir l'information est simplement d'essayer le logiciel, mais je pense qu'elle devrait être accessible plus facilement.

Une inerview, le contenu interessant sont les questions et les reponses. L'intro c'est un peu comme l'edito dans un journal:je me fous bien pas mal de l'avis du redac chef....mais alors, completement.

Tu pourrais être un peu plus respectueux. Ici le "rédac chef" c'est le gars qui s'est décarcassé pour trouver des questions intéressantes à poser, qui a fait l'effort de traduire... Je trouve que c'est assez gonflé de dire "je m'en fous de son avis" et de râler parce qu'en réalité l'introduction contenait une information importante.

Ta remarque sur l'ordre traduction/original est légitime. Mais je pense que les gens t'écouteraient plus si tu formulais ta remarque de façon moins insultante.

Got you.

Pour moi c'est du blabla légal que les avocats de sites webs ont l'habitude de mettre à chaque fois, et ça n'indique rien de potentielles intentions malicieuses des gestionnaires du site. La plupart des sites anglophones ont ça de nos jours.

Pour chaque clause de cet extrait je vois un ou plusieurs usages désirables pour lequel on pourrait leur coller un procès s'ils n'ont pas demandé ces trucs dès le départ. Par exemple "... license to publish the Content" bah oui, normal, on le met sur leur site il faut qu'ils aient le droit de le publier. ".. license to reproduce the Content" bah oui, c'est normal, une fonctionnalité clé de ces sites est de pouvoir forker commodément un projet qui s'y trouve, il faut qu'ils puissent reproduire le repo...

Pareil l'avertissement sur la suppression me semble être du bon sens. Aujourd'hui si un site te dit "promis juré vous cliquez sur 'delete' et on ne trouvera plus jamais cette information sur le web" il te ment, car il y a toujours des caches, des archives etc. Ici on te prévient, je vois pas ce que ça a de scandaleux.

Bref, la formulation est peut-être un peu extrême, mais à mon avis ça veut juste dire qu'ils ont reproduit le charabia habituel sans se prendre la tête, et je ne pense pas que ça nuise à la liberté de leur plateforme. Après, si ça te gêne tu es libre de choisir autre chose (mais pourquoi ne pas leur envoyer un mail pour demander clarification d'abord ?), et Savannah est aussi une bonne plateforme.

J'utilise aussi¹ XMonad et j'en suis très satisfait. Je trouve que c'est un projet cool qui a des priorités cool (simplicité du code, modularité, tests par spécification, un langage original et intéressant...) et j'ai été on ne peut plus ravi par l'effort de Wouter Swiestra de prouver en Coq (PDF) certaines propriétés de correction du cœur de XMonad.

¹: en réalité, en ce moment j'utilise Xfce pour une raison simple mais assez bête : quand j'utilise un tiling WM, les autres gens sont incapables d'utiliser mon ordinateur. Ça m'arrive assez souvent en fait qu'on me dise "tiens tu es connecté à internet? Je pourrais jeter un coup d'œil à ... ?", et dans ce cas là j'ai pas envie de devoir relancer une session X juste pour que la personne ne soit pas complètement perdue. Ça m'est arrivé quelques fois sous XMonad et c'était inutilement gênant, au point que je suis repassé sous Xfce. Je pense que c'est un problème avec tous les tiling WM (mais certains considéreront certainement que c'est une feature, comme avec un clavier dvorak).

Ici, on peut transférer des capacités d'un processus a un autre, mais pas "augmenter" les droits existants.

Oui, quand je parle d'"obtenir plus de droits" dans ce contexte, c'est au sens indirect. Avec Policykit, on discute avec un processus plus privilégié pour qu'il nous "prête" temporairement ses droits en effectuant des actions pour nous. Dans un système à capacités, on peut discuter avec un processus plus privilégié (ayant plus de capacités) pour qu'il nous transfère certaines capacités.

Plus généralement ce schéma (discuter avec un privilégié pour qu'il effectue des actions pour nous ou nous en donne le droit) est utilisé dans de nombreux systèmes de droits, puisque c'est un des plus flexibles, l'application privilégiée étant libre de gérer l'accès (les "prêts") comme elle le souhaite, indépendamment de toute politique de contrôle d'accès. C'est aussi celui utilisé par Chromium dans la version seccomp par exemple.

Une remarque : le côté obscur de cette méthode est que les politiques de contrôle d'accès ne peuvent pas empêcher deux applications qui communiquent de se "prêter" leurs droits (volontairement ou non, on peut exploiter un bug de l'application privilégiée). Une fois qu'on en est là, la seule façon de "contrôler" la sécurité du système est de s'assurer que ces processus ne peuvent pas entrer en communication. Dans ce contexte, les systèmes par capacités pures sont très intéressants, puisque chaque référence à un autre objet du système est par définition une capacité : on peut savoir avec quels objets/processus un agent donné peut entrer en contact en regardant uniquement ses capacités. Pour savoir si un agent donné pourra un jour communiquer avec un autre agent (pour lui extorquer des droits par exemple), on considère les capacités comme les arrêtes d'un graphe entre agents, et on regarde s'il y a un chemin entre ces deux agents. Les systèmes "à autorité ambiante" sont généralement aussi des systèmes "à communication ambiante" où n'importe qui peut parler à n'importe qui, et dans ce cas là on ne peut rien dire.

PS: je ne comprends pas comment les informaticiens libristes peuvent être si insensibles aux conditions de licence de la plateforme d'hébergement de leur logiciel. On fait tout un drame si le visualisateur de photographies n'est pas libre, par contre l'outil d'hébergement de code source, pourtant crucial pendant le processus de développement de logiciel libre, on s'en moque.

Par exemple on qualifie de "troll" et on moinsse mon message qui se contente de dire de façon tout à fait objective et posée "je regrette l'usage d'un outil propriétaire". À croire que vraiment, c'est une remarque outrancière et illégitime (alors qu'on n'hésite pas d'un autre côté à encourager les gens à migrer de SVN à git/hg/darcs par exemple).

L'essentiel, c'est d'utiliser git, non? Du moment que je reste propriétaire de mes données, je ne vois pas quel est le problème. Si demain github change ses termes et qu'ils ne me conviennent plus, je peux changer dans la minute. Ça me suffit.

Oui et non :

• En publiant publiquement un lien qui pointe directement vers github pour ton projet, tu soutiens implicitement la plateforme et encourage les gens à s'en servir. C'est comme de la pub, plus on voit github mieux on s'en souvient et incline à le choisir soi-même, sauf qu'en plus ce n'est pas une pub commerciale, c'est de la diffusion par des collègues techniciens, donc dignes de confiance sur leurs choix d'outils. Ces plateformes jouant sur l'effet de réseau, si l'année prochaine tu te rends compte que github ne te convient plus, tu pourras migrer ton projet mais inciteras-tu les dix autres projets que tu as inspirés à migrer avec toi ?

• Github ce n'est pas une simple URL d'un repo git, c'est une panoplie d'outils et de documents annexes. Quand dans 3 ans tu seras habitué à leur interface, tu auras toute ta doc dans leurs wiki et des dizaines de billets dans le "Issue Tracker"¹, le coût d'une migration sera beaucoup plus élevé et tu seras un utilisateur captif.

• Si comme tu le dis il n'y a aucune différence et tu peux migrer quand tu veux, pourquoi ne pas le faire dès maintenant ? Comme Git est décentralisé, tu peux même conserver un repo github et le synchroniser avec les autres régulièrement. La question est plus de choisir quelle page tu soutiens comme "page principale du projet", et quel outil d'hébergement tu promeus auprès de tes utilisateurs.

¹: si les gens mettent leurs données dans ce wiki et cet issue tracker, c'est aussi parce que ce sont de bons outils. Personne ne le nie, github est une plateforme agréable dont les développeurs font du bon travail (ils rétribuent même une partie de leur développement au libre, d'ailleurs). Ça reste une plateforme propriétaire et je pense que le choix (qui pourrait légitimement être justifié par des raisons techniques) devrait être décidé plus rigoureusement que "boarf j'ai choisi ça au hasard".