anaseto a écrit 2229 commentaires

Ce n'est pas mon impression, je ne sais pas où tu as lu ça. Mon impression, c'est qu'ils ne mettent pas la priorité sur la théorie des types, qui n'est qu'une branche parmi d'autres en théorie des langages (juste un peu à la mode sur reddit et quelques forums, en partie grâce à Rust).

Un langage à la pointe en théorie des types fera des sacrifices ailleurs : les chercheurs ne visent pas à faire un langage pour le rendre le plus productif possible, ils visent à faire un langage qui développe leur théorie (des types ou des langages extensibles ou autre). Tout prendre (types évolués + macros + performant + simple etc.) n'est a priori pas plus raisonnable (ni possible) d'un point de vue design de langage pratique.

Héhé, non, je parlais pas des regexps :-)

Bah si. Tu peux le faire en java. L'introspection te permet ça.

C'est différent : l'introspection apporte de l'expressivité en plus au langage (au sens des choses qu'il n'est pas possible de faire sans).

Le filtrage par motif est une syntaxe déclarative pour écrire plus facilement certains types de code. Par exemple :

match l with
| [] -> (* faire des trucs si la liste l est vide *)
| (Some ((Some x) :: [])) :: l' -> (* faire un truc spécial si le premier élément est un type option qui contient une liste avec un seul élément qui lui même contient un élément x *)
| x :: [] -> (* dans les autres cas, si la liste n'a qu'un seul élément x *)
| x :: y :: l' -> (* faire des trucs avec les deux premiers éléments x et y s'il y a au moins deux éléments dans la liste *)

Une version plus impérative ferait plutôt quelque chose comme :

if len(l) == 0 {
    // faire des trucs si la liste l est vide
    return
}
a := l[0]
if a != nil {
   if len(*a) == 1 {
      x := (*a)[0]
      if x != nil {
          // faire un truc spécial si le premier élément est un type
          // option qui contient une liste avec un seul élément
          // qui lui même contient un élément x
          return
      }
   }
}
if len(l) == 1 {
   x := l[0]
   // dans les autres cas, si la liste n'a qu'un seul élément x
   return
}
x, y := l[0], l[1]
// faire des trucs avec les deux premiers éléments x et y s'il y a au moins deux éléments dans la liste

Après, c'est très tiré par les cheveux, c'est rare d'avoir à destructurer en profondeur juste un cas très particulier et pouvoir gérer tout le reste de façon homogène. En pratique, la différence en verbosité est moindre.

Le filtrage par motif, c'est le nom en français du pattern matching. Ça permet de déconstruire des structures et lier des variables de façon plus déclarative, par exemple écrire un motif pour les listes qui ont au moins trois éléments et donner dans la foulée un nom à ces trois premiers éléments.

C'est sympa, particulièrement dans les langages fonctionnels. Mais ça reste au final essentiellement juste du sucre syntaxique (récursif). Quand je programme dans un langage impératif, j'en ressens pas vraiment le besoin. Si ça ne s'intègre pas naturellement dans le langage, ça ne vaut pas le coup d'introduire de nouvelles syntaxes juste pour ça, à mon avis.

Il a un GC, il existe des techniques de programmation qui font qu'il est tout simplement plus nécessaire d'en avoir un dorénavant.

Utiliser des clôtures ou des structures de données cycliques est très pénible sans GC. Pour les structures, le besoin n'est pas forcément fréquent, mais les clôtures, j'en utilise souvent.

Il supporte les pointeurs du style void * comme en C.

Il n'y a pas de pointeurs du style void * comme en C, non. Ce qu'il y a, c'est un type interface particulier qui peut être utilisé comme une version restreinte et plus explicite du concept de variable en Python ou autres langages dynamiques. C'est très différent. Ça représente rarement une portion significative du code et, même lorsque c'est utilisé, c'est le plus souvent à l'aide de type-switchs qui ne peuvent pas provoquer d'erreurs au runtime.

Les développeurs laissent pourrir des problèmes et n'écoutent pas la communauté.

Chose qui peut s'appliquer à n'importe quel gros projet : impossible de satisfaire tous les utilisateurs. Il y en aura toujours pour se sentir oubliés parce qu'ils n'ont pas écoutés, mais ils oublient souvent que leurs besoins sont en conflits avec ceux d'autres utilisateurs, ou simplement non prioritaires. Par exemple, les utilisateurs de Rust et C++ qui aiment la compilation rapide pourraient se sentir oubliés. Leurs préférences sont juste en conflit avec celles d'autres utilisateurs du langage.

