kantien a écrit 1131 commentaires

Je suis bien d'accord. Mon « que veux tu ? » plus haut n'était pas dirigé contre toi, mais était une remarque ironique envers nos détracteurs. ;-)

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

Avec ton analogie, les banquiers signent des reconnaissances de dette avec l’argent des autres donc soit ton analogie est foireuse, soit les banquiers sont des escrocs.

Cela n'a rien d'une analogie, c'est la nature juridique de l'argent. Voir mes deux autre commentaires en réponse à tisaac: ici et là

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

C'est parce qu'il y a quelque chose en réserve qu'il peut y avoir des écritures comptables.

J'ai oublié un point dans mon précédent message. Oui, il faut quelque chose, pour être garant, et on appelle cela du capital (de la valeur qui est autre chose qu'une promesse : un tiens vaut mieux que deux tu l'auras). ;-)

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

De toute manière, il y a bien quelques choses de préexistant à ces écritures comptables. C'est parce qu'il y a quelque chose en réserve qu'il peut y avoir des écritures comptables.

Oui, parce qu'elles y sont adossées. L'argent étant une reconnaissance de dette, cela relève du droit et, in fine, des États. Chaque État détermine les règles selon lesquelles il reconnaîtra les dettes, et il peut laisser aux banques le soin d'en émettre à la condition qu'elles se portent garantes en cas de défaut du créancier (système des réserves fractionnaires).

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

…ou juste selon le dogme ? :p

Que veux tu ? il y a des gens qui voient bien avec leurs yeux, mais dont les yeux de l'esprit sont quelque peu aveuglés.

Vous avez un écu. Que signifie-t-il en vos mains ? Il y est comme le témoin et la preuve que vous avez, à une époque quelconque, exécuté un travail, dont, au lieu de profiter, vous avez fait jouir la société, en la personne de votre client. Cet écu témoigne que vous avez rendu un service à la société, et, de plus, il en constate la valeur. Il témoigne, en outre, que vous n’avez pas encore retiré de la société un service réel équivalent, comme c’était votre droit. Pour vous mettre à même de l’exercer, quand et comme il vous plaira, la société, par les mains de votre client, vous a donné une reconnaissance, un titre, un bon de la République, un jeton, un écu enfin, qui ne diffère des titres fiduciaires qu’en ce qu’il porte sa valeur en lui-même, et si vous savez lire, avec les yeux de l’esprit, les inscriptions dont il est chargé, vous déchiffrerez distinctement ces mots : « Rendez au porteur un service équivalent à celui qu’il a rendu à la société, valeur reçue constatée, prouvée et mesurée par celle qui est en moi-même. »

Bastiat, maudit argent.

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

J'ai du mal à comprendre la différence entre ce que tu décris et ce que décrit le documentaire ?

C'est peut être ma mémoire qui me joue des tours. Dans mon souvenir (je ne l'ai pas regardé récemment), il décrit le fonctionnement du système pour présenter les banquiers comme des voleurs. Mon point est de dire que le système ne peut fonctionner autrement et qu'il en a toujours été ainsi, qu'il en sera toujours ainsi, car c'est l'essence même de l'argent d'être une reconnaissance de dette.

le documentaire est qu'il ne parle pas de suppression monétaire, ce dont tu ne parles pas non plus

Je ne pensais pas qu'il était nécessaire d'expliciter une évidence : lorsque C va voir A avec sa promesse pour qu'il s'acquite de sa dette, la dette disparait et la monnaie avec. ;-)

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

En informatique, la théorie des types est un bon exemple de ce genre de cas.

Il est vrai, qu'en informatique, l'étude et la réflexion sur le design des API est de fort peu d'importance. Cette réflexion a le défaut de passer sous le tapis les détails d'implémentation, ce qui peut intriguer le producteur, mais, en pratique, je n'ai jamais vu un consommateur s'intéressait à ce genre de détails (sauf s'il veut devenir producteur lui même). ;-)

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

De celui dont parle le lien wikipédia donné par Luke Skywalker. ;-)

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

Pas besoin d'être docteur en économie, ni issu du monde du traiding pour comprendre que ce documentaire c'est n'importe quoi sur le plan de l'économie.

