update

2024-03-31 23:15:58 +02:00
parent 6f8ae6624e
commit 06f3641660
23 changed files with 478 additions and 46 deletions
--- a/sources/zotero/EffetBordInformatique2023.md
+++ b/sources/zotero/EffetBordInformatique2023.md
@@ -9,25 +9,25 @@ link:: [Zotero](zotero://select/groups/5383243/items/HK8W8STH) [attachment](file
 #pkm #zotero


-> [!cite] [Effet de bord (informatique)](zotero://select/groups/5383243/items/HK8W8STH) - [Page ](zotero://open-pdf/groups/5383243/items/FHGCUVX5?annotation=BAIZ4M66)
+> [!cite]+ [Effet de bord (informatique)](zotero://select/groups/5383243/items/HK8W8STH) - [Page ](zotero://open-pdf/groups/5383243/items/FHGCUVX5?annotation=BAIZ4M66)
 > En informatique, une fonction est dite à effet de bord (traduction mot à mot de l'anglais side effect, dont le sens est plus proche d'effet secondaire) si elle modifie un état en dehors de son environnement local, c'est-à-dire a une interaction observable avec le monde extérieur autre que retourner une valeur.
 > 
 > > [!note] Notes
 > > effet de bord = modification en dehors de l'environnement local
 > ^BAIZ4M66aFHGCUVX5g5383243

-> [!cite] [Effet de bord (informatique)](zotero://select/groups/5383243/items/HK8W8STH) - [Page ](zotero://open-pdf/groups/5383243/items/FHGCUVX5?annotation=FRXYERKZ)
+> [!cite]+ [Effet de bord (informatique)](zotero://select/groups/5383243/items/HK8W8STH) - [Page ](zotero://open-pdf/groups/5383243/items/FHGCUVX5?annotation=FRXYERKZ)
 > Par exemple, les fonctions qui modifient une variable locale statique, une variable non locale ou un argument mutable passé par référence, les fonctions qui effectuent des opérations d'entrées-sorties ou les fonctions appelant d'autres fonctions à effet de bord[
 > ^FRXYERKZaFHGCUVX5g5383243

-> [!cite] [Effet de bord (informatique)](zotero://select/groups/5383243/items/HK8W8STH) - [Page ](zotero://open-pdf/groups/5383243/items/FHGCUVX5?annotation=RGPC6369)
+> [!cite]+ [Effet de bord (informatique)](zotero://select/groups/5383243/items/HK8W8STH) - [Page ](zotero://open-pdf/groups/5383243/items/FHGCUVX5?annotation=RGPC6369)
 > La programmation impérative permet l'emploi des effets de bord dans le fonctionnement de ses programmes, voire l'utilise délibérément
 > 
 > > [!note] Notes
 > > La modification (effet de bord) est un mécanisme important de la programmation impérative.
 > ^RGPC6369aFHGCUVX5g5383243

-> [!cite] [Effet de bord (informatique)](zotero://select/groups/5383243/items/HK8W8STH) - [Page ](zotero://open-pdf/groups/5383243/items/FHGCUVX5?annotation=LAQR2DNM)
+> [!cite]+ [Effet de bord (informatique)](zotero://select/groups/5383243/items/HK8W8STH) - [Page ](zotero://open-pdf/groups/5383243/items/FHGCUVX5?annotation=LAQR2DNM)
 > La programmation fonctionnelle cherche au contraire à les minimiser et les isole souvent pour cela dans des structures prévues entre autres pour cela : les monades.
 > 
 > > [!note] Notes
--- a/sources/zotero/EnregistrementStructureDonnees2023.md
+++ b/sources/zotero/EnregistrementStructureDonnees2023.md
@@ -0,0 +1,18 @@
+---
+zotero-key: BNI9449Ng5383243
+zt-attachments:
+  - "127"
+citekey: EnregistrementStructureDonnees2023
+---
+up:: [[zotero literature notes]]
+link:: [Zotero](zotero://select/groups/5383243/items/BNI9449N) [attachment](<file:///Users/oscarplaisant/Zotero/storage/HMUFH5Z7/Enregistrement_(structure_de_donn%C3%A9es).html>)
+#pkm #zotero
+
+
+> [!cite]+ [Enregistrement (structure de données)](zotero://select/groups/5383243/items/BNI9449N) - [Page ](zotero://open-pdf/groups/5383243/items/HMUFH5Z7?annotation=B5KK3HH2)
+> En programmation, un enregistrement est une structure de données qui rassemble plusieurs champs, ceux-ci contenant des valeurs qui peuvent être de types différents[1]. Typiquement, le nombre de champ et leur séquence sont fixés[1]. Les champs d'un enregistrement peuvent aussi être nommés "membres", en particulier dans la programmation orientée objet. Les champs peuvent encore être appelés "éléments", mais cela entraîne un risque de confusion avec les éléments d'une collection.
+> 
+> > [!note] Notes
+> > entregistrement := structure qui rassemble des champs
+> > champ := contient des valeurs (leur type peut changer)
+> ^B5KK3HH2aHMUFH5Z7g5383243
--- a/sources/zotero/ExpressivePowerComputer2023.md
+++ b/sources/zotero/ExpressivePowerComputer2023.md
@@ -0,0 +1,55 @@
+---
+zotero-key: L9WYV33Pg5383243
+zt-attachments:
+  - "130"
+citekey: ExpressivePowerComputer2023
+---
+up:: [[zotero literature notes]]
+link:: [Zotero](zotero://select/groups/5383243/items/L9WYV33P) [attachment](file:///Users/oscarplaisant/Zotero/storage/Q9KCGU98/Expressive_power_(computer_science).html)
+#pkm #zotero
+
+
+> [!cite]+ [Expressive power (computer science)](zotero://select/groups/5383243/items/L9WYV33P) - [Page ](zotero://open-pdf/groups/5383243/items/Q9KCGU98?annotation=4FGMWNP7)
+> In computer science, the expressive power (also called expressiveness or expressivity) of a language is the breadth of ideas that can be represented and communicated in that language.
+> 
+> > [!note] Notes
+> > expressivité := étendue des idées qui peuvent être représentées par un langage
+> ^4FGMWNP7aQ9KCGU98g5383243
+
+> [!cite]+ [Expressive power (computer science)](zotero://select/groups/5383243/items/L9WYV33P) - [Page ](zotero://open-pdf/groups/5383243/items/Q9KCGU98?annotation=ENM5Z4IE)
+> The more expressive a language is, the greater the variety and quantity of ideas it can be used to represent.
+> ^ENM5Z4IEaQ9KCGU98g5383243
+
+> [!cite]+ [Expressive power (computer science)](zotero://select/groups/5383243/items/L9WYV33P) - [Page ](zotero://open-pdf/groups/5383243/items/Q9KCGU98?annotation=MCRWAN6W)
+> For example, the Web Ontology Language expression language profile (OWL2 EL) lacks ideas (such as negation) that can be expressed in OWL2 RL (rule language). OWL2 EL may therefore be said to have less expressive power than OWL2 RL. These restrictions allow for more efficient (polynomial time) reasoning in OWL2 EL than in OWL2 RL. So OWL2 EL trades some expressive power for more efficient reasoning (processing of the knowledge representation language).
+> ^MCRWAN6WaQ9KCGU98g5383243
+
+> [!cite]+ [Expressive power (computer science)](zotero://select/groups/5383243/items/L9WYV33P) - [Page ](zotero://open-pdf/groups/5383243/items/Q9KCGU98?annotation=UL4ZYIV6)
+> The term expressive power may be used with a range of meaning. It may mean a measure of the ideas expressible in that language:[2]
+> 
+> regardless of ease (theoretical expressivity)
+> concisely and readily (practical expressivity)
+> 
+> > [!note] Notes
+> > 2 sens d'expressivité :
+> > - expressivité théorique
+> > 
+> > - expressivité pratique
+> ^UL4ZYIV6aQ9KCGU98g5383243
+
+> [!cite]+ [Expressive power (computer science)](zotero://select/groups/5383243/items/L9WYV33P) - [Page ](zotero://open-pdf/groups/5383243/items/Q9KCGU98?annotation=8W7EHIJN)
+> The first sense dominates in areas of mathematics and logic that deal with the formal description of languages and their meaning, such as formal language theory, mathematical logic and process algebra
+> 
+> > [!note] Notes
+> > expressivité théorique :
+> > mathématique / logique.
+> > en rapport avec la description formelle d'un langage.
+> ^8W7EHIJNaQ9KCGU98g5383243
+
+> [!cite]+ [Expressive power (computer science)](zotero://select/groups/5383243/items/L9WYV33P) - [Page ](zotero://open-pdf/groups/5383243/items/Q9KCGU98?annotation=T3UDRGGG)
+> The design of languages and formalisms involves a trade-off between expressive power and analyzability. The more a formalism can express, the harder it becomes to understand what instances of the formalism say. Decision problems become harder to answer or completely undecidable.
+> 
+> > [!note] Notes
+> > design d'un langage => compromis entre expressivité et analysabilité.
+> > formalisme peut exprimer + de concepts => ses instances deviennent + dures à analyser (les problèmes de décision devienent plus complexes, voire indécidables)
+> ^T3UDRGGGaQ9KCGU98g5383243
--- a/sources/zotero/FermetureInformatique2024.md
+++ b/sources/zotero/FermetureInformatique2024.md
@@ -0,0 +1,22 @@
+---
+zotero-key: ZKL3R2ZEg5383243
+zt-attachments:
+  - "214"
+citekey: FermetureInformatique2024
+---
+up:: [[zotero literature notes]]
+link:: [Zotero](zotero://select/groups/5383243/items/ZKL3R2ZE) [attachment](file:///Users/oscarplaisant/Zotero/storage/JNZ49HIA/Fermeture_(informatique).html)
+#pkm #zotero
+
+
+> [!cite]+ [Fermeture (informatique)](zotero://select/groups/5383243/items/ZKL3R2ZE) - [Page ](zotero://open-pdf/groups/5383243/items/JNZ49HIA?annotation=P8UFCIK5)
+> Dans un langage de programmation, une fermeture ou clôture (en anglais : closure) est une fonction accompagnée de son environnement lexical. L'environnement lexical d'une fonction est l'ensemble des variables non locales qu'elle a capturées, soit par valeur (c'est-à-dire par copie des valeurs des variables), soit par référence (c'est-à-dire par copie des adresses mémoires des variables)[1]. Une fermeture est donc créée, entre autres, lorsqu'une fonction est définie dans le corps d'une autre fonction et utilise des paramètres ou des variables locales de cette dernière.
+> ^P8UFCIK5aJNZ49HIAg5383243
+
+> [!cite]+ [Fermeture (informatique)](zotero://select/groups/5383243/items/ZKL3R2ZE) - [Page ](zotero://open-pdf/groups/5383243/items/JNZ49HIA?annotation=N5UF45WT)
+> Une fermeture peut être passée en argument d'une fonction dans l'environnement où elle a été créée (passée vers le bas) ou renvoyée comme valeur de retour (passée vers le haut). Dans ce cas, le problème posé alors par la fermeture est qu'elle fait référence à des données qui auraient typiquement été allouées sur la pile d'exécution et libérées à la sortie de l'environnement. Hors optimisations par le compilateur, le problème est généralement résolu par une allocation sur le tas de l'environnement.
+> 
+> > [!note] Notes
+> > Le passage *vers le haut* d'une fermeture demande l'accès à des données qui sont libéréres de la pile d'exécution.
+> > Cela est résolu par une allocation sur le tas.
+> ^N5UF45WTaJNZ49HIAg5383243
--- a/sources/zotero/FonctionOrdreSuperieur2023.md
+++ b/sources/zotero/FonctionOrdreSuperieur2023.md
@@ -0,0 +1,17 @@
+---
+zotero-key: NPLAN6RUg5383243
+zt-attachments:
+  - "203"
+citekey: FonctionOrdreSuperieur2023
+---
+up:: [[zotero literature notes]]
+link:: [Zotero](zotero://select/groups/5383243/items/NPLAN6RU) [attachment](<file:///Users/oscarplaisant/Zotero/storage/94RE4PDX/Fonction_d'ordre_sup%C3%A9rieur.html>)
+#pkm #zotero
+
+
+> [!cite]+ [Fonction d'ordre supérieur](zotero://select/groups/5383243/items/NPLAN6RU) - [Page ](zotero://open-pdf/groups/5383243/items/94RE4PDX?annotation=YZKT9G5G)
+> En mathématiques et en informatique, les fonctions d'ordre supérieur sont des fonctions qui ont au moins une des propriétés suivantes :
+> 
+> elles prennent une ou plusieurs fonctions en entrée ;
+> elles renvoient une fonction.
+> ^YZKT9G5Ga94RE4PDXg5383243
--- a/sources/zotero/ProgrammingParadigms.md
+++ b/sources/zotero/ProgrammingParadigms.md
@@ -2,14 +2,14 @@
 zotero-key: XUWRH447g5383243
 zt-attachments:
  - "139"
-citekey: ProgrammingParadigms
+citekey: toalProgrammingParadigms
 ---
 up:: [[zotero literature notes]]
 link:: [Zotero](zotero://select/groups/5383243/items/XUWRH447) [attachment](file:///Users/oscarplaisant/Zotero/storage/LQGLTH3D/paradigms.html)
 #pkm #zotero


-> [!cite] [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=QVDN27WM)
+> [!cite]+ [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=QVDN27WM)
 > Control flow in imperative programming is explicit: commands show how the computation takes place, step by step. Each step affects the global state of the
 > computation.
 > 
@@ -20,7 +20,7 @@ link:: [Zotero](zotero://select/groups/5383243/items/XUWRH447) [attachment](file
 > > - chaque pas affecte l'état global du calcul
 > ^QVDN27WMaLQGLTH3Dg5383243

-> [!cite] [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=SW38ETVU)
+> [!cite]+ [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=SW38ETVU)
 > Structured programming is a kind of imperative programming where control flow is defined by nested loops, conditionals, and subroutines, rather than via gotos. Variables are generally local to blocks (have lexical scope).
 > 
 > > [!note] Notes
@@ -29,14 +29,14 @@ link:: [Zotero](zotero://select/groups/5383243/items/XUWRH447) [attachment](file
 > > - variables généralement locales à un block
 > ^SW38ETVUaLQGLTH3Dg5383243

-> [!cite] [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=KRIHCS5Q)
+> [!cite]+ [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=KRIHCS5Q)
 > OOP is based on the sending of messages to objects. Objects respond to messages by performing operations, generally called methods. Messages can have arguments. A society of objects, each with their own local memory and own set of operations has a different feel than the monolithic processor and single shared memory feel of non object oriented languages.
 > 
 > > [!note] Notes
 > > OOP : basé sur l'envoi de messages à des objets.
 > ^KRIHCS5QaLQGLTH3Dg5383243

-> [!cite] [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=3SBD24AE)
+> [!cite]+ [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=3SBD24AE)
 > Control flow in declarative programming is implicit: the programmer states only what the result should look like,
 > not how to obtain it.
 > 
@@ -46,10 +46,10 @@ link:: [Zotero](zotero://select/groups/5383243/items/XUWRH447) [attachment](file
 > > on déclare ce que le résultat doit être plutôt que comment l'obtenir.
 > ^3SBD24AEaLQGLTH3Dg5383243

-> [!cite] [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=8L7P34B2)
+> [!cite]+ [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=8L7P34B2)
 > In functional programming, control flow is expressed by combining function calls, rather than by assigning values to variables:
 > ^8L7P34B2aLQGLTH3Dg5383243

-> [!cite] [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=JRBMX3NW)
+> [!cite]+ [Programming Paradigms](zotero://select/groups/5383243/items/XUWRH447) - [Page ](zotero://open-pdf/groups/5383243/items/LQGLTH3D?annotation=JRBMX3NW)
 > Logic programming and constraint programming are two paradigms in which programs are built by setting up relations that specify facts and inference rules, and asking whether or not something is true (i.e. specifying a goal.) Unification and backtracking to find solutions (i.e.. satisfy goals) takes place automatically.
 > ^JRBMX3NWaLQGLTH3Dg5383243
--- a/sources/zotero/abelsonStructureInterpretationComputer1996.md
+++ b/sources/zotero/abelsonStructureInterpretationComputer1996.md
@@ -0,0 +1,19 @@
+---
+zotero-key: BKPQ7QSMg5383243
+zt-attachments:
+  - "168"
+citekey: abelsonStructureInterpretationComputer1996
+---
+up:: [[zotero literature notes]]
+link:: [Zotero](zotero://select/groups/5383243/items/BKPQ7QSM) [attachment](<file:///Users/oscarplaisant/Zotero/storage/KNH433ZX/Abelson%20et%20Sussman%20-%20Structure%20and%20Interpretation%20of%20Computer%20Programs.pdf>)
+#pkm #zotero
+
+
+> [!cite]+ [Structure and Interpretation of Computer Programs](zotero://select/groups/5383243/items/BKPQ7QSM) - [Page 28](zotero://open-pdf/groups/5383243/items/KNH433ZX?page=56&annotation=88QKQ5JP)
+> The contrast between function and procedure is a reﬂection of the general distinction between describing properties of things and describing how to do things, or, as it is sometimes referred to, the distinction between declarative knowledge and imperative knowledge. In mathematics we are usually concerned with declarative (what is) descriptions, whereas in computer science we are usually concerned with imperative (how to) descriptions.
+> 
+> > [!note] Notes
+> > fonction : connaissance déclarative
+> > procédure : connaissance impérative
+> ^88QKQ5JPaKNH433ZXg5383243p56
+
--- a/sources/zotero/hughesWhyFunctionalProgramming1989.md
+++ b/sources/zotero/hughesWhyFunctionalProgramming1989.md
@@ -0,0 +1,32 @@
+---
+zotero-key: 6RZUZSFRg5383243
+zt-attachments:
+  - "193"
+citekey: hughesWhyFunctionalProgramming1989
+---
+up:: [[zotero literature notes]]
+link:: [Zotero](zotero://select/groups/5383243/items/6RZUZSFR) [attachment](<file:///Users/oscarplaisant/Zotero/storage/H9SGRTMQ/Hughes%20-%201989%20-%20Why%20Functional%20Programming%20Matters.pdf>)
+#pkm #zotero
+
+
+> [!cite]+ [Why Functional Programming Matters](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 1](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=1&annotation=WSXGN3RM)
+> ![[images/zotero/5383243WSXGN3RM.png]]
+> 
+> > [!note] Notes
+> > programme écrit comme des fonctions qui reçoivent l'entrée en argument et renvoie le résultat.
+> ^WSXGN3RMaH9SGRTMQg5383243p1
+
+> [!cite]+ [Why Functional Programming Matters](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 1](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=1&annotation=58PSUPND)
+> ![[images/zotero/538324358PSUPND.png]]
+> ^58PSUPNDaH9SGRTMQg5383243p1
+
+> [!cite]+ [Why Functional Programming Matters](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 2](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=2&annotation=3TVGD5RH)
+> ![[images/zotero/53832433TVGD5RH.png]]
+> ^3TVGD5RHaH9SGRTMQg5383243p2
+
+> [!cite]+ [Why Functional Programming Matters](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 2](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=2&annotation=Y7Z762JM)
+> ![[images/zotero/5383243Y7Z762JM.png]]
+> 
+> > [!note] Notes
+> > Pour augmenter la capacité à modulariser, il faut augmenter les types de colle disponibles.
+> ^Y7Z762JMaH9SGRTMQg5383243p2
--- a/sources/zotero/minskyFormContentComputer1970.md
+++ b/sources/zotero/minskyFormContentComputer1970.md
@@ -0,0 +1,21 @@
+---
+zotero-key: FJG2FWGGg5383243
+zt-attachments:
+  - "175"
+citekey: minskyFormContentComputer1970
+---
+up:: [[zotero literature notes]]
+link:: [Zotero](zotero://select/groups/5383243/items/FJG2FWGG) [attachment](<file:///Users/oscarplaisant/Zotero/storage/H39XI9D9/Minsky%20-%201970%20-%20Form%20and%20Content%20in%20Computer%20Science%20(1970%20ACM%20turing%20lecture).pdf>)
+#pkm #zotero
+
+
+> [!cite]+ [Form and Content in Computer Science (1970 ACM turing lecture)](zotero://select/groups/5383243/items/FJG2FWGG) - [Page 5](zotero://open-pdf/groups/5383243/items/H39XI9D9?page=5&annotation=JHPJBREL)
+> Here, the function names come immediately inside their parentheses. The clumsi- ness, for humans, of writing all the parentheses is evident; the advantages of not h~ving to learn all the conventions, such as that (X + A ÷ X) is (+ X (÷ A X)) a n d not (÷ (+ X A) X), is often overlooked.
+> ^JHPJBRELaH39XI9D9g5383243p5
+
+> [!cite]+ [Form and Content in Computer Science (1970 ACM turing lecture)](zotero://select/groups/5383243/items/FJG2FWGG) - [Page 9](zotero://open-pdf/groups/5383243/items/H39XI9D9?page=9&annotation=CCMAKXHC)
+> - To help people learn is to help them build, in their heads, various kinds of computational models.
+> - This can best be done by a teacher who has, in his head, a reasonable model of what is in the pupil's head.
+> - For the same reason the student, when debugging his own models and procedures, should have a model of what he is doing, and must know good debugging techniques, such as how to formulate simple but critical test cases.
+> - It will help the student to know something about computational models and programming. The idea of debugging itself, for example, is a very powerful concept - in contrast to the helplessness promoted by our cultural heritage about gifts, talents, and aptitudes. The latter encourages "I'm not good at this" instead of "How can I make myself better at it?"
+> ^CCMAKXHCaH39XI9D9g5383243p9
--- a/sources/zotero/royProgrammingParadigmsDummies.md
+++ b/sources/zotero/royProgrammingParadigmsDummies.md
@@ -9,7 +9,7 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 #pkm #zotero


-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 10](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=2&annotation=2294PTUD)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 10](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=2&annotation=2294PTUD)
 > A programming paradigm is an approach to programming a computer based on a mathematical theory or a coherent set of principles.
 > 
 > > [!note] Notes
@@ -18,25 +18,29 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 > > - chaque paradigme est défini à partir de principes de base (éventuellement une théorie mathématique)
 > ^2294PTUDaP4L4LCJZg5383243p2

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 10](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=2&annotation=4LQTA3Q8)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 10](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=2&annotation=4LQTA3Q8)
 > Each paradigm supports a set of concepts that makes it the best for a certain kind of problem. For example, object-oriented programming is best for problems with a large number of related data abstractions organized in a hierarchy. Logic programming is best for transforming or navigating complex symbolic structures according to logical rules. Discrete synchronous programming is best for reactive problems, i.e., problems that consist of reactions to sequences of external events.
 > 
 > > [!note] Notes
 > > Les concepts supportés par les différents paradigmes les rendent adaptés pour la résolution de différents problèmes.
 > ^4LQTA3Q8aP4L4LCJZg5383243p2

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 10](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=2&annotation=4YR7745Q)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 10](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=2&annotation=4YR7745Q)
 > A language should ideally support many concepts in a well-factored way, so that the programmer can choose the right concepts whenever they are needed without being encumbered by the others.
 > 
 > > [!note] Notes
 > > Les langages devraient tous être multiparadigmes, pour pouvoir choisir les bons concepts en fonction du problème.
 > ^4YR7745QaP4L4LCJZg5383243p2

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 13](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=5&annotation=RSNADR57)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 13](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=5&annotation=RSNADR57)
 > Figure 2. Taxonomy of programming paradigms
 > ^RSNADR57aP4L4LCJZg5383243p5

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 14](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=6&annotation=DCATKHXK)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 13](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=5&annotation=97T2RAYP)
+> This explains why functional programming is so important: it is based on the concept of ﬁrst-class function, or closure, which makes it equivalent to the λ-calculus which is Turing complete.
+> ^97T2RAYPaP4L4LCJZg5383243p5
+
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 14](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=6&annotation=DCATKHXK)
 > nondeterminism is when the execution of a program is not completely determined by its speciﬁcation, i.e., at some point during the execution the speciﬁcation allows the program to choose what to do next. During the execution, this choice is made by a part of the run-time system called the scheduler
 > 
 > > [!note] Notes
@@ -44,25 +48,25 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 > > cela implique que le programme "choisit" ce qu'il doit faire parfois.
 > ^DCATKHXKaP4L4LCJZg5383243p6

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 14](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=6&annotation=BIUNAM6V)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 14](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=6&annotation=BIUNAM6V)
 > We conclude that observable nondeterminism should be supported only if its expressive power is needed.
 > 
 > > [!note] Notes
 > > C'est le pouvoir d'expression apporté qui peut justifier d'accepter certains problèmes de certains paradigmes.
 > ^BIUNAM6VaP4L4LCJZg5383243p6

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 14](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=6&annotation=RSLMGUYK)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 14](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=6&annotation=RSLMGUYK)
 > State is the ability to remember information, or more precisely, to store a sequence of values in time.
 > ^RSLMGUYKaP4L4LCJZg5383243p6

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 16](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=8&annotation=SVNS3KNF)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 16](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=8&annotation=SVNS3KNF)
 > Concepts are not combined arbitrarily to form paradigms. They can be organized according to the creative extension principle. This principle was ﬁrst deﬁned by Felleisen [18] and independently rediscovered in [50].
 > 
 > > [!note] Notes
 > > Le principe de l'*extension créative* permet d'organiser les concepts pour former réellement un paradigme.
 > ^SVNS3KNFaP4L4LCJZg5383243p8

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 17](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=9&annotation=VAZ8DBMA)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 17](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=9&annotation=VAZ8DBMA)
 > If we need to model updatable memory, that is, entities that remember and update their past, then we will have to add two arguments to all function calls relative to that entity. The arguments represent the input and output values of the memory. This is unwieldy and it is also not modular because the memory travels throughout the whole program. All this clumsiness is unnecessary if we add one concept to the language: named state.
 > 
 > > [!note] Notes
@@ -71,14 +75,14 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 > > Cela évite d'avoir à ajouter des arguments à toutes les fonctions qui utilisent cet état.
 > ^VAZ8DBMAaP4L4LCJZg5383243p9

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 17](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=9&annotation=NKKRZRU4)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 17](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=9&annotation=NKKRZRU4)
 > If we need to model error detection and correction, in which any function can detect an error at any time and transfer control to an error correction routine, then we need to add error codes to all function outputs and conditionals to test all function calls for returned error codes. All this complexity is unnecessary if we add one concept to the language: exceptions.
 > 
 > > [!note] Notes
 > > les exceptions sont une solution efficace pour éviter d'avoir à gérer soi-même les codes d'erreurs, leur propagation etc.
 > ^NKKRZRU4aP4L4LCJZg5383243p9

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 17](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=9&annotation=6ZNVVQGI)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 17](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=9&annotation=6ZNVVQGI)
 > The common theme in these three scenarios (and many others!) is that we need to do pervasive (nonlocal) modiﬁcations of the program in order to handle a new concept. If the need for pervasive modiﬁcations manifests itself, we can take this as a sign that there is a new concept waiting to be discovered. By adding this concept to the language we no longer need these pervasive modiﬁcations and we recover the simplicity of the program.
 > 
 > > [!note] Notes
@@ -87,7 +91,7 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 > > ajouter ce concept au langage => éviter les modifications envahissantes => retrouver la simplicité
 > ^6ZNVVQGIaP4L4LCJZg5383243p9

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 18](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=10&annotation=242M9EKU)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 18](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=10&annotation=242M9EKU)
 > Prolog: The ﬁrst paradigm is a logic programming engine based on uniﬁcation and depth-ﬁrst search. The second paradigm is imperative: the assert and retract operations which allow a program to add and remove program clauses.
 > 
 > > [!note] Notes
@@ -97,7 +101,7 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 > > - programmation impérative (ajout et rétraction de clauses)
 > ^242M9EKUaP4L4LCJZg5383243p10

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 18](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=10&annotation=TPDCZ85D)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 18](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=10&annotation=TPDCZ85D)
 > Modeling languages (e.g., Comet, Numerica [48]): The ﬁrst paradigm is a solver: constraint programming (see Section 7), local search (see the chapter by Philippe Codognet [8]), satisﬁability (SAT solvers), and so forth. The second paradigm is object-oriented programming.
 > 
 > > [!note] Notes
@@ -106,14 +110,14 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 > > - OOP
 > ^TPDCZ85DaP4L4LCJZg5383243p10

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 18](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=10&annotation=TN6TDYPD)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 18](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=10&annotation=TN6TDYPD)
 > Solving libraries (e.g., Gecode): The ﬁrst paradigm is a solver library based on advanced search algorithms, such as Gecode [43, 47]. The second paradigm is added by the host language, e.g., C++ and Java support object-oriented programming.
 > 
 > > [!note] Notes
 > > certaines librairies peuvent ajouter un paradigme à un langage (comme les librairies de *solver*).
 > ^TN6TDYPDaP4L4LCJZg5383243p10

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 18](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=10&annotation=E7N7DG39)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 18](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=10&annotation=E7N7DG39)
 > Language embedding (e.g., SQL): SQL already supports two paradigms: a relational programming engine for logical queries of a database and a transactional interface for concurrent updates of the database. The host language complements this by supporting object-oriented programming, for organization of large programs. This example goes beyond two paradigms to show a design with three complementary paradigms.
 > 
 > > [!note] Notes
@@ -122,15 +126,15 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 > > exemple : SQL supporte le paradigme relationnel, et le paradigme par transactions. Il peut être intégré dans un langage objet.
 > ^E7N7DG39aP4L4LCJZg5383243p10

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 19](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=11&annotation=X8JQ43BW)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 19](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=11&annotation=X8JQ43BW)
 > Erlang Programming highly available embedded systems for telecommunications. This project was undertaken by Joe Armstrong and his colleagues at the Ericsson Computer Science Laboratory starting in 1986. The Erlang language was designed and a ﬁrst eﬃcient and stable implementation was completed in 1991 [5, 6]. An Erlang program consists of isolated named lightweight processes that send each other messages. Because of the isolation, Erlang programs can be run almost unchanged on distributed systems and multi-core processors. The Erlang system has a replicated database, Mnesia, to keep global coherent states. Erlang and its programming platform, the OTP (Open Telecom Platform) system, are being used successfully in commercial systems by Ericsson and other companies [57, 17].
 > ^X8JQ43BWaP4L4LCJZg5383243p11

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 19](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=11&annotation=CBQAJDG2)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 19](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=11&annotation=CBQAJDG2)
 > E Programming secure distributed systems with multiple users and multiple security domains. This project was undertaken over many years by diﬀerent institutions. It started with Dennis and Van Horn’s capability model in 1965 [13] and Carl Hewitt’s Actor model in 1973 [24] and it led via concurrent logic programming to the E language designed by Doug Barnes, Mark Miller, and their colleagues [32, 31]. Predecessors of E have been used to implement various multiuser virtual 19 Peter Van Roy environments. An E program consists of isolated single-threaded vats (processes) hosting active objects that send each other messages. Deterministic concurrency is important in E because nondeterminism can support a covert channel.
 > ^CBQAJDG2aP4L4LCJZg5383243p11

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 23](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=15&annotation=8QWDQKJU)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 23](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=15&annotation=8QWDQKJU)
 > A record is a data structure: a group of references to data items with indexed access to each item.
 > 
 > > [!note] Notes
