gasche a écrit 1151 commentaires

Ton post est tout à fait fidèle à l'idée de ma remarque sur le filtrage : c'est ce que je veux dire.

Dans les détails, moi je ne réclame pas ton "troisième comportement" (qui me semble moins bien que les deux premiers; il faudrait au moins afficher un warning) mais plutôt avoir le choix entre le premier et le second, comme fait Reia.

Par contre, il y a quelque chose d'important que j'ai aussi essayé de faire passer, c'est que les deux premiers comportements ne sont pas symétriques. C'est mieux d'avoir les deux mais, si on choisit l'un des deux, il vaut mieux choisir le premier. Choisir le second et l'imposer est un grave défaut, mais choisir le premier et ne pas permettre le second est une limitation relativement négligeable.

En effet, les deux langages considérés possèdent la possibilité d'ajouter une "garde" au filtrage. Le comportement du pattern `{X, X}` de Erlang peut facilement se réécrire en `{X, Y} ... when X == Y`. C'est moins joli, un peu plus pénible à lire et à écrire, mais c'est une modification locale : elle n'affecte que le motif, et pas le reste du code. Elle est par ailleurs plus fine puisqu'elle permet de spécifier l'égalité souhaitée (sachant qu'il n'existe en généralité pas d'égalité canonique qu'on puisse choisir naturellement et dont le comportement soit satisfaisant dans tous les cas).
Dans l'autre sens (si on ne propose que le deuxième comportement), la modification à faire pour obtenir le premier comportement est globale : il faut regarder l'ensemble de l'environnement de la fonction pour choisir des noms convenable. Une modification locale est plus coûteuse (en temps, en réflexion, en mémoire mobilisée chez le programmeur, en risque de bugs, en travail de maintenance...) donc avoir seulement ce comportement est un problème.

Heureusement, comme l'a souligné Jerome Herman, le style idiomatique Erlang encourage les fonctions plutôt courtes, qui contiennent peu de déclarations locales. La portée de l'environnement à considérer quand on analyse un motif reste donc raisonnable en pratique. Mais il n'empêche que ça reste un problème global (à l'ensemble d'une déclaration toplevel) et non local, et qu'on a donc un exemple concret où la syntaxe *gène* la sémantique.

Je ne sais pas exactement ce que tu veux dire par "ne pas supporter l'UTF-8", mais on peut bien sûr manipuler des chaînes UTF-8 avec OCaml, il y a d'ailleurs une bibliothèque logicielle spécialisée pour cela, Camomile : http://camomile.sourceforge.net/

Ce qui est vrai, c'est que le type "string" continue à considérer qu'il manipule des tableaux d'octets. Ça n'empêche pas de manipuler des chaînes UTF8 en utilisant le type string (plutôt que les types spécialisés de Camomile, repris par la bibliothèque Batteries), mais du coup certaines fonctions ne marchent pas tout à fait comme on veut, par exemple String.length renverra le nombre d'octets et non pas le nombre de caractères. On fait largement avec.

Enfin, certaines bibliothèques ou outils n'ont pas pris en compte les questions liées à UTF8. Par exemple il me semble que le générateur de lexeurs standard, ocamllex, ne gère pas bien les entrée UTF-8. Mais il existe un lexeur pensé pour ça, ulex.

Bref, le support d'UTF8 dans OCaml est satisfaisant, dans le sens où bien qu'UTF-8 ne fasse pas partie de la spécification du langage ou des types built-in, on peut tout à fait travailler sur de l'UTF-8 et ça marche très bien.
Si tu veux faire du "bête traitement de texte" où la fatigue liée à l'utilisation d'une bibliothèque spécialisée surpasse la difficulté de la tâche à effectuer au départ, ce n'est pas une bonne idée. Mais si tu veux faire des opérations et manipulations un peu compliquées sur tes données, et que la question de l'encodage n'est au final qu'un détail, il n'y a pas de raison de se gêner.

(D'ailleurs beaucoup d'outils de linguistique computationnelle sont développés en OCaml)

Je ne comprends pas ta remarque. Oui, les patterns Erlang font du pattern matching. Ce que je dis c'est que dans un patten, les *variables*, quand elles existent déjà dans l'environnement, matchent leur entrée si et seulement si l'entrée fournie est égale à leur variable dans l'environnement.