Le principe élémentaire de l'échange marchand, c'est le troc : donne moi ceci ou fais cela pour moi et, en échange, je te donnerai ceci ou ferai cela pour toi.

Mais voilà, la société n'est pas constituée de seulement deux individus, mais elle peut en avoir trois. A vient voir B qui propose un bien ou service S, qu'il aimerait bien avoir. B lui dit : « Ok, mais tu me files quoi en échange ? ». Sur ce, A lui propose un bien ou service S'. B réfléchit, se dit que les valeurs s'équivalent, mais qu'il n'a pas réellement besoin de S', d'autant qu'il ne peut l'avoir de suite (alors que S est déjà disponible). Il revient voir A, puis lui dit : « Ok, pourquoi pas, je te donne S et en échange tu me donnes une promesse sur S' » (on est pas loin de la programmation avec promise). Ensuite, B qui ne veut pas vraiment de S', va voir C, qui le recherche, et lui donne la promesse de S' en échange d'un service S'' (que fournit C) et que B désire.

Cette promesse de S' est du proto-argent, créer par la dette de A vis à vis de B, introduit dans le système économique constitué par A, B et C. Et il en est de même de toute les liquidités qui ont jamais circulait en ce bas monde : ce sont des reconnaissances de dettes. Cela n'a rien d'exubérant, c'est l'essence même de l'argent d'être une reconnaissance de dette.

Avant de se demander : comment crée-t-on de la monnaie ? Il faut d'abord se poser la question : qu'est-ce que l'argent ? Et alors, la réponse : la dette crée la monnaie coule de source.  ;-)

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

Oui l'image du trains, des rails et des aiguillages et une bonne image pour présenter le fonctionnement d'une monade. Ce qui est décrit est valide quelque soit la monade choisie et pas seulement celle d'erreurs : c'est une question de composition de diagonale dans les calculs.

          f                 g
 A   ----------->  B   ----------->  C
 |                 |                 |
 |                 |                 |
 V      map f      V       map g     V
F(A) -----------> F(B) -----------> F(C)

Ici A, B et C sont des types et F est un types paramétriques. Le but d'une monade est de composé les diagonales : aller de A à F(C) en prenant les chemins A -> F (B) et B -> F(C). Ce qui dans le cas des erreurs correspond à un calcul produisant peut être un B à partir d'un A et un autre produisant peut-être un C à partir d'un B. En composant ces deux fonctions, on en obtient une qui produit peut être un C à partir d'un A.

Dans le cas de la monade identité, on a F(A) = A, les deux lignes du haut et du bas sont les même et c'est le principe du pipe du shell : on pipe A dans f puis le résultat dans g et on obtient C. Une monade c'est juste une généralisation du principe du pipe du shell.

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

En fait c'est le même problème que je rencontre un peu régulièrement dans ma carrière: l'absolutisme des dogmes.

Ce n'est pas une question de dogmes mais de modèle de calcul : lambda-calcul ou machine de Turing. Ce que tu décris ensuite relève de principes architecturaux d'organisation de codes, et n'a rien à voir avec le modèle de calcul sous-jacent aux langages. On peut les appliquer correctement, ou n'importe comment sans rien y comprendre, et cela quelque soit le modèle de calcul choisi par le langage sous-jacent dans lequel on implémente nos idées.

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

Quel langage est le plus « pur » parmi les langage fonctionnels ?

Tu le cites juste après c'est Haskell. ;-) Il y a des traits impératifs dans tous les autres (si on oublie ceux à types dépendants), OCaml y compris. Tu ne peux pas faire d'entrée-sortie en Haskell sans passer par le monade IO, toutes les valeurs sont immuables, aucun effet de bords…

En parlant de monade et de ton return LISP qui ne va pas n'importe où : oui il saute à l'entrée où le code de la fonction avait été appelé, mais sans son double correspondant, le bind, c'est une structure de contrôle qui ne vaut pas grand chose.

Ce qui me semble pathologique, par exemple, c'est la gestion des erreurs en go où l'on voit répéter à longueur de code le même pattern:

if err != nil {
  do_this;
  do_that;
}

Voilà ce que fait une code appelant du retour qu'il reçoit après un calcul qui peut échouer : c'est son bind. ;-)

