kantien a écrit 1131 commentaires

Le télétravail a eu pour effet de considérablement diminuer le volume de questions idiotes par jour, et c'est dommage car j'aurais du en noter quelques unes et faire un livre de blagues :)

Un peu comme les perles du bac, ça aurait pu être marrant. :-)

Trèves de plaisanterie … je ne connais pas Ocaml mais ton explication donne envie de s'y attarder un peu pour en connaître un peu plus

J'ai jeté un œil du côté de elixir (mentionné dans un autre commentaire par un adepte de python), et ça peut être intéressant à regarder pour appréhender l'approche fonctionnelle de la programmation. Venant de python ce sera peut être moins perturbant : pas de typage statique et une syntaxe plus proche.

Néanmoins, sur leur syntaxe, ils m'ont bien fait rire sur un point (cf. chapitre sur les modules et fonctions) :

ajouter = &(&1 + &2)

# ils considérent cela comme du sucre syntaxique pour

ajouter = fn (x, y) -> x + y

Utiliser la notation de De Bruijn dans un langage généraliste, je dois dire que je n'avais jamais vu cela. :-D

Leur présentation de la notion de clôture (closure) me semble un peu étrange par rapport à ce qu'elle est réellement, mais à part cela ça peut être amusant de regarder de ce côté.

Sinon, pour ce qui est de python vs OCaml, il y a le développeur d'un gestionnaire de paquet multi-platforme (Linux, MacOS et Windows) zero install qui a fait la migration du code de python vers OCaml en 2013. Il a détaillé son expériences sur son blog dans une longue série d'articles. Au bilan on se retrouve 6 ans plus tard avec une personne qui pense que le projet est mort parce qu'il y a peu voire pas d'activité sur le dépôt de code, et l'auteur de lui répondre :

Well, this is the problem with OCaml. When 0install was written in Python, I did frequent bug-fix releases. Now it’s in OCaml, there’s no need to do that. e.g. there were 8 Python releases in 2012 vs 1 OCaml release last year. I prefer it that way, but it’s bad for the project’s metrics.

source

:-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Je ne sais pas quoi répondre. On est pas dans le même monde.

Sans doute pas dans le même, effectivement. ;-)

Il ne faut pas s'arrêter au vocabulaire que j'ai utilisé : ici je m'adresse au lectorat de linuxfr, où je partais d'une réponse à quelqu'un qui mentionnait des « ingénieurs au sens large » et des « programmeurs lambda ». Je m'attends à ce que cette population ne soit pas choquée et comprenne la notion de boucle de rétroaction.

Ceci étant mon monde n'est pas celui de l'informatique mais de la musique, qui est loin d'être composé de techniciens et d'ingénieurs, et je te garantie qu'ils comprennent ce qu'est une boucle de rétroaction : quand il y a un larsen, ils savent d'où cela vient et comment régler le problème. ;-)

Tu verrais la difficulté pour les prof de collèges pour expliquer la récursivité aux élèves…