@@ -138,13 +142,45 @@ link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment](<fil
 > > enregistrement = concept derrière le dictionnaire
 > ^8QWDQKJUaP4L4LCJZg5383243p15

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 23](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=15&annotation=E7BNJFPV)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 23](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=15&annotation=E7BNJFPV)
 > A symbolic programming language is able to calculate with records: create new records, decompose them, and examine them.
 > 
 > > [!note] Notes
 > > programmation symbolique => calculer avec des enregistrements
 > ^E7BNJFPVaP4L4LCJZg5383243p15

-> [!cite] [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 23](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=15&annotation=LVLX8ZD6)
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 23](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=15&annotation=LVLX8ZD6)
 > Many important data structures such as arrays, lists, strings, trees, and hash tables can be derived from records.
 > ^LVLX8ZD6aP4L4LCJZg5383243p15
+
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 24](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=16&annotation=BRVCUS8M)
+> From an implementation viewpoint, a closure combines a procedure with its external references (the references it uses at its deﬁnition).
+> 
+> > [!note] Notes
+> > fermeture = combiner une fonction avec ses références externes
+> ^BRVCUS8MaP4L4LCJZg5383243p16
+
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 24](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=16&annotation=6H6T7X9L)
+> From the programmer’s viewpoint, a closure is a “packet of work”: a program can transform any instructions into a closure at one point in the program, pass it to another point, and decide to execute it at that point. The result of its execution is the same as if the instructions were executed at the point the closure was created.
+> 
+> > [!note] Notes
+> > fermeture := permet que le résultat soit le même que si les instructions étaient éxécutées à l'endroit où la fermeture à été créée.
+> ^6H6T7X9LaP4L4LCJZg5383243p16
+
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 24](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=16&annotation=F2A5ZRPP)
+> We have separated the deﬁnition of <stmt> from its execution. With this ability we can deﬁne control structures such as an if statement or while loop.
+> 
+> > [!note] Notes
+> > Les fermetures permettent de définir les structures de contrôle (`if`, `while`...).
+> ^F2A5ZRPPaP4L4LCJZg5383243p16
+
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 24](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=16&annotation=Z3JJ32SZ)
+> Instantiation and genericity, normally associated with object-oriented programming, can be done easily by writing functions that return other functions. In object-oriented programming the ﬁrst function is called a “class” and the second is called an “object”.
+> 
+> > [!note] Notes
+> > les fermetures permettent l'instantiation et la généricité, en définissant des fonctions d'ordre supérieur (qui retournent d'autres fonctions).
+> ^Z3JJ32SZaP4L4LCJZg5383243p16
+
+> [!cite]+ [Programming Paradigms for Dummies: What Every Programmer Should Know](zotero://select/groups/5383243/items/673TMQRT) - [Page 25](zotero://open-pdf/groups/5383243/items/P4L4LCJZ?page=17&annotation=DEJEICNP)
+> Separation of concerns, normally associated with aspect-oriented programming, can be done easily by writing functions that take other functions as arguments. For example, Erlang has a function that implements a generic fault-tolerant client/server. It is called with a function argument that deﬁnes the server’s behavior. Aspectoriented programming in object-oriented languages is explained in the chapter by Pierre Cointe [9]. It is usually done by syntactic transformations
+> ^DEJEICNPaP4L4LCJZg5383243p17