Quand tout est expression, ce motif est aussi une expression, qui peut alors devenir paramètre formel d'une autre expression, d'où le bind de la monade d'erreur :

let bind x f = match x with
  | Ok v -> f v
  | Error _ as e -> e

On l'écrit une bonne fois pour toute et il n'est plus nécessaire de le recopier des centaines de fois à longueur de code, ce qui relève de la pathologie malsaine. ;-)

On peut alors, dans son code, se concentrer sur la partie importante : que faire du résultat quand on en a un ? On n'attrape alors qu'en toute fin de fonction les erreurs que l'on veut attraper si l'on souhaite en gérer certaines au lieu de disséminer cela dans tous les sens dans le corps de la fonction. ;-)

En résumé : les programmeurs go utilise le bind de la monade identité quand il travaille dans la monade d'erreurs, ce qui rend leur code de gestion d'erreurs totalement imbitable dès qu'il y en a plusieurs qui s'enchainent.

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

Je vois bien l’idée mais ce contraindre à coder uniquement selon ce paradigme me semble relever de la manie pathologique.

Je ne vois pas bien ce qu'il y a de pathologique là-dedans. C'est un paradigme comme un autre, celui suivi par tous les langages fonctionnels du LISP jusqu'à nos jours, langages qui ont tous pour modèle le lambda-calcul d'Alonzo Church. Church était le directeur de thèse de Turing, et le seul intérêt que je vois à son modèle de calcul sur machine est que l'on peut compiler en une suite d'instruction machine un code écrit en lambda-calcul (les deux modèles sont équivalents). Procéder par évaluation d'expression, c'est ce que je fais depuis que j'ai appris à calculer à l'école primaire avec un papier et un crayon. Je ne vois pas bien le côté pathologique a toujours faire de même. ;-)

J’ai le sentiment qu’un return (qui existe en Lisp), est compatible avec un paradigme fonctionnel strict

LISP (qui est orienté expression) a aussi des traits impératifs (c'est du fonctionnel impur) et le return permet, entre autre, de sortir prématurément d'une boucle (cf. mon commentaire sur le message de Linus). Dans un langage fonctionnel pur, toute boucle est une fonction récursive et si l'on veut sortir, il suffit de ne pas relancer la récursion et de dire à quelle expression s'évalue le retour de fonction (le return explicite devient purement facultatif).

Ce qui me semble pathologique, c'est ce besoin irrépressible d'avoir un return quelque part dans le corps d'une fonction. ;-)

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

Avec ce genre d'arguments il n'y a plus d'overflow. Personne ne découvre le langage, personne ne commet de faute etc

Uso a raison sur ce que je voulais dire. L'usage du goto en C est tout à fait anodin et n'est pas comparable à la gestion mémoire. C'est limité à la portée de la fonction et permet simplement une meilleure organisation et lisibilité du code. C'est du même ordre que l'usage des exceptions locales en OCaml (exception dont la définition est interne à une fonction) qui sont toutes rattrapées et n'ont aucune chance de se propager n'importe où.

Ce qui est risqué c'est l'oubli de mettre un bout de code ou un mauvais code dans chaque label, mais ça un système de try ... catch ne le résoudra pas non plus.

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

Une analogie qui m'est revenue, sur le style orienté expression, est celle des phrases à trous. Une fonction Ocaml (ou dans le style fonctionnel) c'est comme les phrases à trous. Dans la fonction foo cond = if cond then 2 else 3, c'est juste une expression if _ then 2 else 3 qui comporte un trou, trou auquel le paramètre formel donne un nom. Appeler la fonction consistant à dire quoi mettre dans le trou pour former une expression.

En français, on pourrait écrire « la première fonction Scala définie par martoni dans son journal ». Cette phrase désigne ("s'évalue") la fonction pof. On peut, ensuite, mettre un trou à la place de « première »; on a alors la phrase à trou « la ____ fonction Scala définie par martoni dans son journal ». Ou, si l'on nomme le trou : « la nième fonction Scala définie par martoni dans son journal ». Cette dernière phrase est une fonction qui prend un entier en paramètre (pour combler le trou) et retourne le nom d'une fonction :

• 1 -> pof
• 2 -> pif
• 3 -> pouet

C'est ça le style expression : on écrit des phrases à trous au lieu d'un suite d'instructions données à la machine (c'est le rôle du compilateur de passer d'un style à l'autre). Le return (des langages impératifs) étant vu, de base, comme une instruction pour la machine.