Go est écrit en Go, ce qui rend sa compilation sur des nouvelles plateformes pénible. C'est dingue cette obsession de développer quelque chose puis d'en faire un logiciel self-hosted.

C'est un désavantage en partie, mais bon, tu as gccgo aussi. Personnellement, je trouve que les avantages compensent largement les inconvénients : c'est un compilateur facile à maintenir par n'importe quel utilisateur du langage et qui compile en à peine une minute sur de vieilles machines (bref, ça m'est techniquement accessible, contrairement au compilateur Rust, par exemple).

Celles que j'ai citées sont celles qui me feront jamais utiliser ce langage.

C'est l'impression que tu donnes en effet, celle de n'avoir jamais utilisé ce langage, mais d'être capable de le juger comme « inutile » sur la base d'une compréhension qui n'est pas basée sur un apprentissage du langage. C'est courant comme chose à faire mais, perso, je ne comprends pas.

Et puis, personnellement, si je devais me faire une idée sur un langage que je ne connais pas, je serais méfiant de m'appuyer sur des arguments techniques sortis de contexte et peut-être mal compris. Surtout pour un langage qui est quand même utilisé pour faire plein de choses. L'argument d'autorité n'est pas fiable en lui-même, mais dis-toi quand même que Go est utilisé avec satisfaction par plein de monde, pas forcément que des ignorants, et ses propres créateurs ont un bon bagage dans le domaine. De quoi se dire qu'un jugement rapide risque fortement d'être incorrect.

Perso, d'expérience, avec les langages de programmations, il y a deux types de personnes qui les détestent : ceux qui ne les ont pas utilisé, mais ont des préjugés basés sur leurs préférences dans des contextes qui ne s'appliquent pas ; et ceux qui ont été forcés de les utiliser dans un projet mal bâti.

C'est le même qu'en C, il permet de faire un saut local. Il n'est pas possible de faire un « long » saut de fonction à fonction comme setjmp et il n'est pas possible de stocker des labels de goto non plus.

Et il n'est pas possible de faire un jump qui fait rentrer dans la portée lexicale d'une variable locale, ce qui enlève quand même une source majeure de mauvaises surprises.

Un truc qui m'a toujours semblé un peu une mauvaise idée (d'un point de vue maintenance) dans lua et que tu ne mentionnes pas, c'est le fait que les variables sont globales par défaut et qu'il faut utiliser local, plutôt que le comportement inverse (un global à la Tcl ou Python).

Les développeurs sont fortement contre l'ajout du mot clé continue, alors ils ont rajouté le terrible goto. Par contre break existe.

Le goto est une version très restreinte (un peu comme en Go, c'est un goto sans vraiment l'être), donc qui évite les cas vraiment problématiques qui lui valent une mauvaise réputation, non ?

Pas d'expression régulière, mais un format maison bien plus limité.

Pour le coup, ça c'est assez compréhensible pour un langage qui se veut petit et d'extension : un moteur d'expression régulières un peu moderne représenterait probablement autant de code que le reste de l'interpréteur, et un moteur trop simpliste donnerait de mauvaises performances.

Ça a aussi l'avantage d'être plus facile à apprendre que les regexps, plus clair dans les cas simples. Un des objectifs de lua est d'être facilement modifiable par des personnes avec peu d'expérience en programmation.

J'ai vérifié, tu as raison pour l'AoT, visiblement ça ne compile simplement pas pour les programmes qui n'utilisent pas le bon sous-ensemble du langage ; du moins, le site de graal dit que dans ce cas, ça utilise une image fallback qui fait appel à la JVM, je sais pas si c'est uniquement du byte code, mais probablement.

Je me demande du coup si les deux projets graal partagent vraiment beaucoup de code, ou surtout le nom, vu comment la représentation interne de programmes de graal (version normale avec JIT) est justement particulièrement conçue à la base pour le JIT et la gestion simultanée de parties compilées et byte code interprété.

C'est une façon de voir les choses. Par contre je ne sais pas ce qui est plus complexe entre interpréter un byte-code et compiler un byte-code vers du natif et exécuter ce natif (ce que font les JIT).

Les JIT font souvent les deux : ils analysent les bouts de bytecode fréquemment exécutés et les compilent, tout en interprétant les bouts de bytecode moins fréquents. Autrement le temps de compilation pourrait devenir trop long.

