update
This commit is contained in:
Oscar Plaisant
parent
b2eb62ad98
commit
d4d78b2137
3
.obsidian/community-plugins.json
vendored
3
.obsidian/community-plugins.json
vendored
@ -43,5 +43,6 @@
|
||||
"inline-math",
|
||||
"quick-preview",
|
||||
"obsidian42-brat",
|
||||
"obsidian-vault-statistics-plugin"
|
||||
"obsidian-vault-statistics-plugin",
|
||||
"obsidian-plugin-toc"
|
||||
]
|
||||
@ -1,5 +1,5 @@
|
||||
{
|
||||
"displayIndividualItems": true,
|
||||
"displayIndividualItems": false,
|
||||
"showNotes": true,
|
||||
"showAttachments": true,
|
||||
"showFiles": true,
|
||||
|
||||
@ -1 +1 @@
|
||||
{"matrice hessienne":{"matrice hessienne":{"internalLink":{"count":2,"lastUpdated":1710324879177}}},"manim Ellipse":{"manim Ellipse":{"internalLink":{"count":1,"lastUpdated":1709296590359}}},"baptême":{"baptême":{"internalLink":{"count":5,"lastUpdated":1709864270370}}},"gradient":{"gradient":{"internalLink":{"count":1,"lastUpdated":1710325461961}}},"obsidian plugin tag and wordcloud":{"obsidian plugin tag and wordcloud":{"internalLink":{"count":1,"lastUpdated":1710345237714}}},"intersection de sous groupes":{"intersection de sous groupes":{"internalLink":{"count":1,"lastUpdated":1710465530327}}},"valeurs":{"valeurs":{"internalLink":{"count":1,"lastUpdated":1711459246780}}},"Learning APL":{"Learning APL":{"internalLink":{"count":1,"lastUpdated":1711584419388}}},"structure de donnés":{"structure de donnés":{"internalLink":{"count":1,"lastUpdated":1711621251914}}},"paramètre":{"paramètre":{"internalLink":{"count":1,"lastUpdated":1711621492446}}},"langage de programmation":{"langage de programmation":{"internalLink":{"count":4,"lastUpdated":1711920773085}},"langage":{"internalLink":{"count":1,"lastUpdated":1711920903060}}},"argument d'une fonction":{"argument d'une fonction":{"internalLink":{"count":1,"lastUpdated":1711624010397}}},"argument":{"argument":{"internalLink":{"count":2,"lastUpdated":1711624133731}}},"techniques de pkm":{"techniques de pkm":{"internalLink":{"count":1,"lastUpdated":1711627281333}}},"paradigme de programmation":{"paradigme de programmation":{"internalLink":{"count":6,"lastUpdated":1711917618071}}},"état":{"état":{"internalLink":{"count":3,"lastUpdated":1711905774038}}},"structure de données":{"structure de données":{"internalLink":{"count":1,"lastUpdated":1711643699590}}},"structures de données":{"structures de données":{"internalLink":{"count":2,"lastUpdated":1711904665130}}},"enregistrement":{"enregistrement":{"internalLink":{"count":1,"lastUpdated":1711668283936}}},"envoi de messages entre objets":{"envoi de messages entre objets":{"internalLink":{"count":1,"lastUpdated":1711742931869}}},"programmation structurée":{"programmation structurée":{"internalLink":{"count":1,"lastUpdated":1711764089506}}},"effet de bord":{"effet de bord":{"internalLink":{"count":2,"lastUpdated":1711906516742}}},"programmation impérative":{"programmation impérative":{"internalLink":{"count":3,"lastUpdated":1711915570179}}},"composition de fonctions":{"composition de fonctions":{"internalLink":{"count":1,"lastUpdated":1711904385231}}},"fonction":{"fonction":{"internalLink":{"count":2,"lastUpdated":1711904857369}}},"fonction pure":{"fonction pure":{"internalLink":{"count":1,"lastUpdated":1711915488076}}},"effets de bord":{"effets de bord":{"internalLink":{"count":1,"lastUpdated":1711915498637}}},"Alan Perlis":{"Alan Perlis":{"internalLink":{"count":1,"lastUpdated":1711915724379}}},"fonction racine carrée":{"fonction racine carrée":{"internalLink":{"count":1,"lastUpdated":1711916013705}}},"méthode de Newton":{"méthode de Newton":{"internalLink":{"count":1,"lastUpdated":1711916030171}}},"langages formels":{"langages formels":{"internalLink":{"count":1,"lastUpdated":1711916816989}}},"logique":{"logique":{"internalLink":{"count":1,"lastUpdated":1711916822650}}},"sophisme":{"sophisme":{"internalLink":{"count":1,"lastUpdated":1711916957089}}},"définition":{"définition":{"currentVault":{"count":1,"lastUpdated":1711920701861},"currentFile":{"count":1,"lastUpdated":1711920749062}}},"remplissage":{"remplissage":{"currentVault":{"count":1,"lastUpdated":1711920704851}}},"défini":{"défini":{"currentFile":{"count":1,"lastUpdated":1711920747172}}},"SE - organisation des données":{"SE - organisation des données":{"internalLink":{"count":1,"lastUpdated":1711920824428}}},"Frédéric Lordon":{"Frédéric Lordon":{"internalLink":{"count":1,"lastUpdated":1711942941375}}}}
|
||||
{"matrice hessienne":{"matrice hessienne":{"internalLink":{"count":2,"lastUpdated":1710324879177}}},"manim Ellipse":{"manim Ellipse":{"internalLink":{"count":1,"lastUpdated":1709296590359}}},"baptême":{"baptême":{"internalLink":{"count":5,"lastUpdated":1709864270370}}},"gradient":{"gradient":{"internalLink":{"count":1,"lastUpdated":1710325461961}}},"obsidian plugin tag and wordcloud":{"obsidian plugin tag and wordcloud":{"internalLink":{"count":1,"lastUpdated":1710345237714}}},"intersection de sous groupes":{"intersection de sous groupes":{"internalLink":{"count":1,"lastUpdated":1710465530327}}},"valeurs":{"valeurs":{"internalLink":{"count":1,"lastUpdated":1711459246780}}},"Learning APL":{"Learning APL":{"internalLink":{"count":1,"lastUpdated":1711584419388}}},"structure de donnés":{"structure de donnés":{"internalLink":{"count":1,"lastUpdated":1711621251914}}},"paramètre":{"paramètre":{"internalLink":{"count":1,"lastUpdated":1711621492446}}},"langage de programmation":{"langage de programmation":{"internalLink":{"count":4,"lastUpdated":1711920773085}},"langage":{"internalLink":{"count":1,"lastUpdated":1711920903060}}},"argument d'une fonction":{"argument d'une fonction":{"internalLink":{"count":1,"lastUpdated":1711624010397}}},"argument":{"argument":{"internalLink":{"count":2,"lastUpdated":1711624133731}}},"techniques de pkm":{"techniques de pkm":{"internalLink":{"count":1,"lastUpdated":1711627281333}}},"paradigme de programmation":{"paradigme de programmation":{"internalLink":{"count":6,"lastUpdated":1711917618071}}},"état":{"état":{"internalLink":{"count":3,"lastUpdated":1711905774038}}},"structure de données":{"structure de données":{"internalLink":{"count":1,"lastUpdated":1711643699590}}},"structures de données":{"structures de données":{"internalLink":{"count":2,"lastUpdated":1711904665130}}},"enregistrement":{"enregistrement":{"internalLink":{"count":1,"lastUpdated":1711668283936}}},"envoi de messages entre objets":{"envoi de messages entre objets":{"internalLink":{"count":1,"lastUpdated":1711742931869}}},"programmation structurée":{"programmation structurée":{"internalLink":{"count":1,"lastUpdated":1711764089506}}},"effet de bord":{"effet de bord":{"internalLink":{"count":2,"lastUpdated":1711906516742}}},"programmation impérative":{"programmation impérative":{"internalLink":{"count":4,"lastUpdated":1711988908729}}},"composition de fonctions":{"composition de fonctions":{"internalLink":{"count":1,"lastUpdated":1711904385231}}},"fonction":{"fonction":{"internalLink":{"count":2,"lastUpdated":1711904857369}}},"fonction pure":{"fonction pure":{"internalLink":{"count":1,"lastUpdated":1711915488076}}},"effets de bord":{"effets de bord":{"internalLink":{"count":1,"lastUpdated":1711915498637}}},"Alan Perlis":{"Alan Perlis":{"internalLink":{"count":1,"lastUpdated":1711915724379}}},"fonction racine carrée":{"fonction racine carrée":{"internalLink":{"count":1,"lastUpdated":1711916013705}}},"méthode de Newton":{"méthode de Newton":{"internalLink":{"count":1,"lastUpdated":1711916030171}}},"langages formels":{"langages formels":{"internalLink":{"count":1,"lastUpdated":1711916816989}}},"logique":{"logique":{"internalLink":{"count":1,"lastUpdated":1711916822650}}},"sophisme":{"sophisme":{"internalLink":{"count":1,"lastUpdated":1711916957089}}},"définition":{"définition":{"currentVault":{"count":1,"lastUpdated":1711920701861},"currentFile":{"count":1,"lastUpdated":1711920749062}}},"remplissage":{"remplissage":{"currentVault":{"count":1,"lastUpdated":1711920704851}}},"défini":{"défini":{"currentFile":{"count":1,"lastUpdated":1711920747172}}},"SE - organisation des données":{"SE - organisation des données":{"internalLink":{"count":1,"lastUpdated":1711920824428}}},"Frédéric Lordon":{"Frédéric Lordon":{"internalLink":{"count":1,"lastUpdated":1711942941375}}},"taxonomie des paradigmes de programmation":{"taxonomie des paradigmes de programmation":{"internalLink":{"count":1,"lastUpdated":1711988222924}}}}
|
||||
0
.trash/Untitled 2 6.md
Normal file
0
.trash/Untitled 2 6.md
Normal file
@ -1,6 +1,36 @@
|
||||
up:: [[plan du mémoire de L3]]
|
||||
#informatique #fac
|
||||
|
||||
|
||||
# Introduction
|
||||
![[mémoire de L3#^abstract]]
|
||||
|
||||
|
||||
# Sommaire
|
||||
|
||||
- [[#qu'est-ce qu'un paradigme|qu'est-ce qu'un paradigme]]
|
||||
- [[#Concepts importants|Concepts importants]]
|
||||
- [[#Concepts importants#Fonction et procédure|Fonction et procédure]]
|
||||
- [[#Concepts importants#Fermeture|Fermeture]]
|
||||
- [[#les principaux paradigmes|les principaux paradigmes]]
|
||||
- [[#les principaux paradigmes#programmation déclarative|programmation déclarative]]
|
||||
- [[#les principaux paradigmes#programmation fonctionnelle|programmation fonctionnelle]]
|
||||
- [[#les langages multi-paradigmes|les langages multi-paradigmes]]
|
||||
- [[#Définition de la puissance d'expression|Définition de la puissance d'expression]]
|
||||
- [[#Définition de la puissance d'expression#Au sens formel|Au sens formel]]
|
||||
- [[#Définition de la puissance d'expression#Au sens commun|Au sens commun]]
|
||||
- [[#Définition de la puissance d'expression#compromis expressivité vs analysabilité|compromis expressivité vs analysabilité]]
|
||||
- [[#compromis expressivité vs analysabilité#Exemple de compromis : automates et grammaires|Exemple de compromis : automates et grammaires]]
|
||||
- [[#contre la distinction entre les paradigmes|contre la distinction entre les paradigmes]]
|
||||
- [[#contre la distinction entre les paradigmes#Les paradigmes sont des courants de pensée|Les paradigmes sont des courants de pensée]]
|
||||
- [[#contre la distinction entre les paradigmes#Les paradigmes sont tous équivalents|Les paradigmes sont tous équivalents]]
|
||||
- [[#avantages de la diversité|avantages de la diversité]]
|
||||
- [[#problèmes de la diversité|problèmes de la diversité]]
|
||||
- [[#diversité des approches|diversité des approches]]
|
||||
- [[#créer un paradigme pour chaque type de problème|créer un paradigme pour chaque type de problème]]
|
||||
- [[#avantages des langages multi-paradigme|avantages des langages multi-paradigme]]
|
||||
|
||||
|
||||
# Définition et concepts importants
|
||||
## qu'est-ce qu'un paradigme
|
||||
|
||||
@ -8,7 +38,6 @@ Un paradigme de programmation est une façon d'approcher la programmation et de
|
||||
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|paradigme]]
|
||||
|
||||
> [!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)
|
||||
@ -31,12 +60,180 @@ Un paradigme est un concept plus "haut niveau", c'est-à-dire plus abstrait : ch
|
||||
> > 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](zotero://select/groups/5383243/items/JS99BNS3) - [Page ](zotero://open-pdf/groups/5383243/items/TFPQ3W8G?annotation=KP3KB62E)
|
||||
> 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](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 1](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=1&annotation=2QS3SA82)
|
||||
> 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](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 1](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=1&annotation=INFAECYD)
|
||||
> 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](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 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](zotero://select/groups/5383243/items/CNP9I827) - [Page 135](zotero://open-pdf/groups/5383243/items/TY878EW8?page=2&annotation=SRALKQCM)
|
||||
> (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)](zotero://select/groups/5383243/items/FDB7GED2) - [Page ](zotero://open-pdf/groups/5383243/items/RIAPAJ6E?annotation=GNQR9GC2)
|
||||
> 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](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=BRVCUS8M)
|
||||
> 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)](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
|
||||
|
||||
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)](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
|
||||
|
||||
## 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|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](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.
|
||||
>
|
||||
> > [!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|é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|pures]] (limiter au maximum / complètement [[programmation.effet de bord|effet de bord]])
|
||||
^definition
|
||||
|
||||
> [!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]+ [What Is Functional Programming?](zotero://select/groups/5383243/items/TLUTFXJ8) - [Page ](zotero://open-pdf/groups/5383243/items/8P4TX53J?annotation=IU2KWY7L)
|
||||
> 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](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 1](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=1&annotation=WSXGN3RM)
|
||||
> ![[images/zotero/5383243WSXGN3RM.png|500]]
|
||||
>
|
||||
> > [!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](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
|
||||
|
||||
|
||||
### programmation orientée objet
|
||||
|
||||
###
|
||||
|
||||
- impératif
|
||||
- procédural
|
||||
@ -44,7 +241,6 @@ Un paradigme est un concept plus "haut niveau", c'est-à-dire plus abstrait : ch
|
||||
- fonctionnel
|
||||
- fonctionnel pur
|
||||
- programmation structurée
|
||||
|
||||
## les langages multi-paradigmes
|
||||
|
||||
> [!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)
|
||||
@ -218,18 +414,6 @@ Greg Michaelson critique la distinction des paradigmes, en expliquant que, lorsq
|
||||
> ^588UCYYDaSQN4T6Z8g5383243p7
|
||||
|
||||
# Paradigmes pour la résolution de problèmes
|
||||
|
||||
Un paradigme de programmation est principalement décrit par les concepts qu'il implémente ou non.
|
||||
J.Huges, dans son article "Why Functional Programming Matters", fustige notamment le fait que certains paradigmes (notamment la programmation fonctionnelle *ref* et la programmation structurée *ref*) sont trop souvent définies en termes des fonctionnalités qu'il n'implémente pas, ou des contraintes qu'il pose. 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 ()
|
||||
|
||||
> [!cite]- [Why Functional Programming Matters](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 1](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=1&annotation=2QS3SA82)
|
||||
> 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](zotero://select/groups/5383243/items/6RZUZSFR) - [Page 1](zotero://open-pdf/groups/5383243/items/H9SGRTMQ?page=1&annotation=INFAECYD)
|
||||
> 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
|
||||
|
||||
## diversité des approches
|
||||
La diversité est utile, de nouveaux paradigmes apportent de nouvelles façons de voir.
|
||||
Langages multi-paradigmes
|
||||
|
||||
@ -26,3 +26,10 @@ up:: [[programmation.fonction|fonction]]
|
||||
> 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
|
||||
@ -26,7 +26,7 @@ title::
|
||||
- pour l'expression de problèmes (pouvoir d'expression)
|
||||
|
||||
Il existe de nombreux paradigmes de programmation. Puisque tous les langages turing-complets sont formellement équivalents (ils ont la même capacité à exprimer l'ensemble des problèmes calculables), l'existance de tant de paradigmes différents peut sembler étonnante, voire inutile. Nous essayerons de comprendre pourquoi il existe tant de paradigmes différents. Nous présenteront d'abord une définition de ce qu'est un paradigme de programmation, puis nous exposeront en quoi différents paradigmes sont plus adaptés pour différentes raisons : pour l'apprentissage, pour la résolution ou l'expression de certains types de problèmes et pour les apports que fait chaque paradigme en général.
|
||||
|
||||
^abstract
|
||||
|
||||
|
||||
|
||||
|
||||
18
programmation déclarative.md
Normal file
18
programmation déclarative.md
Normal file
@ -0,0 +1,18 @@
|
||||
up:: [[paradigme de programmation|paradigme]]
|
||||
opposes:: [[paradigme programmation impérative|programmation impérative]]
|
||||
#informatique
|
||||
|
||||
> [!definition] programmation déclarative
|
||||
> La programmation déclarative est un paradigme de programmation (ou plutôt un style de paradigme) 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|programmation impérative]]).
|
||||
> Le flôt de contrôle est donc implicite, et le développeur ne s'occupe pas de l'exécution, mais plutôt de comment spécifier le résultat.
|
||||
^definition
|
||||
|
||||
> [!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.
|
||||
>
|
||||
> > [!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
|
||||
@ -5,3 +5,11 @@ aliases:
|
||||
---
|
||||
up:: [[programmation]]
|
||||
#informatique
|
||||
|
||||
> [!smallquery]+ Sous-notes de `$= dv.el("span", "[[" + dv.current().file.name + "]]")`
|
||||
> ```breadcrumbs
|
||||
> title: false
|
||||
> type: tree
|
||||
> dir: down
|
||||
> ```
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user