Il va de soi que la phrase à trou « Tu bluffes ___ ! » n'accepte que martoni en paramètre. :-P

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

L’expression que tu donnes en exemple ci-dessus, tu considères qu’elle relève de l’expression ou de l’instruction ?

Thomas t'as répondu sur le reste, je ne reviendrais donc que sur cette question. Quand je dis que c'est orienté expression, c'est que l'on ne code pas en pensant au fait que cela sera traduit en instruction pour une machine (c'est le travail du compilateur de faire cela) mais que l'on a des expressions, définies les unes à partir des autres, que l'on cherche à évaluer. L'exécution du programme ne consistant qu'en l'évalutation de ces expressions.

La construction if true then 2 else 3 est une expression au même titre que n'importe qu'elle entier, et qui s'évalue ici à 2. Et je peux l'utiliser ainsi :

(if true then 2 else 3) + 1;;
- : int = 3

Lorsque l'on définit une fonction comme foo, on explique juste comment évaluer une expression à partir d'une autre donnée en paramètre. Ainsi, on a :

(foo true) + 1;;
- : int = 3

(foo false) + 1;;
- : int = 4

Il n'y a pas besoin de return explicite, parce que le modèle de calcul veut que lorsque une fonction en appel une autre (ce qui est aussi un saut dans le code) elle retourne (encore un saut) avec la valeur de l'expression qu'elle a évaluée.

Après, si on veut signifier cet aller-retour entre en l'appelant et l'appelé via un return et un bind (pour décrire ce que fera l'appelant de la valeur retournée), on aboutit à la structure de monade décrite plus haut, structure qui, si on analyse son fonctionnement, mène à la notion d'effets ;-) (voir les futurs leçons de Xavier Leroy sur le sujet).

Dans le cas de la monade d'erreurs (les exceptions à la sauce Rust), le code du bind est le suivant :

let bind x f = match x with
  | Ok v -> f v
  | Error _ as e -> e

Autrement dit, sa sémantique est la propagation des exceptions : si on reçoit une valeur on la traite, sinon on retourne l'erreur reçue au code appelant supérieur, jusqu'à ce qu'il y en ait un qui la traite. ;-)

On aboutit alors à des notions bien mieux structurées qu'un simple goto pour gérer les sauts dans le code. ;-)

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

C’est pas possible d’implémenter un try … catch … en C ?

En théorie oui, mais en pratique cela me semble de peu d'utilité. Le C est un langage normé ISO, processus long et complexe, et il faudrait ajouter un garde-fou sans grande utilité pratique : ceux qui utilisent le goto pour cela savent très bien s'y prendre, et il est impossible de retirer le goto pour des raisons de compatibilité historiques avec le code existant. À quoi bon rentrer dans un processus de normalisation ISO sans intérêt pratique ?

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

Oui, et c'est une application du goto statement considered harmful. Mais dans le fond, il est trop conservateur : pour éviter toute erreur, on interdit par convention certains usages. Sauf que l'usage que je décris est celui des effets mais, s'il est fourni par des primitives mieux structurées que goto, alors il est tout de suite moins harmful et bien pratique.

Celui que décrit Robert Love dans son message est celui des exceptions, celui que je décris est celui des effets. ;-)

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

C'est une bonne manière de présenter la chose. On est proche de l'usage du goto dans le dernier message de Robert Love dans l'échange sur la mailing list du kernel postée plus haut, où l'usage est qualifié de cleanly do the usual stack-esque wind and unwind. Mais ici chaque code d'un appelé via goto peut retourner à l'appelant via un goto pour reprendre l'éxecution. Et là, on arrive au code spaghetti si c'est fait à coup de goto et non de primitives plus structurées. ;-)

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

Always look on the bright side of life ;-)

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

