--- zotero-key: 673TMQRTg5383243 zt-attachments: - "8" citekey: royProgrammingParadigmsDummies --- up:: [[zotero literature notes]] link:: [Zotero](zotero://select/groups/5383243/items/673TMQRT) [attachment]() #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) > A programming paradigm is an approach to programming a computer based on a mathematical theory or a coherent set of principles. > > > [!note] Notes > > Paradigme: approche (éventuellement mathématique) de la programmation > > > > - 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) > 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) > 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) > 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) > nondeterminism is when the execution of a program is not completely determined by its specification, i.e., at some point during the execution the specification 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 > > non-déterminisme = la spécification du programme ne détermine pas complètement le résultat > > 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) > 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) > 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) > Concepts are not combined arbitrarily to form paradigms. They can be organized according to the creative extension principle. This principle was first defined 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) > 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 > > Les *états nommés* sont une solution efficace pour modéliser la mémoire que l'on peut mettre à jour. > > > > 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) > 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) > The common theme in these three scenarios (and many others!) is that we need to do pervasive (nonlocal) modifications of the program in order to handle a new concept. If the need for pervasive modifications 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 modifications and we recover the simplicity of the program. > > > [!note] Notes > > Modification envahissante = signe qu'un nouveau concept peut être découvert > > > > 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) > Prolog: The first paradigm is a logic programming engine based on unification and depth-first search. The second paradigm is imperative: the assert and retract operations which allow a program to add and remove program clauses. > > > [!note] Notes > > prolog supporte 2 paradigmes : > > - programmation logique > > > > - 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) > Modeling languages (e.g., Comet, Numerica [48]): The first paradigm is a solver: constraint programming (see Section 7), local search (see the chapter by Philippe Codognet [8]), satisfiability (SAT solvers), and so forth. The second paradigm is object-oriented programming. > > > [!note] Notes > > Langages de modélisation : supportent 2 paradigmes : > > - programmation par contraintes (avec un solver) > > - 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) > Solving libraries (e.g., Gecode): The first 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) > 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 > > L'intégration d'un langage (embedding) permet de créer une architecture où plusieurs paradigmes complémentaires interagissent. > > > > 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) > 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 first efficient 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) > E Programming secure distributed systems with multiple users and multiple security domains. This project was undertaken over many years by different 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) > A record is a data structure: a group of references to data items with indexed access to each item. > > > [!note] Notes > > enregistrement = un ensemble de références à des données avec un accès indexé > > 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) > 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) > Many important data structures such as arrays, lists, strings, trees, and hash tables can be derived from records. > ^LVLX8ZD6aP4L4LCJZg5383243p15