Je ne sais pas la difficulté que rencontre les profs de collèges sur ce point mais, pour ma part, les premiers algorithmes que j'ai appris étant enfant sont hautement récursifs et totalement fonctionnels dans leurs principes, et il en est de même de tous les écoliers de France depuis des décennies. Je veux parler des algorithmes d'addition et de multiplication avec retenue, ainsi que celui de la division euclidienne (celui où l'on pose la division). Tu as peut être oublié ce que tu faisais étant enfant à l'école primaire.

Si je veux être pompeux et utiliser un concept sophistiqué, je pourrais employer, par exemple, celui de monade d'état et pourtant c'est au cœur des API REST. Si j'en crois la présentation de wikipédia :

La communication client–serveur s'effectue sans conservation de l'état de la session de communication sur le serveur entre deux requêtes successives. L'état de la session est conservé par le client et transmis à chaque nouvelle requête. Les requêtes du client contiennent donc toute l'information nécessaire pour que le serveur puisse y répondre. La visibilité des interactions entre les composants s'en retrouve améliorée puisque les requêtes sont complètes. La tolérance aux échecs est également plus grande. De plus, le fait de ne pas avoir à maintenir une connexion permanente entre le client et le serveur permet au serveur de répondre à d'autres requêtes venant d'autres clients sans saturer l'ensemble de ses ports de communication, ce qui améliore l'extensibilité du système.

source

Moi quand je lis ça, je me dis : tiens, ils travaillent dans une monade d'état.

Peut être que l'on ne comprends pas le mot simple de la même façon. Je parle de facilité d'accès et pas de simplicité algorithmique. La programmation fonctionnel permet d'obtenir des

Je voudrais bien te répondre, mais il semble que ton clavier se soit blo

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Mais il est bien plus intuitif de décrire un programme de manière impérative, il est aussi bien plus confortable d'avoir un accès direct aux effets de bords.

Parle pour toi, l'impératif rempli d'effets de bords je n'y comprends strictement rien dès que le programme devient trop gros. C'est un paradigme qui m'est totalement incompréhensible.

Autre chose manipuler des listes ne demande pas de notions particulières, là où la programmation fonctionnelle va te demander de comprendre des notions comme la reduction, fold, zip,… C'est élégant, mais c'est des notions plus sophistiquées.

Qu'est ce qu'il y a de compliqué là-dedans ? Prenons le reduce (ou fold) : c'est un peu comme une boucle de rétroaction. J'ai un système qui prend deux entrées et renvoie une sortie, je mets ma liste sur une des entrées qui sera consommée un par un, et je branche la sortie sur l'autre entrée : le système s'arrête quand il n'y plus rien à consommer dans liste.

     -------------------------
     |   _________________   |
     |   |               |   |
 --------|               |   |
                 +       |----
 --------|               |
         |_______________|

C'est le schéma du dessus le reduce : je branche ma liste dans l'entrée du bas et je renvoie la sortie dans l'entrée du haut. Pour que ça marche il faut également donner une valeur initiale à l'entrée du haut, pour le premier tour, avant qu'elle ne soit alimentée par la sortie. Coder ce composant est on ne peut plus simple :

let reduce f acc l =
  match l with
  | [] -> acc
  | hd :: tl -> reduce f (f hd acc) tl

Le composant est constitué d'un opérateur à deux entrées (le paramètre f, qui était l'addition dans mon schéma), d'un accumulateur acc qui jouera le rôle de l'entrée avec rétroaction et d'une liste l à envoyer sur la deuxième entrée.

Comment fonctionne-t-il ? C'est simple : il décompose la liste par un pattern matching. Soit la liste est vide est, dans ce cas, on renvoie ce qui a été accumulé sur la premier entrée. Soit elle ne l'est pas et, dans ce cas, elle est constitué d'une tête (son premier élément) et d'une queue (le reste de la liste). À ce moment, on donne les deux entrées acc et hd à la fonction dans notre boite (le terme f hd acc) puis on renvoie la sortie dans la première entrée et le reste de la liste tl dans la seconde entrée.

Exemple d'usage : calculer la somme d'une liste d'entiers. Pour cela, il faut mettre l'addition comme fonction dans la boîte et partir de 0, ce qui donne :

let somme liste = reduce (+) 0 liste

somme [1; 2; 3] (* qui retournera 6 *)

Ce qui demande du temps, et de l'expérience, c'est de comprendre toute la puissance du reduce et à quel point on peut faire de choses avec un tel composant, pourtant en apparence si simple.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