Un petit bonus sur le returncomme fonction identité, les exceptions et les pointeurs. En fait, on peut bien trouver des return en OCaml, quand on quitte ce que l'on appelle la monade identité. Ce qui peut être le cas quand on travail avec des pointeurs à la places d'exceptions.

La fonction int_of_string_opt a pour type string -> int option. Ce qui veut dire qu'elle prend une chaîne de caractères pour la convertir en int. Par contre, si c'est pas possible, au lieu de lever une exception, elle retourner l'équivalent OCaml d'un pointeur sur int (qui est le pointeur nul en cas d'échec). Et bien, on peut travailler avec ces pointeurs comme si c'était des int. Le tout c'est de lui dire comment si prendre pour travail avec un fonction qui attend un a et retourne un pointeur sur b, comment on s'y prend pour lier une valeur à une variable quand on travaille avec des pointeurs.

let bind x f = match x with Some v -> f v | None -> None

Si j'ai un pointeur valide je passe la valeur pointée à f, sinon je retourne toujours le pointeur nul.

Ensuite, il faut dire comment on obtient un pointeur à partir d'un valeur donnée :

let return x = Some x

Enfin on peut écrire le code suivant :

let foo s s' =
  let ios = int_of_string_opt in
  let (let*) = bind in
  let* x = ios s in
  let* y = ios s' in
  return (x + y)

Fonction qui s'utilise ainsi :

(* tout va bien on a un pointeur sur int *)
foo "21" "21";;
- : int option = Some 42

(* on a un pointeur nul *)
 foo "a" "21";;
- : int option = None

C'est ainsi que les exceptions sont gérées en Rust via la monade d'erreurs. :-)

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

Sinon, pour l'évolution des pratiques en la matière, il y a le cours de cette année de Xavier Leroy au Collège de France Structures de contrôle : de « goto » aux effets algébriques.

Cette fois, les effets algébriques sont des exceptions sous stéroïdes et c'est un peu plus qu'un simple jump. Depuis leur arrivée dans OCaml 5 (avec le multicore), il y a une émulation et une concurrence qui se crée pour implémenter des ordonnanceurs en utilisant les effets.

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

Le message de Linus, sur l'absence d'instruction break pour sortir prématurément d'une boucle en Pascal, me rappelle la situation de ceux qui utilisent pas mal le style impératifs en OCaml. Ils ont demandé plusieurs d'avoir cette primitive sur le bugtracker mais n'ont toujours pas eu gain de cause. Pour l'instant, il faut passer par des exceptions pour faire ça.

Au lieu de :

for ... do
  do_A;
  do_B;
  if cond then break;
done

il faut faire un truc du genre :

try for ... do
  do_A;
  do_B;
  if cond then raise Break;
done
with Break -> do_check

Bon dans le fond ça change rien, les exceptions en OCaml c'est un jump (à la manière des exceptions en C via goto), mais ça rendrait le code peut être plus clair avec un break.

Sinon pour revenir au journal, en programmation fonctionnelle ce n'est pas forcément la dernière valeur qui est retournée. C'est juste que c'est un style orienté expression et non instruction.

Dans le code suivant :

let foo cond = if cond then 2 else 3

la valeur retournée dépend du booléen est peut être 2 ou 3. Ça équivaut à ce code :

(* return est juste la fonction identité *)
let return x = x

(* le même code qu'avant *)
let foo cond = if cond then return 2 else return 3

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

Tu penses vraiment que les cyclistes font ça pour embêter les automobilistes pour leur rappeler le code de la route.

En fait, ça ne leur ferait pas de mal de leur rappeler. Un cycliste, c'est comme un piéton : la voiture est toujours en tort. On ne met pas en danger la vie des gens comme ça nous chante.

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

bien sûr que c'est idiot de doubler un cycliste pour se retrouver coincé au feu rouge 50 mètres plus loin, mais que ça soit idiot ou pas, c'est son droit

Il faut se méfier de ce qui est son droit vis à vis des autres automobilistes. Si un cycliste te grille une priorité à droite et que tu le fous par terre, tu es en tort. Dans ton cas c'est plus une question de bienséance, mais j'ai pu constater que nombre d'automobilistes traitent les cyclistes comme des voitures ce qui les met (les cyclistes) en danger.

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