La version native essaie d'apporter plus de compilation que celle que peut raisonnablement faire le JIT sans trop impiéter sur le temps de démarrage. Elle ne compile a priori pas tout pour autant non plus, tout n'étant pas compilable en natif statiquement en Java (en tous cas, c'était ainsi la dernière fois que j'ai lu des trucs sur GraalVM), donc il reste des bouts de bytecode qui sont interprétés et potentiellement même compilés JIT à l'exécution si estimé rentable (si l'analyse de performances est activé dans les options).

Bref, c'est une machinerie bien complexe.

J'aurais plus mis en cause la machine virtuelle que le compilateur perso.

La machine virtuelle fait du JIT, donc combine le gros de la complexité d'un compilateur et celui d'une machine virtuelle traditionnelle (genre Perl), mais en pire (il y a des processus de décision assez complexes pour décider quoi compiler en natif à la volée et quand ce n'est pas possible ou non rentable).

Pour la compilation native, je connais pas bien les détails, mais j'imagine que ça met un sous-ensemble de la JVM (a priori plus simple) et le programme dans un même exécutable.

C'est vrai que firejail est assez simple d'utilisation pour les logiciels pré-configurés, même si la technologie derrière est plus complexe (un niveau d'indirection en plus, puisqu'il faut un processus pour en surveiller un autre). Cela dit, à ma connaissance, aucune distribution (du moins connue) ne remplace par défaut firefox par firejail firefox.

En même temps, il parle de briques bas niveau, pour lesquelles Java n'est pas utilisable.

Cela dit, pour le bas niveau, Rust fait beaucoup d'usage d'unsafe (inévitable), ce qui réduit quand même beaucoup ses garanties. Quand on compare Rust et C pour une application haut-niveau, Rust est un clair gagnant, mais alors Java ou Go est souvent possible aussi, sauf besoins en performance particuliers. Pour du très bas niveau, l'intérêt de Rust est paradoxalement moins impressionnant, je trouve.

Après, il y a aussi la question des bugs dans le compilo. Par exemple, Java utilise un JIT, et un particulièrement complexe, donc le potentiel de bugs problématiques dans le compilo qui conduisent à des problèmes de sécurité est a priori non négligeable. Rust a un compilateur assez complexe aussi, malgré l'absence de JIT, donc le risque n'est pas exclu non plus.

Le soucis un peu, c'est que les méthodes de mitigation sous Linux ne sont pas très simples, donc non activées par défaut.

Après, l'article est exagéré pour une utilisation desktop typique (au sens, typique pour un windosien auquel on compare) : souvent le seul logiciel qui communique avec des méchants probables est le navigateur (beaucoup l'utilisent même pour le mail), donc en termes de mitigations, ce qui est vraiment prioritaire, c'est d'empêcher le navigateur de pouvoir faire trop de choses.

Sous OpenBSD, avec unveil on s'assure que le navigateur ne peut accéder qu'à ~/Downloads et son cache, ce qui limite pas mal les dégâts, et pledge évite de donner accès à trop d'appels systèmes. Avec Linux, on n'a pas de moyen super simple de faire pareil. Un truc facile quand même, c'est de lancer le navigateur avec un autre utilisateur qui ne peut pas lire le home de l'utilisateur principal (je fais ça lorsque j'utilise Linux, c'est mieux que rien et ça coûte pas cher).

Hm, j'imagine que la différence avec Go, c'est que tous les gros sont dedans et pas qu'un seul ;-) Après, quel compilateur mainstream est vraiment communautaire de nos jours ? LLVM l'est déjà pas non plus et même GCC ne l'est peut-être plus vraiment.

Perso, ce qui me semble important, c'est la facilité pour forker au besoin. Par exemple, je sais être capable de compiler les sources du compilateur Go sur ma vieille machine en à peine une minute, je l'ai fait plusieurs fois. C'est un truc qui me rassure sur le fait qu'au besoin, je pourrais faire des choses avec (après maintenir une telle base de code dans le long terme, ce serait une autre histoire).

pas commun à tous ceux qui font du libre.

L'aspect sociétal n'est en effet pas commun à tous ceux qui font du libre, d'où l'existence d'au moins deux mouvements parmi les gens qui font du libre.

