cours/Remplissage du plan de L3.md

up:: plan du mémoire de L3 #informatique #fac

Introduction

!mémoire de L3#^abstract

Sommaire

• #qu'est-ce qu'un paradigme
• #Concepts importants
  • #Concepts importants#Fonction et procédure
  • #Concepts importants#Fermeture
• #les principaux paradigmes
  • #les principaux paradigmes#programmation déclarative
  • #les principaux paradigmes#programmation fonctionnelle
• #les langages multi-paradigmes
• #Définition de la puissance d'expression
  • #Définition de la puissance d'expression#Au sens formel
  • #Définition de la puissance d'expression#Au sens commun
  • #Définition de la puissance d'expression#compromis expressivité vs analysabilité
    • #compromis expressivité vs analysabilité#Exemple de compromis : automates et grammaires
• #contre la distinction entre les paradigmes
  • #contre la distinction entre les paradigmes#Les paradigmes sont des courants de pensée
  • #contre la distinction entre les paradigmes#Les paradigmes sont tous équivalents
• #avantages de la diversité
• #problèmes de la diversité
• #diversité des approches
• #créer un paradigme pour chaque type de problème
• #avantages des langages multi-paradigme

Définition et concepts importants

qu'est-ce qu'un paradigme

Un paradigme de programmation est une façon d'approcher la programmation et de formuler les problèmes et leurs formalisation dans un langage de programmation. En particulier, un paradigme fournit et détermine comment un développeur doit voir un programme. La notion de paradigme est notamment à dissocier de celles de méthode ou bien de design patterns, qui décrivent comment traîter des problèmes spécifiques et reconnus, et comment aboutir à une solution conceptuelle. Un paradigme est un concept plus "haut niveau", c'est-à-dire plus abstrait : chaque paradigme supporte un ensemble particulier de concepts (cohérents entre eux), qui peuvent être hérités d'une théorie mathématique, de principes fondamentaux, ou bien d'une vision sur ce que doit être la programmation.

!paradigme de programmation#^definition