sincerement : (enfin si j'ai bien compris)

def ajoute(x, y):
  return x + y

ajoute(1,2)

Oui tu as bien compris le code, mais en OCaml c'est du même ordre si on vire toutes mes explications autour :

let ajouter x y = x + y

ajouter 1 2

la définition de ajouter c'est juste du sucre syntaxique pour cette définition :

let ajouter = fun x y -> x + y

(*qui est elle même du sucre syntaxique pour celle-ci *)
let ajouter = fun x -> fun y -> x + y

mais cela je peux aussi l'écrire en python :

ajouter = lambda x, y : x + y

D'ailleurs j'ai toujours trouver l'utilisation du mot clef lambda quelque peu pédant, un peu comme Haskell qui utilise \ parce que ça ressemble à la graphie du lambda dans l'alphabet grec.

Ce que je voulais signaler c'est que la programmation fonctionnelle n'a rien d'étrange ou de si compliquée : c'est fondamentalement ce que nous faisons quand on fait des phrases à trous.

Il y a deux modèles de calcul qui servent de base aux langages de programmations. Celui de Turing avec sa machine et ses instructions pour en modifier l'état qui sert de base aux paradigme impératif. Celui de son directeur de thèse, Alonzo Church, à savoir le lambda-calcul avec son système d'expression et de réécriture d'expression qui sert de base au paradigme fonctionnel.

Ce que je disais c'est que les phrases à trous sont du lambda-calcul, tout comme le calcul tel qu'on l'enseigne dans les cours de mathématiques élémentaires.

Pour bien illustrer cet aspect où tout est expression en programmation fonctionnel (c'est vrai de OCaml mais aussi de lisp, ses dériviées, Haskell, elixir…), prenons cet exemple :

let paire x = x mod 2 = 0

cette fonction teste la parité de son paramètre, elle compare à 0 le reste de la division euclidienne par 2 (x mod 2).

Avec la fonction ajouter de ci-dessus, on peut l'appeler ainsi :

ajouter (if paire 2 then 1 else 2) 2

ce qui vaut toujours 3. Ici if paire 2 then 1 else 2 est une expression comme un autre, que je peux donner en argument à ajouter car elle à le bon type. De la même façon que l'expression composée le chat de ma tante peut être passer à la phrase à trous "je regarde qqchose" car elle a la bonne catégorie grammaticale.

motifs / abstrais / beta reduction => les termes ne sont pas assez "basique" pour certains et trop théoriques.

Mon discours n'était pas destiné à des débutants, je m'interrogeais seulement sur ce qu'il y a de si compliqué à comprendre dans le paradigme fonctionnel alors que l'on fait la même chose à l'entrée du collège en cours de français (j'ai eu l'idée en faisant faire ses devoirs à une de mes nièces qui était en 6ème).

Ce qui est vrai avec OCaml, ce n'est pas que la langage soit compliqué, mais qu'une grande partie de ses utilisateurs (le milieu académique faisant de la recherche en langage de programmation) fait des choses compliquées avec : pour leur santé mentale, il n'essaieraient même pas de les faire en Python ou Go. ;-)

Si tu veux voir un programme simple, mais un peu plus évolué que les one liner de ces commentaires, tu peux regarder le journal sur taptempo en OCaml.

Pour finir, il y a un point qui m'a échappé dans ta réponse :

(* j'abstrais le patrons suivants *) => ici tu en as perdu encore … (et dans certaines entreprises les délégués syndicaux te regardent d'un sale oeil … )

Ici tu considères que j'ai en face de moi un public de développeurs ? Ils ont eu peur de quoi ? du mot abstraction ? Si c'est le cas, effectivement les délégués syndicaux ne vont pas m'aimer : là c'est direction les ressources humaines, tu prends tes affaires et pas la peine de revenir demain. :-D
C'est le métier du programmeur que de créer des abstractions. S'ils ont peur d'un mot qui constitue le cœur de leur activité, que font-ils ici ?

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

C'est l'anti-thèse de Ocaml, très beau sur le plan théorique mais en pratique, c'est trop compliqué pour le développeur lambda, pas assez performant, trop peu utilisé etc.

Il n'a jamais fait de phrase à trou dans son enfance en cours de français le développeur lambda ? Parce qu'écrire un programme en OCaml c'est le même principe. Elle est où la difficulté ?

Exemples:

• Je mange du pain
• Je bois de l'eau

de ces deux phrases, on peut abstraire un motif sous la forme :

• Je verbe de qqchose

ce motif, on peut l'appliquer soit au couple manger - pain, soit au couple boire - eau, afin d'obtenir les phrases précédentes.

Après, certes, on peut commencer à construire des phrases plus complexes, en partant par exemple de ce patron :

• je regarde qqchose

ce qui peut donner :

• je regarde la télé
• je regarde le chien du voisin

Dans le deuxième exemple, le complément d'objet est lui-même un composé dont on peut abstraire un motif. Disons, celui-ci :

• l'animal de qqu'un

qui peut être instancier sous la forme :

• le chien du voisin
• le chat de ma tante
• le poisson rouge de Nicolas

et ainsi de suite. Ensuite, en composant les patrons de phrases, on construit des phrases de plus en plus complexes (ce qui ne veut pas dire compliquée ;-).

Tu t'y prends autrement pour exprimer ta pensée de manière écrite? Le développeur lamabda, aussi, a une autre façon de procéder? Si c'est le cas, j'aimerais bien savoir laquelle.

En programmation fonctionnelle, abstraire un mot pour former un patron c'est ce qui se nomme la lambda abstraction (le mot clef fun de OCaml), puis appliquer un patron à des cas particuliers cela s'appelle l'application de fonction, et la phase qui remplace le paramètre formelle par le paramètre effectif se nomme la beta reduction (c'est-à-dire l'exécution du code).

(* j'ai les motifs suivants *)
1 + 2
2 + 3

(* j'abstrais le patrons suivants *)
fun x y -> x + y

(* je l'utilise pour retrouver les exemples du dessus *)
(fun x y -> x + y) 1 2

(* et là le runtime fait des substitutions successives ou beta reduction *)
(* on commence par susbstituer le premier paramètre x *)
(fun y -> 1 + y) 2

(*on fait pareil avec y *)
1 + 2

(* on calcule *)
3

Après le langage va rajouter des catégories grammaticales ou types pour bien vérifier que l'on utilise les patrons avec des mots ou construction conforme au règle de la grammaire, comme tout langage à typage statique. Autrement dit, dans le patron "je verbe de qqchose", il n'est pas correcte de vouloir utiliser le mot "bouchon" à la place du verbe car il n'appartient pas à la bonne catégorie grammaticale.

Qui y a-t-il de compliquer à comprendre dans tout cela ?

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

La pour le coup, le calcul me semble pas si simple. Ce cargo a un énorme avantage: il ne consomme (quasiment) pas de carburant.

Sur ce point, je dirais quand même que l'expérience reste en faveur du pétrole. Le turbovoile d'Anton Flettner fut construit au début des années 1920 et, de fait, cette technologie n'a pas du tout prise. Je crains qu'il ne faille pas compter sur cet apparent avantage économique pour espérer la voir fleurir.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Il serait pas awesome ce produit ? Genre revolutionary ?

Je crois qu'il y a méprise : ce n'est pas revolutionary mais It’s gonna be legen… wait for it… dary ! Legendary! L'awesomeness c'est totalement Stinson-proof. Par contre cela risque de ne pas être très inclusive, ce qui est à la mode en ce moment. :-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Après, je ne comprends pas ce mépris sous-jacent pour les techniciens.

Je ne crois pas qu'il y ait un quelconque mépris envers les techniciens. Il me semble que l'idée générale serait plutôt que la difficulté technique d'exécution d'une œuvre ne détermine nullement sa qualité musicale. Cela se rapproche de ce qu'exprimer Duke Ellington avec son It don't mean a thing (if it ain't got that swing).

Pour rester dans l'instrument de Van Halen, Bibi (aka Biréli Lagrène), un des virtuoses de la guitare, aurait pu mal tourner à la fin des années 80, début 90, s'il avait suivit ce courant. Heureusement, par la suite, il est revenu à la raison (petit clin d'œil à Beethoven sur la fin ;-). Ceci étant il lui arrive encore de composer des pièces qui me laisse de marbre, comme son mouvements : la partie du sax soprano se prête très bien à la tessiture et au timbre de cet instrument, en revanche je trouve qu'il gâche la pièce avec sa guitare.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Le type 'null' est toujours là. Les types de base ne sont pas des objets.

Tout ça, OK (et à mon sens le null est peut-être le plus gros problème de Java). Il y avait un projet pour se débarasser des types de base, mais ça fait longtemps que je n’en ai plus entendu parler.

C'est étrange comme projet, j'aurais plutôt eu l'idée contraire : virer les objets et n'avoir que des types comme ceux de base. :-)

Les définitions mathématiques ne peuvent jamais être fausses. En effet, comme le concept est d’abord donné par la définition, il ne contient exactement que ce que la définition veut que l’on pense par ce concept. Mais, s’il ne peut rien s’y trouver de faux quant au contenu, il peut y avoir parfois, mais rarement, quelque défaut dans la forme (dans l’expression), je veux dire du côté de la précision. Ainsi cette définition ordinaire de la ligne circulaire, qu’elle est une ligne courbe dont tous les points sont également éloignés d’un point unique (du centre), a le défaut d’introduire sans nécessité la détermination courbe. En effet il doit y avoir un théorème particulier qui est dérivé de la définition, et qui peut être aisément démontré, à savoir que toute ligne dont tous les points sont également éloignés d’un point unique est courbe (qu’aucune partie n’en est droite).

Kant, Critique de la raison pure.

Un type c'est un concept et l'interface d'une classe la définition d'un concept (celui mal fait d'algèbre sur un concept). Celui qui définit ses concepts comme des classes s'y prend aussi mal que ce qui est reproché dans le texte ci-dessus. Si au lieu de ce théorème, on prend le fait qu'un cercle a une circonférence dont la valeur est le diamètre multiplié par une constante (Pi) et que l'on met cela dans une méthode d'une classe, alors on définit le cercle comme une quiche sur patte. ;-)

Le problème étant que, si l'on a que des classes, ce défaut qui touche à la forme des définitions, au lieu d'être rare, se retrouve être permanent.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

La commutativité et l'associativité sont des points super importants en calcul sur des gros volumes. Que ce soit en C++ ou en n'importe quoi.

• Associativité: tu peux séparer en morceaux indépendants
• Commutativité: l'ordre n'est pas important, ainsi tu peux traiter les morceaux quand ils arrivent et ne pas dépendre de la latence réseau par exemple.

Ce n'est pas moi qui dirait le contraire : ces propriétés permettent d'effectuer les calculs dans n'importe quel ordre, i.e. quelque soit la permutation effectuée sur la séquence d'opérations on aboutit toujours au même résultat. Ainsi, on est moins tributaire du temps d'accès aux données (peu importe l'ordre dans lesquelles elles arrivent) que ce soit du à de la latence réseau, ou à des échanges répétés entre le cache et la ram. ;-)

;)

Il y a une série d'articles de blogs (compilé en un livre) sur le thème théorie des catégories pour les programmeurs. L'auteur y donne des illustrations de code en Haskell et C++ : c'est dingue à quel point la syntaxe du C++ est tordue et peu « parlante ». Si l'on prend la notion élémentaire de monoïde (cf chapitre 3), en Haskell cela se définit ainsi :

class Monoid m where
    mempty  :: m
    mappend :: m -> m -> m

autrement dit un monoïde sur un type m est la donnée d'un élément neutre et d'une opération associative (important l'associativité, même si le contrat est implicite entre les programmeurs ;-). Là où en C++, avec les concepts, on se retrouve à le définir ainsi :

template<class T>
  T mempty = delete;

template<class T>
  T mappend(T, T) = delete;

template<class M>
  concept bool Monoid = requires (M m) {
    { mempty<M> } -> M;
    { mappend(m, m); } -> M;
  };

Non, mais what the fuck !? :-o

Par comparaison, en ML, c'est proche du Haskell mais plus conforme à la définition formelle des mathématiciens :

module type Mondoid = struct
  type t
  val mappend : t -> t -> t
  val mempty : t
end

c'est-à-dire la donnée conjointe d'un type (ou concept, ou ensemble…), d'une loi de composition interne associative et d'un élément neutre pour cette loi. La différence avec Haskell étant que le type fait partie du dictionnaire, là où en Haskell le type support du monoïde paramétrise le dictionnaire qui n'a que deux éléménts. C'est similaire à ce type produit :

type 'm monoid = {
  mempty : 'm ;
  mappend : 'm -> 'm -> 'm
}

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Ai-je bien compris ?

Oui c'est cela, mais plus proche des packages génériques : c'est tout une section de code qui peut être paramétrée, pas seulement une fonction. Mais les concepts n'ajoutent rien de nouveau là-dessus, c'est ce qu'on toujours fait les template. Les concepts c'est juste un système de types pour les template. Le langage des template est interprété par le compilateur et, avant, lorsqu'il y avait une problème lors de l'instantiation d'une template, il y a avait l'équivalent d'une stack trace en guise de message d'erreur, qui pouvait faire 3km de long si le code utilisé était très générique. Là, ils auront des messages plus clairs du au système de type.

Peut-on faire des trucs encore plus forts avec les concepts que juste spécifier les opérations nécessaires ?

Je ne crois pas, mais on peut les utiliser en dehors des templates. Par exemple, pour contraindre le mécanisme d'inférence de type :

Sortable auto x2 = f(y);

ne compilera que si la fonction f retourne une valeur que l'on peut trier.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Mais je pense amicalement que tu me provoques un peu sachant que tu sais cela très bien.

Ce n'était pas de la provocation, j'étais bien sérieux avec ma question. Je me doutais bien que cela devait être affirmé sans preuve, mais j'ai préféré avoir confirmation. Là où j'étais un peu railleur, c'est en te demandant la syntaxe choisie pour exprimer cela (de manière générale je me demandes quels genres de psychotropes prennent les responsables du standard C++, mais ils devraient réduire la dose, j'ai rarement vu une syntaxe aussi laide).

C'est juste un problème d'interface ou de contrat que tu passes avec ton développeur et la libraire. Si on reprend l'exemple de la commutativité, si en tant que développeur je sais que le type générique (e.g. template) que j'utilise est commutatif pour mon opération, alors je peux me permettre certaines choses. On peut me mentir, mais au moins j'aurais prévenu. Inversement, en demandant que le type en entrée soit commutatif, je préviens l'utilisateur et il ne peut pas rater la contrainte que je lui demande.

Ça se tient. C++ étant orienté performance, avoir la commutativité permet de choisir un parcours de données plus efficace pour optimiser l'usage du cache du CPU, par exemple.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Avec un concept tu pourra aussi demander à ce que + soit commutatif.

C'est fascinant ça. Mais comment on prouve au type checker que l'opérateur + que l'on définit est bien commutatif ? On se contente de l'affirmer sans preuve ? Dans les faits, elle ressemble à quoi la syntaxe pour ce genre de propriété ?

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Qu'ai-je loupé?

T'as le message d'erreur d'un type checker au lieu d'avoir une stack trace à la python. En gros, le système de template c'était du lamba-calcul non typé, ils y ont rajouté un système de types. Le langage est interprété par le compilateur : en l'absence de typage statique, tu as une stack trace lors de l'appel, avec un système de types tu as tous les avantages du typage statique.

Par contre le choix du nom pour la fonctionnalité n'est pas très judicieux : un concept c'est un type (les deux mots sont synonymes), donc des concepts il y en avait déjà depuis le début en C++. Là, cela revient à paramétrer du code par un type muni de certaines opérations : ça s'appelle une algèbre. ;-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Moi perso j'ai 6 pieds de tomate, et cette année j'ai quasi rien récupéré. Et je sais pas quoi faire pour l'an prochain

Demande à eingousef ! :D

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Personnellement, l'apprentissage de la théorie de la relativité m'a surtout fait comprendre a quel point j'étais ignorant, et je ne suis d'ailleurs toujours pas très sur de savoir ce que ce que c'est que la gravité.

Il me semble que tu es un ancien marin, alors pour approfondir cette question, sans avoir besoin d'un lourd formalisme géométrique, je peux te proposer de retourner à la source et de lire le Dialogue sur les deux grands systèmes du monde de Galilée. Si tu as lu le livre d'Einstein sur la rélativité, son personnage enfermé dans sa cabine est un lointain cousin d'un personnage de Galilée : un marin enfermé dans sa cabine et qui se demande si avec les expériences qu'il y fait, il peut déterminer si le bateau est en mouvement ou non. ;-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Au début (avant la norme AFNOR), je suivais ton patron (merci, au passage pour ton journal de l'époque) ou celui du CHU de grenoble. ;-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

J'en sais rien, mais pas besoin de le faire si tu ne veux pas. C'est un carré de 20cm sur 20cm que tu dois replier d'une certaine façon : tu as un tuto ici, avec les dimensions en bas de page.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Pour ma part, j'utilise un masque maison en coton à chaque sortie depuis le début du confinement.

Au niveau de l'entretien, je ne le passe pas à la machine, mais je le fait tremper dans l'eau chauffée à la bouilloire électrique (entre 80°C et 90°C) avec de la javel [1] pendant 30 minutes, puis je finis par un coup de fer à repasser. Avec une telle température de lavage, il finit par rétrécir et j'en refais un autre : c'est assez rapide à faire si on a du stock de tissu ou de vieux draps, et pour le patron je suis maintenant celui fournit par l'AFNOR.

[1]: je mets aussi de la lessive, puis un rinçage rapide avec un adoucissant pour que le tissu ne deviennent pas trop rêche.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

je serais d'ailleurs curieux de ce que Kant aurait à dire sur le sujet

Littéralement parlant, il n'a plus grand chose à dire sur le sujet, étant mort depuis plus de 200 ans. Mais, plus sérieusement, tu es curieux de savoir ce qu'il a dit sur quel sujet ? La tyrannie de groupe ? La première chose qui me vient à l'esprit est qu'il considérait la démocratie comme une forme de gouvernement despotique, mais ce qu'il entendait sous ce terme correspond plus à ce que nous entendons par démocratie directe et non les systèmes représentatifs (dont il était partisan) :

Pour que l’on ne confonde pas (comme on le fait communément) la constitution républicaine avec la démocratique, je dois faire les remarques suivantes. Les formes d’un État (civitas) peuvent être divisées, soit d’après la différence des personnes qui jouissent du souverain pouvoir, soit d’après la manière dont le peuple est gouverné par son souverain, quel qu’il soit. La première est proprement la forme de la souveraineté (forma imperii), et il ne peut y en avoir que trois : en effet, ou bien un seul, ou bien quelques-uns unis entre eux, ou bien tous ceux ensemble qui constituent la société civile possèdent le souverain pouvoir (autocratie, aristocratie et démocratie, pouvoir du prince, pouvoir de la noblesse et pouvoir du peuple). La seconde est la forme du gouvernement (forma regiminis) ; elle concerne le mode, fondé sur la constitution (sur l’acte de la volonté générale, qui fait d’une multitude un peuple), suivant lequel l’État fait usage de sa souveraine puissance, et elle est sous ce rapport ou républicaine ou despotique. Le républicanisme est le principe politique de la séparation du pouvoir exécutif (du gouvernement) et du pouvoir législatif ; le despotisme est le gouvernement où le chef de l’État exécute arbitrairement les lois qu’il s’est données à lui-même, et où par conséquent il substitue sa volonté particulière à la volonté publique. — Parmi les trois formes politiques, indiquées plus haut, celle de la démocratie, dans le sens propre de ce mot, est nécessairement un despotisme, puisqu’elle établit un pouvoir exécutif, où tous décident sur et même contre un seul (qui ne donne pas son assentiment), et où par conséquent la volonté de tous n'est pas celle de tous, ce qui est une contradiction de la volonté générale avec elle-même et avec la liberté.

Kant, Traité de paix perpétuel

Le texte complet est sur wikisource (mis en forme par zeroheure et moi-même ;-).

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

On leur montre le chemin.

Je ne suis pas certain que de faire l'éloge de la Corée du Sud soit le meilleur moyen d'arriver à tes fins ;-)

Le système de santé sud-coréen est en passe d’être totalement privatisé. La crise de 2008 a, pour l’instant, obligé le gouvernement coréen à revoir ses plans. Il n’existe pas à proprement parler d’offre publique de santé en Corée, tant l’offre de soins repose essentiellement sur le secteur privé qui représentait en 1996, 91% des lits et 89% du personnel hospitalier.

source

L'article date de 2010 et la situation n'a pas évolué vers plus d'étatisation, bien au contraire : la Corée du Sud a l'un des systèmes de santé le plus privatisé du monde, bien davantage qu'aux États-Unis.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Peut-être que chez des zététiciens chevronnés il y a quelque chose de précis ?

Se rendre chez les logiciens et philosophes devraient suffire. D'autant que, pour des questions aussi fondamentales, les dernières personnes que j'irai voir sont bien des statisticiens.

Je n'ai pas compris la partie après les deux points.

À considérer les choses objectivement nous n'avons que deux sources de savoir à la base de nos jugements : notre raison et l'expérience via l'observation du monde. Comme il est impossible de tout observer et expérimenter par soi-même, il est inéluctable, dans ce type de connaissance, de substituer l'expérience d'autrui à notre propre expérience au fondement de nos jugements. Procéder ainsi c'est se reposer sur l'autorité d'autrui, ce qui n'a rien de fallacieux.

Si quelqu'un que tu croises te dis qu'en ce moment il y a une pandémie, que tu lui demandes comment il le sait, puis qu'il te répond que c'est ce que dit l'OMS, alors il fait usage d'un argument d'autorité. Rejeter, par principe, tout argument d'autorité au prétexte qu'ils sont nécessairement fallacieux, c'est au pire la porte ouverte à toutes les formes de complotisme, au mieux l'avènement d'un scepticisme radical.

En revanche, dans le champ de la connaissance rationnelle, il n'est pas acceptable de substituer le jugement d'autrui au sien propre : je reconnais le théorème de Pythagore comme vrai, non parce que des géomètres le considèrent comme tel, mais parce je suis en mesure d'en fournir la preuve. La totalité du fondement de telles propositions se trouve en moi-même, dans ma propre raison, et il en est de même pour chacun.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

"Argument d'autorité" est le terme utilisé pour ce qui n'est pas un argument, c'est une astuce de rhétorique, une ruse. C'est la définition du truc :-)

Il me semble que ta définition de l'argument d'autorité est trop stricte : on ne peut s'en passer dans les connaissances expérimentales.

Le préjugé qui tient à la considération des personnes. — Lorsque, dans les choses qui reposent sur l’expérience et le témoignage, nous faisons porter notre connaissance sur la considération que nous avons pour d’autres personnes, nous ne tombons pas dans un préjugé ; car, en fait de choses de cette nature, comme nous ne pouvons pas tout connaître par nous-mêmes, ni tout embrasser avec notre entendement propre, nous basons nos jugements sur la considération due aux personnes. — Mais, si nous fondons nos jugements, en fait de connaissances rationnelles, sur la considération que nous accordons aux autres, ces connaissances ne sont pour nous que de véritables préjugés, car les vérités rationnelles valent anonymement ; il n’est pas question de savoir qui est-ce qui a dit cette chose, mais qu’est-ce qu’on a dit. Qu’importe qu’une connaissance soit ou ne soit pas de noble origine ! Et cependant, le penchant à la considération des grands hommes en matière scientifique est très-commun, tant à cause des limites de la pénétration ordinaire, que par le désir d’imiter ce que nous croyons grand. Notre vanité se trouve encore indirectement satisfaite par le respect que nous portons à quelque homme de génie. De même que les sujets d’un despote puissant sont fiers d’être tous traités par lui de la même manière, puisque le plus petit peut, se croire égal au plus grand, tous deux n’étant également rien en présence du pouvoir illimité de leur maître, de même les adorateurs d’un grand homme se jugent égaux, en ce sens que la supériorité qu’ils peuvent avoir les uns sur les autres, considérée quant au mérite de cet homme, est réputée insignifiante.

Kant, Logique.

Lorsque Liorel nous présente le modèle statistique pour évaluer les risques, on est dans le champ de la connaissance pure et rationnelle : nulle personne ne peut faire autorité ; chacun étant aussi proche des sources du savoir que l'auteur (il se trouve dans la commune raison humaine, c'est-à-dire en nous même). En revanche lorsqu'il fournit les données d'entrée du modèle, elles sont le résultat d'observation et de mesures statistiques : c'est l'autorité des auteurs qui fait foi pour qui n'y a pas un accès direct.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Mathématiquement c'est peut être une horreur, mais en cuisine cela se pratique couramment … :)

Ça n'a rien d'une horreur mathématique, et ne dit on pas couramment « ajouter un ingrédient à la liste ». Comme te l'a dit JeanClaude : tu définis juste une algèbre sur les recettes de cuisine. Il est où le problème ? D'autant que ton exemple est mal choisi pour « détourner » l'arithmétique : c'est de l'arithmétique ton opérateur. Comme je l'ai dit plus haut : d'un certain point de vue les listes c'est des entiers unaires, et là tu as défini l'opération successeur (ou « ajouter 1 »).

module Arithmetique = struct
  type nat = unit list
  let zero = []
  let succ l = () :: l
end

Voilà : un entier unaire c'est juste une liste de bâtons, zéro c'est la liste vide et la fonction qui calcule le successeur consiste à ajouter un élément dans la liste (c'est à dire ta surcharge de la fonction add).

Toi ce que tu as écris c'est cela :

module Recette = struct
  type t = {
    ingredients : string list;
    nom : string ;
  }

  let new () = {ingredients = []; nom = ""}

  let changer_nom nom recette = {recette with nom = nom}
  let add ing recette = {
    recette with
    ingredients = ing :: ingredients
  }

let _ = Recette.(
 new ()
 |> changer_nom "Soupe de"
 |> add "patate"
 |> add "potiron"
)

Et ici ce que fais ma fonction add sur ma liste d'ingrédients, c'est la même chose que fait ma fonction succ sur les entiers unaires.

Pour répondre à ton autre commentaire :

Les mathématiques s'arrêteraient elles donc ou l'informatique commence :)

ou l'informatique aurait elle une plus grande portée que les mathématiques ?

:)

Non, comme je le dis depuis le début : c'est la même chose. C'est juste une extension et une généralisation des travaux de Descartes quand il a algébrisé la géométrie mais, entre Descartes et nous, il s'est passé près de 400 ans. ;-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Je ne vois pas le rapport qu'il y a entre la question traitée et la polysémie des langages¹. De même qu'elle n'a rien à voir avec le fait que toute modélisation est une vision partielle et simplifiée de la réalité. Il s'agit de sémantique des langages et du fait que la relation « est une sorte de » n'a rien à voir avec la notion de classe et d'héritage, contrairement à ce qui est couramment présenté. Un canard, même simplifié, modélisé, tout ce que tu veux, n'a jamais été et ne sera jamais une instance d'une classe canard qui hériterait d'une classe animal. C'est ce que j'avais expliqué en détail dans ce commentaire d'une dépêche.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.