Le truc intéressant, c'est que j'en arrive à une conclusion assez opposée à la tienne pour une raison similaire. Ma vision (personnelle) de l'aspect sociétal, c'est que c'est dommage de s'intéresser uniquement à ceux qui font du libre, et que ce serait bien que les 4 libertés puissent se diffuser en dehors de ce cercle réduit. Bref, j'aimerais que les utilisateurs finals en général puissent disposer des 4 libertés, pas seulement une petite communauté éclairée.

Et si votre logiciel est non pas un logiciel complet (Linux, GIMP, etc.) mais une librairie, alors là, en GPL, il sera jamais utilisé par ces grosses entreprises non éthique, aucun risque de ce côté là.

Tout à fait, c'est ce que je disais : ça dépend beaucoup du logiciel, la plupart du temps faire du non-libre n'apporterait strictement rien.

Notons qu'en vrai, si ces gens veulent du code vraiment éthique en s'assurant que les grosses boîtes n'iront pas le leur prendre, ils peuvent déjà faire GPL ou mieux AGPL. 30 ans d'expérience a montré que ça marche.

Ça marche dans une communauté réduite : l'OS le plus utilisé actuellement est probablement Android, il repose sur du libre (même GPL), mais quasiment aucune des 4 libertés n'arrive à l'utilisateur final. On peut se satisfaire de pouvoir faire du libre en communauté réduite éclairée, je comprends cela et pas le choix je m'en contente aussi, mais toujours est-il que « ça marche » est très relatif.

Au contraire, leur liste bizarre de qui est considéré comme un utilisateur éthique est juste n'importe quoi (on peut tous citer des cas dans chacune des catégories où l'utilisateur sera loin d'un utilisateur "éthique", ou d'ailleurs pour reprendre le nom de la licence, on peut aussi trouver des gens avec des comportements ultra-capitalistes dans chacune des catégories citées).

Je suis d'accord, mais tu reproches à la licence la même chose qu'on peut reprocher à la GPL : c'est-à-dire qu'elle peut être contournée. La question est, dissuade-t-elle au moins les gros acteurs du privateur ? Je veux dire, à un niveau sociétal, c'est quand même la priorité : dissuader les petits méchants est peine perdue, je crois qu'on est d'accord là-dessus.

Donc nope. Cette licence, j'espère bien qu'elle n'aura jamais le moindre succès et que les gens ne tomberont pas dans ce piège.

Perso, ça m'est un peu égal, au sens, pour un simple individu, elle est moins restrictive que la GPL, relativement applicable (contrairement à la SSPL) et toujours mieux que du privateur. Après, perso, je pense que l'intérêt principal de la licence serait de dissuader les gros acteurs du privateur, c'est pas comme si celui qui l'utilise a vraiment envie ensuite d'utiliser et engraisser la machine juridique pour la faire respecter.

Tu me diras, pour ça, l'expérience semble montrer que la WTFPL, qui est libre, suffit, puisque les GAFAMs ont tendance à ne pas intégrer de code sous cette licence : plus efficace en pratique que la GPL visiblement !

P.S.: cette fois, j'arrête vraiment de répondre. Plus de commentaire, ça me prend trop de temps! Ahahah!

Héhé, tes messages sont intéressants à lire, mais c'est vrai que le résumé c'est encore moins ton truc qu'à moi ;-)

Et c'est ce qui m'amuse (en virtuel, comme dit à l'extérieur j'ai d'autres plaisirs) : demander aux gens d'assumer ce qu'ils disent, de juste nommer, ça fait déjà tellement réagir, les gens détestent regarder en face l'incohérence entre l'affiché et le réellement pensé.

Pour le coup, on a un défaut en commun ;-) J'avoue qu'une partie de moi prend un peu plaisir aussi à vouloir te demander d'assumer que tu veux imposer aux autres le raccourci « licence libre » = « le Libre » et si t'es pas d'accord tu fais de la pub, chose qui n'est faite par aucune référence sur le sujet.