[!cite]- Programming Paradigms for Dummies: What Every Programmer Should Know - Page 10 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]- Paradigme (programmation) - Page Le paradigme de programmation est la façon (parmi d'autres) d'approcher la programmation informatique et de formuler les solutions aux problèmes et leur formalisation dans un langage de programmation approprié[1]. Ce n'est pas de la méthodologie contenant une méthode ; cette dernière organise le traitement des problèmes reconnus dans l'écosystème concerné pour aboutir à la solution conceptuelle et programme exécutable. ^FZJDRZRQaPYQD2DCXg5383243

[!cite]- Programming Paradigms for Dummies: What Every Programmer Should Know - Page 10 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

Un paradigme de programmation est souvent principalement décrit par les concepts qu'il implémente ou non. C'est notamment cette approche qu'emploie la taxonomie des paradigmes de programmation présentée dans l'article royProgrammingParadigmsDummies (faire une référence à une annexe).

[!cite]+ Une taxonomie des principaux paradigmes de programmation - Page Une taxonomie des principaux paradigmes de programmation

[!note] Notes taxonomie des langages de programmation (poster en français) ^KP3KB62EaTFPQ3W8Gg5383243

Cependant, J.Huges, dans son article "Why Functional Programming Matters", fustige le fait que certains paradigmes (notamment la programmation fonctionnelle ref et la programmation structurée ref) sont trop souvent définis en termes des fonctionnalités qu'il n'implémentent pas, ou des contraintes qu'il posent ("It says a lot about what functional programming is not [...] but not much about what it is."). Cela est problématique car l'absence d'une fonctionnalité ne peut pas expliquer pourquoi un paradigme serait plus intéressant dans certains cas ("It is a logical impossibility to make a language more powerful by ommitting features, no matter how bad they may be"). L'auteur insiste donc sur le fait que les paradigmes devraient être définis en fonction des avantages structurels qu'il apportent pour résolution de certains types de problèmes.

C'est pour cette raison que, dans notre définition des différents paradigmes, nous chercherons à expliquer à la fois les principes fondamentaux de chaque paradigme, mais également à montrer brièvement pourquoi ceux-ci sont intéressants, c'est-à-dire répondre à la question "en quoi ce paradigme apporte-t-il quelque chose". Cela constituera une première partie de réponse

[!cite]- Why Functional Programming Matters - Page 1 Such a catalogue of 'advantages' is all very#ell, but one must not be surprised if outsiders don't take it too seriously. It says a lot about what functional programming is not (it has no assignment, no side-effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. ^2QS3SA82aH9SGRTMQg5383243p1

[!cite]- Why Functional Programming Matters - Page 1 Functional programmers argue that there are great material benefits - that a functional programmer is an order of magnitude more productive than his conventional counterpart, because functional programs are an order of magnitude shorter. Yet why should this be? The only faintly plausible reason one can suggest on the basis of these 'advantages' is that conventional programs consist of 90% assignment statements, and in functional programs these can be omitted! This is plainly ridiculous. If omittin assignment statements brought such enormous benefits then FORTRAN programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omittion features, no matter how bad they may be. ^INFAECYDaH9SGRTMQg5383243p1

Concepts importants

Fonction et procédure

Les termes "fonction" et "procédure" sont, selon les contextes et les auteurs, utilisés pour désigner différentes choses, ou bien la même chose.

Par exemple, le livre abelsonStructureInterpretationComputer1996 fournit la distinction suivante : Les fonctions sont l'aspect mathématique du concept et sont définies en déclarant "ce qu'elle est" , en donnant des propiétés de cette fonction (une définition déclarative, voir Remplissage du plan de L3#programmation déclarative). Les procédures sont l'aspect programmatique du concept, et sont définies en déclarant "comment elle doit faire", en décrivant comment elle doit s'exécuter.

[!cite]+ Structure and Interpretation of Computer Programs - Page 28 The contrast between function and procedure is a reflection 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

Cependant, certains auteurs utilisent le terme procedure même pour parler du concept théorique et mathématique (qui se rapproche du lambda-calcul) (par exemple Fellesein dans "On the expressive power of programming languages" ref).

[!cite]+ On the expressive power of programming languages - Page 135 (let x be v in e) is expressible as (apply (procedure x e) v). ^SRALKQCMaTY878EW8g5383243p2

Nous utiliserons donc principalement le terme fonction, avec les définitions suivantes :

[!definition] fonction Une fonction est l'encapsulation d'un ensemble d'instructions. Une fonction peut posséder des paramètres qui peuvent influencer son exécution. Ces paramètres sont des valeurs ou des références qui sont données ("passées en argument") lors de l'appel de cette fonction. Une fonction peut retourner une valeur.

[!definition] fonction pure Une fonction pure est une fonction déterministe, c'est-à-dire que les mêmes arguments donnent toujours la même valeur de retour. Une fonction pure est une fonction sans effet de bord, c'est-à-dire qu'elle ne modifie pas l'état du système (en dehors de son champ local propre, dont la durée de vie est limitée).

[!cite]+ Function (computer programming) - Page In computer programming, a function, subprogram, procedure, method, routine or subroutine is a callable unit[1] that has a well-defined behavior and can be invoked by other software units to exhibit that behavior. ^GNQR9GC2aRIAPAJ6Eg5383243

Fermeture

Une fermeture (de l'anglais closure) est une fonction à laquelle on attache l'environnement local de l'endroit où elle à été définie. Cela permet à cette fonction d'accéder aux valeurs et aux références de cet environnement local, même si elle est appelée depuis un autre contexte (dans un autre champ local). Du point de vue du développeur, cela signifie que l'exécution d'une fermeture soit le même que si les instructions étaient exécutées "à l'endroit" (dans le contexte où) la fermeture à été créée.

[!cite]- Programming Paradigms for Dummies: What Every Programmer Should Know - Page 24 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 - Page 24 From an implementation viewpoint, a closure combines a procedure with its external references (the references it uses at its definition).

[!note] Notes fermeture = combiner une fonction avec ses références externes ^BRVCUS8MaP4L4LCJZg5383243p16

[!cite]- Fermeture (informatique) - Page 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

Un avantage considérable des fermetures est qu'elles permettent d'accéder aux valeurs et références d'un environnement local qui n'existe plus (car il à été libéré de la pile d'exécution) : "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." (ref FermetureInformatique2024).

[!cite]- Fermeture (informatique) - Page 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

les principaux paradigmes

taxonomie des paradigmes de programmation

programmation déclarative

La programmation déclarative est un paradigme de programmation dans lequel la définition des programme se fait en déclarant la forme du résultat plutôt que la manière l'obtenir (comme en paradigme programmation impérative). Le développeur ne s'occupe donc pas de l'exécution, mais plutôt de comment spécifier le résultat.

[!cite]- Programming Paradigms - Page Control flow in declarative programming is implicit: the programmer states only what the result should look like, not how to obtain it.

[!note] Notes déclaratif : le flot de contrôle est implicite. on déclare ce que le résultat doit être plutôt que comment l'obtenir. ^3SBD24AEaLQGLTH3Dg5383243

La programmation déclarative est un paradigme très général (qui englobe beaucoup de langages différents), et peut même être vue comme un spectre : certains languages étant plus ou moins déclaratifs (taxonomie des paradigmes de programmation ref). Cette vision de la programmation déclarative comme spectre (plutôt que comme une propriété simplement présente ou absente) permet d'envisager des nuances entre certains paradigmes.

Par exemple, la programmation purement impérative nécessite de penser constamment à l'exécution concrête de notre programme, puisqu'aucune abstraction n'est présente. Cependant, des paradigmes comme la programmation orientée objet permettent, par l'encapsulation

programmation fonctionnelle

La programmation fonctionnelle est un paradigme de programmation dans lequel les programmes sont exprimés comme des arbres d'expressions.

Le contrôle du flot d'exécution est donc fait en combinant des fonctions : la fonction principale prends en argument l'entrée du problème, puis elle est définit a partir d'autres fonctions, qui sont elles-même définies à partir de fonctions, et ce jusqu'à ce que les fonctions à la base de la définition (les feuilles de l'arbre d'expressions) soient des primitives du langages, ou bien des constantes. Cela distingue la programmation fonctionnelle d'autres paradigmes, notamment en programmation impérative, où l'état est beaucoup plus utilisé, notamment pour le contrôle du flot d'exécution.

[!definition] programmation fonctionnelle La programmation fonctionnelle est un paradigme de programmation dans lequel :

• les programmes sont exprimés comme des arbres d'expressions
• le contrôle de flot est fait en combinant des fonctions plutôt qu'en assignant des valeurs
  • utiliser des fonction d'ordre supérieur
  • ne pas utiliser d'programmation.état
  • ne pas utiliser d'entrée/sortie cachée (en sortant du champ local)
• les fonctions sont (le plus souvent, le plus possible) fonction pure (limiter au maximum / complètement programmation.effet de bord) ^definition

[!cite]+ Programming Paradigms - Page In functional programming, control flow is expressed by combining function calls, rather than by assigning values to variables: ^8L7P34B2aLQGLTH3Dg5383243

[!cite]+ What Is Functional Programming? - Page Functional programming is about writing pure functions, about removing hidden inputs and outputs as far as we can, so that as much of our code as possible just describes a relationship between inputs and outputs. ^IU2KWY7La8P4TX53Jg5383243

[!cite]- Why Functional Programming Matters - Page 1 !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

Les fonction d'ordre supérieur sont centrales en programmation fonctionnelle. Les fonctions d'ordre supérieur sont des fonctions qui prennent en argument, ou renvoient d'autres fonctions. Ces fonctions d'ordre supérieur (aussi appelées "fonctionnelles") permettent donc de modifier ou combiner entre elles des primitives du langages, des fonctiosn

[!cite]- Fonction d'ordre supérieur - Page 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

programmation orientée objet

• impératif
  • procédural
  • orienté objet
• fonctionnel
  • fonctionnel pur
• programmation structurée

les langages multi-paradigmes

[!cite] Programming Paradigms for Dummies: What Every Programmer Should Know - Page 10 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

Définition de la puissance d'expression

[!cite]+ Expressive power (computer science) - Page 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) - Page 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) - Page 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)