On peut ainsi définir l'égalité ainsi :
Eq = fun(X,Y) ->
  case Y of
    X -> true;
    _ -> false
  end
end.

Ça marche aussi quand les variables sont déjà définies par le pattern :
Eq2 = fun(X,Y) ->
  case {X,Y} of
    {Z,Z} -> true;
    _ -> false
  end
end.


(Je pense que tu le sais et que notre incompréhension est juste due à une question de formulation, mais histoire de mettre les choses à plat : )
Un motif fait à la fois un "filtrage" (j'accepte certaines entrées et j'en rejette d'autres), et a un effet sur l'environnement (si j'accepte, j'enrichis l'environnement avec de nouvelles variables liées). La sémantique du motif qui n'est qu'une variable (les motifs plus compliqués comme ceux sur les tuples étant défini par composition des sémantiques des sous-motifs qui les composent) est :
- si la variable n'existe pas dans l'environnement, accepter toujours et enrichir l'environnement avec un lien (variable -> entrée)
- si la variable existe déjà dans l'environnement, accepter seulement si l'entrée est égale à sa valeur dans l'environnement, et ne pas enrichir l'environnement

Plutôt que de produire un exemple artificiel, je suis allé chercher du code dans la documentation officielle : http://www.erlang.org/examples/examples-2.0.html

    server_loop(Name, Data, Fun) ->
        receive
            {rpc, Pid, Q} ->
                case (catch Fun(Q, Data)) of
                    {'EXIT', Why} ->
                        Pid ! {Name, exit, Why},
                        server_loop(Name, Data, Fun);
                    {Reply, Data1} ->
                        Pid ! {Name, Reply},
                        server_loop(Name, Data1, Fun)
                end;
            {cast, Pid, Q} ->
                case (catch Fun(Q, Data)) of
                    {'EXIT', Why} ->
                        exit(Pid, Why),
                        server_loop(Name, Data, Fun);
                    Data1 ->
                        server_loop(Name, Data1, Fun)
                end;
            {eval, Fun1} ->
                server_loop(Name, Data, Fun1)
        end.


La partie intéressante est "{Reply, Data1}" : pourquoi appeler cette variable Data1 ? Parce que le nom Data est "déjà pris". Si on mettait Data ici, le code deviendrait complètement faux. Pour choisir le nom à mettre dans le motif, on a du faire une opération non-locale : regarder l'ensemble des noms existants dans l'environnement. Si on coupe-colle le "case (catch Fun(Q, Data) .. end) à un autre endroit il faut faire bien attention de vérifier que les variables Why, Reply et Data1 ne sont pas déjà dans la portée de l'endroit où on les ajoute.

Encore une fois, le comportement "variable existante = test d'égalité" de Erlang est parfois bien pratique (si on sait définir l'égalité). Le problème c'est qu'il soit imposé (pour de simples raisons syntaxiques), qu'on ne puisse pas choisir un comportement local plus prédictible quand c'est plus adapté.

Ce que tu dis est difficilement compréhensible.

« La logique Erlang va vraiement à l'encontre de fonctions locales telles que tu les souhaites. Chaque morceau doit être patchable à chaud, distribuable etc. »
J'ai l'impression qu'il n'y a aucun rapport. On peut définir localement des fonctions, je veux définir des fonctions locales récursives, c'est tout, c'est totalement indépendant de la question de la modification à chaud du code (qui se fait à un niveau plus grossier, comme la déclaration toplevel, le module, etc.).

« Non, tu ne peux pas parceque F n'est pas une fonction locale au sens langage C du terme, mais un etat. F(N-1) ne veut rien dire, puisque F(N) a déjà été appelé et que l'état a déjà été assigné. C'est pour çà que le compilo te jette. »
Qu'est-ce que c'est que cette histoire ? Une fonction locale définie avec "fun" peut bien-sûr être appelée plusieurs fois, par exemple quand on la passe à la fonction "map" qui l'applique à tous les éléments d'une liste. Je ne comprends pas ce que tu essaies de dire.

Pris d'un doute, je suis allé consulter la spécification Erlang de 1999 (qui est vieille, d'accord) et la sémantique de Core Erlang publiée en 2004, et les deux ne mentionnent aucune bizarrerie de ce genre : une fonction locale est décrite comme une fermeture classique, qui capture son environnement, et qu'on peut ensuite appliquer comme une fonction globale.
D'ailleurs Core Erlang contient une construction pour les déclarations récursives locales (letrec)... Ce qui tend à confirmer que c'est bien juste un problème de syntaxe, et que conceptuellement c'est tout à fait possible.

Enfin je suis tombé sur cette discussion de la mailing-list Erlang, datant de 2000 : Do we need a letrec construct ? : http://www.erlang.org/pipermail/erlang-questions/2000-Octobe(...)
I think a variant of letrec could be useful in many cases where one wants
local functions, not cluttering the module-level namespace, even if the
problem does not involve tricky recursion like in your example (and it is
not difficult to handle letrec in the compiler, as long as only function
definitions are allowed).

« La méthode la plus simple est d'utiliser le keyword apply sur une fonction d'un module extérieur. »
Oui... précisément il faut passer par une fonction non-locale définie au toplevel d'un module. Moi je voudrais faire ça en local (il n'y a pas de raison...).

D'accord mais c'est quoi Urbi au juste ?

Ton argumentation me rend perplexe. J'ai l'impression que tu dis qu'Erlang n'est pas un langage fonctionnel, puisqu'il ne permet pas de créer des fonctions locales, et que la syntaxe "fun" est juste du sucre syntaxique proche d'une fonction pour autre chose de moins expressif (moins expressif puisqu'on n'envisage pas d'y ajouter la récursion).
Dans ce cas, Erlang n'est pas satisfaisant du tout en tant que langage fonctionnel (un langage fonctionnel sans fonctions locales, c'est presque de la publicité mensongère).

En même temps, ton discours "tu peux l'utiliser où tu veux dans ton code, le passer en paramètre ..." est exactement celui que l'on utilise pour décrire des fonctions de première classe. Des fonctions quoi.

Ensuite tu dis que de toute façon, ces trucs là sont très peu utilisés en Erlang, ce n'est pas idiomatique de s'en servir. Très bien (tant mieux pour vous les programmeurs Erlang, qui n'êtes pas dérangé par cette limitation), mais peut-être que si la syntaxe était mieux pensée sur ce point, les gens pourraient s'en servir de temps en temps.

Je ne sais pas quel est le problème que tu cherches à résoudre.

Un exemple serait plus parlant. Imagine que j'ai une fonction Erlang un peu grosse, qui définit une fonction locale (parce que cette fonction utilise des variables définies plus haut dans le bloc, et qu'elle n'a de sens que dans ce contexte donc polluerait inutilement le niveau global).

(Désolé pour l'indentation, je ne sais pas comment faire simplement avec le markup LinuxFR)

truc(args) ->
...
F = fun(N) ->
N * (N + 1) / 2
end,
...

Maintenant il se trouve que ma spécification change un peu, et j'ai besoin d'utiliser non pas (1 + 2 + .. + n) mais (1 * 2 * .. * n). J'ai envie d'écrire :


truc(args) ->
...
F = fun(N) ->
if
N > 1 -> N * F(N-1)
true -> 1
end
end,
...

Mais je ne peux pas, car `F` n'est pas définie dans le corps de la fonction.

J'aimerais avoir une syntaxe pour faire ça, par exemple :

F = fix Fac(N) ->
if
N > 1 -> N * Fac(N-1)
true -> 1
end
end


Oups : ce long post est une réponse à la question suivante :

Quant à ce que tu appelles les patterns linéaires, peux-tu indiquer des langages qui les permettent et éventuellement à quoi cela ressemble ?

Dans de nombreux langages avec pattern matching, les patterns doivent respecter la restriction de linéarité, qui dit qu'une variable ne peut apparaître qu'une seule fois par pattern. En effet, la sémantique d'une variable dans un pattern est "accepte n'importe quelle entrée et, dans la clause de filtrage, je pourrai utiliser cette variable comme nom sur l'entrée filtrée". Par exemple en caml dans `fun (x, y) -> x + y`, `(x,y)` est un motif qui accepte un couple, et donne le nom "x" au premier composant du couple, et "y" au second. `fun (x,x) -> x` n'a pas de sens (puisqu'il faudrait donner le même nom à deux valeurs différentes) et est rejeté par le compilateur.

Il y a des langages qui autorisent le filtrage non-linéaire, où une variable apparaît plusieurs fois, et dans ce cas la sémantique est "accepte cette clause de filtrage si les différentes valeurs liées par la variable sont égales". Par exemple le pattern `(x, x)` n'accepterait que les couples dont les deux composants sont égaux. Cette approche a en particulier été popularisée par Prolog qui l'utilise comme une des base de la programmation (parce qu'en prolog il n'y a pas vraiment de "motifs" et de "résultat", les variables sont au même niveau et unifiées entre elles). C'est assez naturel, le problème c'est que dans un langage fonctionnel il n'y a pas forcément de notion canonique d'égalité qu'on puisse utiliser (qu'est-ce que ça veut dire, que deux fonctions sont égales ?).

Erlang, comme prolog, utilise une forme de filtrage encore plus étendue : le test d'égalité se fait quand la variable est déjà liée dans le motif courant, mais aussi quand elle est déjà liée dans l'environnement : si tu rencontres la variable X dans un motif, la signification du motif dépend de si la variable X n'existe pas déjà dans le programme (alors elle est fraîche et on la lie), ou de si la variable X est déclarée et que le motif est dans sa portée (alors c'est un test d'égalité).

En pratique cela veut dire que quand tu vois un motif en Erlang, tu ne peux pas connaître sa signification sans lire tout le code "au dessus" pour repérer toutes les déclarations de variable, et savoir si les variables du motif sont déjà dans l'environnement ou non. En particulier, si tu coupes-colle du code d'une fonction à une autre, ton code a des risques de devenir complètement faux pour des raisons subtiles qui sont difficiles à repérer, et dont le compilateur ne pourra pas t'avertir.

Ce comportement (que j'appelle non-linéaire) est utile et expressif. Mais parfois, ce n'est pas le comportement qu'on veut : on veut dire "je ne veux pas savoir si X existe déjà ou non, donne le nom X à cette nouvelle variable et oublie l'ancienne le cas échéant". C'est utile, ça aide le raisonnement local, bref on en a besoin. Et Erlang ne le propose pas (sauf dans le cas de la syntaxe "fun (motif) -> expression end"), ce qui est un défaut. Reia propose deux syntaxes, une pour les filtrages non-linéaires d'Erlang, et une pour les filtrages linéaires (il me semble que c'est "*X". À vérifier).

Attention ! En Erlang fun n'est pas une fonction mais un état fonctionnel. C'est à dire un objet avec du code, des valeurs et à peu prêt tout ce qu'on veut dedans (y compris si on le souhaite des fonctions récursives).

Ton argumentation n'est pas bonne. Tu nous donnes des détails sur les choix de représentation par Erlang des fonctions locales (bien sûr, dans tous les langages les fonctions locales sont représentées par des fermetures, c'est à dire quelque chose avec du code, des valeurs issues de l'environnement, etc.).

Mais ça m'est égal, moi, la façon dont Erlang représente ses fonctions locales. Je peux déclarer des fonctions locales (anonymes), et j'aimerais définir des fonctions locales récursives, sans utiliser un combinateur de point fixe codé à la main qui tue les performances et limite la lisibilité.

Par ailleurs il est possible de définir la récursion sur certaines valeurs (par exemple en OCaml), et les "objets fonctionnels" semblent tout indiqués pour supporter cette fonctionnalité.

Je ne vois pas en quoi un langage non Turing-complet ne serait pas un langage de programmation. Obtenir un langage utilisable¹ qui se trouve du bon côté de la frontière de Turing, derrière laquelle c'est le chaos (on ne sait presque plus rien dire du comportement des programmes), est justement une grande victoire des types dépendants.

¹: à discuter. Mais plus utilisables que tout ce qu'on faisait avant dans le genre

Pour moi, la construction d'automates pour calculer des propriétés de mots (le modulo deux d'un nombre binaire par exemple) est aussi une forme de programmation, bien que ce ne soit pasnon plus Turing-complet.

Je suis d'accord sur le principe mais dans le cas d'Erlang, c'est en fait justifié : la syntaxe d'Erlang est *vraiment* mauvaise.

La syntaxe d'Erlang est, pour des raisons historiques, inspirée de la syntaxe de Prolog. Le problème c'est que la sémantique de l'Erlang moderne ne correspond pas du tout à celle de Prolog, et que des choses qui étaient donc très bien pour Prolog sont des problèmes pour Erlang.

D'habitude les critiques qu'on peut faire sur une syntaxe sont... purement syntaxiques (il y a une ambiguïté à tel niveau, etc..), donc fondamentalement peu importantes. Mais dans le cas d'Erlang il y a de vrais problèmes sémantiques bêtement liés à la syntaxe, comme par exemple :
- impossibilité de définir des fonctions locales récursives
- impossibilité d'avoir des patterns linéaires. L'interprétation de la clause de filtrage "X => ..." dépend donc complètement de l'environnement : si X est défini, c'est un test d'égalité, sinon c'est un motif universel. Ça rend tout raisonnement équationnel (et donc la plupart des manipulations de code) difficile.

Le deuxième point est par ailleurs corrigé par Reia, qui propose (ou proposait la dernière fois que j'ai regardé) deux syntaxes pour les patterns, une linéaire (une variable est toujours un motif universel) et une non-linéaire.

Prolog

Oz, et l'excellent livre Concept, Techniques and Models of Computer Programming.

OCaml ou SML (parce que .NET, on sait pas si c'est le mal, mais on se doute bien qu'un peu quand même)

Haskell (mais après avoir appris OCaml ou SML) ou éventuellement Clean

Coq ou Agda (ou Epigram) (mais après avoir appris un langage fonctionnel statiquement typé)

Forth ou Factor

un Lisp (Common Lisp ou Scheme, principalement) ou éventuellement Dylan

C ou un assembleur

Smalltalk, ou Ruby ou Python ou Javascript ou Io

Si, git sait oublier : l'historique est modifiable dont un petit "git rebase", tu vires les commit qui ne t'intéressent plus, un coup de gc, et hop disparu.

Ça devient un peu facile cette critique systématique, toujours pour la même raison, d'une chose qui ne peut pas changer du jour au lendemain mais évolue sur la durée. Si la critique était vraie il y a trois mois, elle restera vraie aujourd'hui (surtout quand on parle de statistiques sur plusieurs années), et ça n'apporte pas forcément beaucoup.

C'est bien de faire pression sur les compagnies pour qu'elles contribuent upstream, mais un bon troll devrait essayer de se renouveler au lieu de toujours revenir sur les mêmes choses.

J'ai déja joué à Postal et GTA, et je survis, merci.

La différence c'est qu'ici on a un jeu qui s'inscrit dans le créneau "mignon et rigolo", pas dans le créneau "tripes au second degré".
Du coup, le manque de tact et de politiquement correct du scénario est plus gênant, parce que c'est plutôt un jeu qu'on envisagerait de proposer à ses enfants.

De plus, dans les jeux que vous citez, ou même les FPS bêtes et méchants, il est bien clair que les créateurs du jeu n'encouragent pas les comportements des personnages du jeu. Ici il peut être plus difficile de distinguer ce qui est humoristique ou simplement considéré comme normal : contrairement au meurtre ou même au vol de voiture (ou de moto, de bus, de tank, d'hélicoptère, de cheval....), le fait de mettre une raclée à ses enfants ou sa femme dès qu'ils se montrent contrariants était considéré comme normal il n'y a pas si longtemps.

Je pense que ma gêne tient uniquement à une question de formulation (le terme "torgnole" est trop naturel dans ce contexte). Quelque chose de moins physique et qui suggère moins un père alcoolique et violent ferait très bien l'affaire dans le registre "grognon" : "je vais lui passer un savon dont il se souviendra", "il va m'entendre", "je sais qui va faire la vaisselle ce soir", "il ne va pas revoir de dessert de sitôt", etc...

Quand on suit le lien vers le site officiel on peut lire ceci :

Les bases du scénario tiennent dans ces quelques lignes :
« Seize heures et des poussières, Plee se réveille, fatigué. Il a encore rêvé de cette époque formidable pendant laquelle il arpentait le monde en compagnie de sa belle. Il plonge sa patte dans le pot de miel. Vide. Tous les pots de la maison sont vides d'ailleurs. « Encore un coup du gamin », se dit-il. « Je m'en vais te lui foutre une torgnole dont il se rappellera ».
En suivant les traces de miel laissées sur le sol, Plee rejoint l'orée de la forêt. Début du jeu. »

Donc le but du jeu semble être de retrouver le fils du héros pour lui mettre une raclée.

Je suis peut-être trop à cheval sur mes principes, mais je ne suis pas attiré par un jeu dont le but est de « foutre une torgnole » à un « gamin ». Les screenshots ont beau m'avoir rendu curieux, quand je lis ça je suis gêné et je passe à autre chose.

Voilà, c'est sans doute seulement une question de formulation, mais la façon dont est décrite le jeu sur le site officiel ne donne pas envie d'y jouer. J'écris ce commentaire ici parce que c'est dommage de s'aliéner une partie des joueurs potentiels pour cette raison, et que les développeurs n'en sont peut-être simplement pas conscient.

C'est bien de lister des services d'hébergement en ligne de répertoires, mais j'aimerais savoir lesquels sont libres : je cherche un service dont les sources sont disponibles, et qui permette la création d'instances locales si je le souhaite.

Côté git, j'utilise gitorious plutôt que github pour cette raison. J'ai regardé rapidement BitBucket, et je n'ai vu nulle part d'indication sur un éventuel code source disponible (donc j'imagine que ce n'est pas libre).

Ce n'est pas du tout basé sur des raisons pragmatiques (en local j'utilise de simple repos darcs/git/whatever, la plus value de l'hébergement en ligne c'est l'accès facile en lecture par tout le monde), mais je trouve absurde de dépendre d'un logiciel propriétaire pour diffuser ses projets libres...

Et les mauvaises nouvelles :
- c'est un unique fichier python de 6k lignes
- le parsing est fait avec des regexp

Un jour, les gens comprendront que la structure d'un document n'est pas régulière, dès qu'on ajoute quelque chose ressemblant à une indication, comme les listes dans les listes. C'est le cas en langue naturelle; après, certains formats ne le supportent pas, mais cela limite leur expressivité.

Je trouve très intéressant le fait que la nouveauté principale d'une bibliothèque importante comme cairo soit en fait destiné à combler un besoin d'ingénérie logicielle très "classique", la possibilité de rejouer facilement et de façon déterministe une série d'action, en passant le moins possible par le frontend de la bibliothèque.
C'est directement lié à la séparation d'interfaces modulaires, et par exemple à la pratique des "mock objects" pour le test d'applications orientées objet.

Pour résumer, ton argumentation est « Bien que la syntaxe acceptée soit un sous-ensemble du langage naturel, elle obéit à des règles strictes comme dans tous les autres langages. »

C'est vrai, mais il y a deux "Mais".

Mais, d'une part, une partie des réactions des gens vient visiblement du fait que la syntaxe stricte, sur certains points, est mal spécifiée et n'est pas rigoureusement décrite de façon exhaustive quelque part. On peut considérer que c'est indépendant de la question des langages naturels (d'ailleurs il y a d'autres langages de programmation mal spécifiés et définis), mais le risque c'est que l'aspect "naturel" justement laisse penser qu'il est facile de découvrir soi-même la syntaxe en s'exprimant naturellement, et qu'une spécification rigoureuse n'est donc pas forcément nécessaire.


Mais, d'autre part, le fait d'utiliser un sous-ensemble de la langue naturelle encourage les gens à programmer dans ce langage comme ils parlent dans leur langue naturelle. Comme une langue naturelle est très tolérante (ou plutôt, les interlocuteurs sont très tolérants) à des petits changements qui préservent le sens global de la phrase, on s'attend à ce que ce langage fonctionne de la même façon. Du coup, le programmeur aura un peu plus tendance à se laisser aller, et sera donc plus souvent contrarié par des erreurs.

Je peux présenter ça d'une autre manière : quand on met en avant le rapprochement de la langue naturelle et du langage utilisé pour les programme Inform, on se dit : « c'est chouette, maintenant mes programmes vont être en langue naturelle, donc avec un aspect plus littéraire, plus fluide et agréable à lire, et plus proche de l'interaction qu'ils auront avec l'utilisateur ». C'est le point de vue de la personne qui va lire le code. Maintenant, une personne qui écrit du code, il faut qu'elle continue à se dire « attention, c'est un langage avec une grammaire stricte, il faut que je sois précis et rigoureux, et que j'agence mes mots exactement comme il faut. ». Mais comme la plupart des gens lisent le programme en même temps qu'ils l'écrivent, et ont des boucles d'interaction lecture-écriture-lecture complexes où ce qui est (re)lu influence ce qui va être écrit, la superposition des deux états esprits ne marche pas forcément très bien, et donne lieu à des expériences frustrantes.

Si, c'est ce qui est fait par [PAWS], un des autres systèmes de la page qui les recense.

[PAWS] http://www.firthworks.com/roger/cloak/paws/index.html

J'ai regardé tous les systèmes principaux et secondaires, et Inform 7 est celui qui m'a le plus plu. Les autres ressemblent à des versions mal conçues de langages de programmation déjà existant, avec du sucre syntaxique déjà ajouté par dessus.

Au contraire, Inform 7 a une approche vraiment orignale, basée sur un rapprochement entre le code du système et la langue naturel (ce qui est nettement plus osé que les autres où c'est le joueur qui utilise la langue naturelle, et pas le développeur). Ça a de nombreux défauts (« guess the syntax ») mais c'est une expérience intéressante.

Je suis resté un peu sur ma faim après avoir regardé des descriptions d'Inform 7 (favardin > je l'ai d'ailleurs découvert dans ton tuto), mais il se trouve que mon site préféré au sujet des langages de programmation, Lambda The Ultimate, lui a dédié une [dépêche/discussion], que j'ai trouvé très intéressante.

Inform 7: A relational DSL for interactive fiction with natural language syntax : http://lambda-the-ultimate.org/node/1554

C'est pas exactement dans "ta distribution", mais moi j'attends avec impatience la nouvelle dépêche Linux de patrick_g !

11.
> systemd supports several kinds of dependencies between
> units. After/Before can be used to fix the ordering how units are
> activated. It is completely orthogonal to Requires and Wants, which
> express a positive requirement dependency, either mandatory, or
> optional. Then, there is Conflicts which expresses a negative
> requirement dependency. Finally, there are three further, less used
> dependency types.

12.
> systemd has a minimal transaction system. Meaning: if a unit is
> requested to start up or shut down we will add it and all its
> dependencies to a temporary transaction. Then, we will verify if the
> transaction is consistent (i.e. whether the ordering via After/Before
> of all units is cycle-free). If it is not, systemd will try to fix it
> up, and removes non-essential jobs from the transaction that might
> remove the loop. Also, systemd tries to suppress non-essential jobs in
> the transaction that would stop a running service. Non-essential jobs
> are those which the original request did not directly include but
> which where pulled in by Wants type of dependencies. Finally we check
> whether the jobs of the transaction contradict jobs that have already
> been queued, and optionally the transaction is aborted then. If all
> worked out and the transaction is consistent and minimized in its
> impact it is merged with all already outstanding jobs and added to the
> run queue. Effectively this means that before executing a requested
> operation, we will verify that it makes sense, fixing it if possible,
> and only failing if it really cannot work.

Ça va faire un sujet de recherche de plus pour les gens de MANCOOSI.

La phrase que tu cites ne me paraît pas méprisante vis-à-vis des "non techniciens". On peut dire que les gens dont ce n'est pas le domaine d'intérêt n'ont pas le temps ou l'envie de s'intéresser à ces questions.

Si quelqu'un a envie (pour son travail, son plaisir, etc.) de voir une vidéo sur internet, il est normal qu'elle ne s'intéresse pas forcément aux détails éthico-techniques qui entourent cette action, et qu'elle n'ait pas envie de passer du temps pour se forcer à se plonger dans ces détails, au lieu de voir sa vidéo.

Certaines personnes plus curieuses sont prêtes à écouter une explication à ce sujet à un moment où elles ne sont pas occupées, mais ça ne fait pas du reste des gens des "cons" ou des "imbéciles", juste des gens occupés à autre chose.