Ceci dit, par contre, perso j'ai pas de soucis pour me corriger quand je me suis trompé, par exemple lorsque j'ai qualifié peu rigoureusement ta position d'utilitarisme extrême, alors que c'est plutôt un extrémisme juridique (tu privilégies la compatibilité d'une licence avec les 4 libertés), laissant de côté l'aspect sociétal (diffusion des 4 libertés en général aux utilisateurs finals).

HS par rapport au journal peut-être, mais ton commentaire parle vite-fait de pseudo-libristes et de ce que tu crois savoir qu'ils pensent :-)

Mais, ok, « utilitariste » est un peu vague, j'ai mal résumé ta pensée, mea culpa.

j'ai une vision du libre en lecture littérale de sa définition à l’extrême

J'aurais plutôt pensé une insistance extrême pour vouloir que les autres partagent l'opinion que la lecture littérale de la définition d'un logiciel libre est aussi la définition de Libre. En d'autres termes, tu fais une lecture littérale d'une définition (licence libre), tu l'appliques tel quel à des concepts liés mais a priori différents (le Libre), puis tu te surprends que les autres ne comprennent pas le raccourcis de vocabulaire que tu fais, qui sont donc des pseudo-libristes qui n'ont pas compris que le libre s'intéresse à celui qui reçoit (c'est-à-dire l'utilisateur direct, amazon ou elastic, et pas l'utilisateur final).

Bref, peut-être que l’extrême vu chez quelqu'un est démonstratif de l'incohérence des idées chez soit qu'on ne veut pas voir ;-).

Héhé, je te retourne la phrase ;-)

En fait, un bon exercice (sauf que pas facile à mettre en pratique sur le net), qui vaut pour n'importe quel désaccord, ce serait d'essayer d'écrire des messages comme l'écrirait l'autre : si j'arrive à écrire sur le libre de sorte que tu sois 100% d'accord avec, c'est que j'aurais compris ta position (et vice-versa). En gros, être capable d'expliquer les arguments de l'autre aussi bien que lui permet de se faire une idée si on maîtrise vraiment son opinion ou non (une sorte de test de Turing).

Pareil. Perso, je trouve déjà intéressant de comprendre pourquoi une personne en arrive à une croyance : ça nous en apprend sur la société. Comprendre une croyance, c'est de l'information et ça peut permettre de mieux se comprendre (à défaut d'être d'accord), contrairement à la mise en ridicule et associations par étiquette. Traiter quelqu'un de complotiste va juste le braquer, sachant qu'il a affaire à quelqu'un qui ne veut pas essayer de le comprendre, mais plutôt l'assimiler à un croyant de la terre plate.

Ça doit dépendre des milieux : perso, dans la vie réelle je croise rarement des libristes avec une vision du libre utilitariste à l'extrême comme la tienne. La plupart font une différence entre un logiciel libre et le mouvement du libre en général, sans pour autant être des extrémistes du mouvement non plus.

Je pense que sur le net les positions extrêmes ont tendance à plus se faire sentir, tant dans un sens que dans l'autre. On lit aussi beaucoup plus de défenseurs extrêmes du système pour qui les complotistes semblent être un problème surdimensionné par rapport aux choses qui ont vraiment un impact sur la société et qui créent des conditions favorables au complotisme en premier lieu. Le complotisme est souvent juste une réaction défensive contre une situation perçue comme injuste ou incompréhensible, c'est un symptôme d'un problème réel mal compris. Il n'y a pas que les cas profondément absurdes comme la terre est plate, cas qui sont malheureusement utilisés pour ridiculiser et étiqueter sans distinction toute opinion peu rigoureuse comme inutile voire dangereuse, plutôt que d'essayer d'en comprendre les origines.

Oui, il est aussi possible de capitaliser sur des free lance (des salariés jetables, quoi) : c'est plus difficile à éviter directement. Ça reste au fond la même chose : le free lance est payé pour sa valeur en tant que bien et pas pour la valeur de son travail.

A lire vite fait, elle n’empêche pas le capitalisme par le particulier

Le salariat est la caractéristique principale du capitalisme. Sans salariat, ce n'est plus du capitalisme, mais autre chose (la capitalisation ne peut se faire alors que sur des biens non humains).

Pour rappel, le salariat est une relation entre un employeur et un employé où ce dernier est, d'un point de vue du marché, considéré comme un simple bien (une machine ou ressource) que l'on achète à un prix dépendant de l'offre et la demande (le salaire). L'employeur utilise ensuite cette ressource pour produire des choses qui lui appartienne. Ça signifie que le profit de l'employeur est basé sur combien il sous-paye son employé par rapport aux fruits de son travail. C'est ce qu'on appelle l'exploitation du travail d'autrui et la critique principale du capitalisme.

Un principe de base de l'économie de marché, c'est la distinction entre la valeur d'utilisation d'un bien et sa valeur en tant qu'objet d'échange dans le marché. C'est ce qui permet de capitaliser sur un bien en l'achetant à un prix dans le marché, puis en l'utilisant pour produire de nouveaux biens qui se vendront à un prix plus élevé. Le salariat représente la capitalisation sur l'humain en tant que bien et est donc considéré une des principales faiblesses du capitalisme.

par exemple suivant un régime fiscal, une EIRL = entreprise individuelle semble acceptable et encore, mais pas EURL = entreprise unipersonnelle qui a une personne morale du point de vue légal mais appartient bien à un individu

Je voudrais que tu m'expliques ton raisonnement : s'il n'y a qu'une seule personne dans l'entreprise, la personne physique est à la fois propriétaire et employée, donc pas concernée par les restrictions de la licence. Après, je ne connais pas les détails de ce statut, peut-être qu'il réussit l'exploit de faire du salariat inégal avec une seule personne.

même le NC de Creative Commons pose des gros problèmes, en incluant des gens qu'on veut exclure par exemple une représentation gratuite dans une endroit payant et en excluant des gens qu'on veut inclure par exemple en empêchant les gens de financer l'hébergement du contenu mis à disposition

Le NC est bien plus restrictif que la licence anti-capitaliste qui ne complique pas la vie des simples individus. Le NC à un but individuel (empêcher que quiconque, même un individu ou une association avec des status égalitaires, fasse du profit avec un logiciel), alors que l'autre licence à un but sociétal (empêcher les organisations d'utiliser le logiciel pour capitaliser sur de l'humain). Là où le NC rend impossible toute forme de modèle économique autour du logiciel, la licence anti-capitaliste rend impossible seulement un modèle économique particulier.

Et ce sont les même nigauds qui maintenant nous sortent des licences "éthiques"

Tu parles beaucoup d'argent et c'est souvent le cas, je suis malheureusement d'accord qu'il y a beaucoup trop de monde (et d'artistes) qui espèrent être dans le petit pourcentage de gens qui profitent. Mais la question me semble plus compliquée dans sa généralité. Pour quelqu'un qui fait du Libre juste pour l'amour du Libre, parce qu'il pense que ses utilisateurs devraient avoir les quatre libertés, sans vision économique, il reste la question de savoir si l'utilisation d'une licence libre a, sociétalement, toujours une balance positive (même du point de vue des 4 libertés).

Pour la plupart des logiciels, comme tu le dis plus haut, peu importe qu'un rapace l'utilise, sinon il utilisera quelque chose d'autre et le résultat sera probablement le même. Mais si tu penses que ton logiciel peut devenir une pièce importante pour des gros acteurs du non libre (du type GAFAM), se pose la question suivante : est-ce que les usages directs de ton logiciel compenseront le nombre d'utilisateurs qu'il aura permis de limiter indirectement ? Parfois le calcul est évident. Gimp aura clairement eu un impact plus positif que négatif. Mais est-ce que Linux (ou une de ces bases de données) a permis plus d'utilisateurs libres que de non libres ? En absolu la réponse est probablement négative. Après, ce chiffre absolu n'est pas forcément un critère pertinent, mais disons que la balance des choses n'est pas facile à évaluer sociétalement.

Sinon, s'il fallait choisir une licence non-libre mais qui offre quand même les 4 libertés dans un maximum de cas, je pencherais plutôt pour la licence anti-capitaliste, qui est très claire sur le fait qu'elle offre les 4 libertés aux individus (mais pas à toutes les organisations), alors que la plupart des licences dites éthiques sont trop vagues et compliquées pour les simples individus.

Dans sort.pl:

local $/;
my $text = <>;
my ($start, @chapters) = split/^#(?=[^#])/m, $text;
print $start;
for (sort @chapters) {
    my ($intro, @subchapters) = split/^##(?=[^#])/m;
    print "#$intro";
    print map {"##$_"} sort @subchapters; 
}

Puis:

$ perl sort.pl file.md

Le truc qui a provoqué un rire incontrôlable de dépit chez moi, c'est l'annonce du « chèque-psy ». Je ne vois vraiment pas comment l'interpréter autrement que par « taisez-vous, le problème est dans votre tête ».

Je réagissais uniquement à tes doutes sur le côté monopolistique ou non des acteurs comme Facebook, soulignant le fait que pour décider du côté monopolistique d'une entité il faut regarder s'il a un pouvoir de marché sur ses consommateurs (et non sur ses produits).

Pour ce qui est du mot « censure », je crois déjà m'être cassé la tête dessus une fois et j'ai pas trop envie d'y réfléchir à nouveau, je laisse ça aux linguistes ;-)