^UL4ZYIV6aQ9KCGU98g5383243

Au sens formel

!expressivité théorique

Tous les paradigmes sont équivalent puisqu'ils sont tous turing-complets en fait non :

• nuance : les langages descriptifs (XML, HTML, JSON...)
• languages de markup : non turing-complets mais intéressants quand même

Au sens commun

!expressivité pratique#^definition

compromis expressivité vs analysabilité

Plus un langage est expressif, plus il est complexe de l'analyser mathématiquement.

• expressivité théorique : plus un formalisme peut exprimer d'idées, plus il est complexes de démontrer des théorèmes sur ce formalisme
  • en général : plus un formalisme est complexe, plus les problèmes de décision sont durs à résoudre, voir indécidables
  • exemple : si un langage est turing-complet, alors le problème de l'arrêt est indécidable sur ce langage

[!cite]+ Paradigme (programmation) - Page Cependant, le fait d’éviter certaines techniques peut permettre de rendre plus aisée la démonstration de théorèmes sur la correction d’un programme — ou simplement la compréhension de son fonctionnement — sans limiter la généralité du langage de programmation. ^LMVQE7BZaPYQD2DCXg5383243

[!cite]+ Expressive power (computer science) - Page 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

Exemple de compromis : automates et grammaires

• les automates à pile sont moins expressifs que les machines de Turing
  • les automates à pile reconnaissent exactement les grammaires non-contextuelles
  • les machines de Turing reconnaissent les langages récursivement énumérables
• les automates à pile ont un formalisme plus pratique (certains théorèmes sont plus définis)
  • le problème qui demande si un mot est reconnu par un automate à pile est décidable
  • le problème qui demande si un mot est reconnu par une machine de Turing est indécidable

On voit donc que les machines de Turing sont un formalisme plus expressif (certains concepts exprimés par des machines de Turing ne sont pas exprimables par des automates à pile) mais que certains problèmes deviennent indécidables sur ce formalisme (alors qu'ils le sont sur les automates à pile).

[!cite]+ Hiérarchie de Chomsky - Page Les langages produits, appelés langages contextuels ou sensibles au contexte, sont exactement ceux reconnus par une machine de Turing non déterministe à mémoire linéairement bornée, appelés couramment automates linéairement bornés.

[!note] Notes les grammaires contextuelles sont reconnues exactement par les automates linéairement bornés (machines de Turing non déterministe à mémoire linéairement bornée) ^Z2Q99QE4aGTNGMUQLg5383243

[!cite]+ Hiérarchie de Chomsky - Page Ces grammaires engendrent exactement les langages algébriques, appelés aussi langages hors contexte, langages acontextuels, ou langages non contextuels. Ils sont reconnus par un automate à pile.

[!note] Notes en parlant des grammaires non-contextuelles ^2Q8JY698aGTNGMUQLg5383243

[!cite]+ Hiérarchie de Chomsky - Page La classe des langages rationnels (type 3) est incluse strictement dans la classe des langages algébriques (type 2). La classe des langages contextuels (type 1) est incluse strictement dans la classe des langages récursivement énumérables (type 0). L'inclusion de la classe des langages algébriques (type 2) dans la classe des langages contextuels (type 1) doit être précisée car un langage contextuel ne contient jamais le mot vide ε. L'énoncé exact est : Un langage algébrique ne contenant pas le mot vide est un langage contextuel ou, de manière équivalente : Un langage algébrique est un langage contextuel éventuellement augmenté du mot vide.

[!note] Notes implique que les grammaires non-contextuelles on moins d'expressivité que les grammaires contextuelles. ^SL7UL6CYaGTNGMUQLg5383243

[!cite]+ Automate à pile - Page le problème de l'appartenance d'un mot à un langage algébrique est décidable : il existe un algorithme qui, étant donnés la description d'une grammaire non contextuelle et un mot, répond en temps fini à la question de l'appartenance de ce mot au langage défini par cette grammaire (plus précisément, on peut le tester en un temps O(n^{3}) pour un mot de longueur n, grâce à l'algorithme CYK). ^DMXNL4GEaWAETBZDGg5383243

contre la distinction entre les paradigmes

La dinstinction entre les différents paradigmes n'est pas toujours claire : beaucoup de langages sont Remplissage du plan de L3#les langages multi-paradigmes, et certains paradigmes peuvent être utilisés dans presque tous les langages (par exemple, la programmation structurée ref)

Les paradigmes sont des courants de pensée

Certains auteurs considèrent que les paradigmes ne sont pas fondamentalement différents (voir : Remplissage du plan de L3#Au sens formel), mais plutôt que les paradigmes sont des courants de pensée, des traditions dans la programmation, rattachées à des communautés (souvent autour d'un ou plusieurs languages de programmation, par exemple LISP pour la programmation fonctionnelle, ou APL pour la programmation matricielle).

Les paradigmes sont tous équivalents

Greg Michaelson critique la distinction des paradigmes, en expliquant que, lorsqu'on les analyse profondément, les paradigmes sont en fait proche entre-eux .

[!cite]+ The paradigms of programming - Page 2 In computer science, one sees several such communities, each speaking its own language and using its own paradigms. In fact, programming languages typically encourage use of some paradigms and discourage others. ^AK2234X5aWWITR642g5383243p2

[!cite]+ Programming Paradigms, Turing Completeness and Computational Thinking - Page 41 Furthermore, it is not at all clear how programming paradigms are to be characterised and differentiated. Indeed, on closer inspection, apparently disparate programming paradigms are very strongly connected. Rather, they should be viewed as different traditions of a unitary Computer Science paradigm composed of programming languages which are all Turing Complete, complemented by methodologies which may all be subsumed by Computational Thinking.

[!note] Notes il n'y a pas de différence claire entre les paradigmes les paradigmes devraient plutôt être vus comme différentes traditions, sur un même paradigme : l'informatique, composée de langages tous Turing completes. ^V8VHK9N2a6YJZLPLZg5383243p1

Paradigmes dans l'apprentissages

avantages de la diversité

• pour apprendre, il est mieux d'apprendre plusieurs langages
  • car il en existe plusieurs
  • car le fait de connaître différentes approches de la programmation permet de mieux résoudre de nouveaux problèmes
    • on pourra choisir le paradigme adapté à notre problème (voir section résolution de problèmes)
    • on construit des modèles mentaux pour les problèmes

[!cite]+ Form and Content in Computer Science (1970 ACM turing lecture) - Page 9

• 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

[!cite]+ 10 Things Software Developers Should Learn about Learning - Page 81 One key difference between beginners and experts is that experts have seen it all before. Research into chess experts has shown that their primary advantage is their ability to remember and recognize the state of the board.

[!note] Notes L'avantage des experts est d'avoir en mémoire beaucoup de cas, quand les débutants doivent réfléchir pour chaque nouveau cas. ^7WYHBT9DaSQN4T6Z8g5383243p4

[!cite]+ 10 Things Software Developers Should Learn about Learning - Page 81 Experts build up a mental library of patterns ^K2JKSWGEaSQN4T6Z8g5383243p4

[!cite]+ 10 Things Software Developers Should Learn about Learning - Page 81 seeing a variety of programming paradigms will help further. ^2PSW4XYMaSQN4T6Z8g5383243p4

problèmes de la diversité

• problèmes liés au mauvais transfer de connaissances (inter-langages, inter-paradigmes)
• problème simplement parce que le langage que l'on doit utiliser n'implémente pas le paradigme que l'on souhaite
  • solution possible : voir Remplissage du plan de L3#avantages des langages multi-paradigme

[!cite]+ 10 Things Software Developers Should Learn about Learning - Page 84 Knowing multiple languages can be beneficial once they have been mastered, but sometimes transferring knowledge from one programming language to another can lead to faulty knowledge

[!note] Notes le transfert de connaissances d'un langage à un autre peut être avantageux, mais peut aussi créer de la connaissance fausse (si le transfert n'est pas pertinent à ce moment). ^588UCYYDaSQN4T6Z8g5383243p7

Paradigmes pour la résolution de problèmes

diversité des approches

La diversité est utile, de nouveaux paradigmes apportent de nouvelles façons de voir. Langages multi-paradigmes

créer un paradigme pour chaque type de problème

avantages des langages multi-paradigme

Les paradigmes comme outil pour la pensée

Connaître un système de calcul ne permet pas d'immédiatement tout connaître sur son champ d'expressivité Notamment :

• connaître un système de calcul ne permet pas (toujours) de connaître l'ensemble des problèmes décidables de ce système
  • En particulier, les systèmes universels (Turing-complets) : il existe toujours des problèmes indécidables dans de tels modèles (problème de l'arrêt)
  • voir Remplissage du plan de L3#compromis expressivité vs analysabilité

De la même manière, connaître un langage de programmation ne permet pas de savoir immédiatement résoudre tous les problèmes que l'on peut rencontrer. Par exemple, la syntaxe des langages similaires à LISP est très simple et peut être apprise en quelques heures pour certains dialectes. Cependant, connaître la syntaxe complête et le fonctionnement de LISP ne permettra pas de résoudre tout problème : il est également nécessaire d'être capable de "faire le lien" entre un problème et un langage. C'est ce lien que les paradigmes de programmation permettent de faire, soit en donnant explicitement une méthode pour le faire (comme la paradigme programmation structurée), soit en définissant comment le programmeur doit voir les programmes, soit en implémentant certaines fonctionnalités utiles pour gérer certains problèmes.