oskar/cours
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
Oscar Plaisant 2024-05-21 11:40:42 +02:00
parent 95c81f9cb3
commit de3a0dcf0f
75 changed files with 87483 additions and 93999 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
.DS_Store vendored
View File

Binary file not shown.

3
.obsidian/community-plugins.json vendored
View File

@ -49,5 +49,6 @@
"better-fn",
"math-in-callout",
"cloze",
"obsidian-hypothesis-plugin"
"obsidian-hypothesis-plugin",
"unicode-search"
]

27
.obsidian/hotkeys.json vendored
View File

@ -79,15 +79,6 @@
"key": "L"
}
],
"obsidian-excalidraw-plugin:excalidraw-autocreate": [
{
"modifiers": [
"Mod",
"Shift"
],
"key": "E"
}
],
"editor:swap-line-down": [
{
"modifiers": [
@ -792,5 +783,23 @@
],
"key": "I"
}
],
"obsidian-excalidraw-plugin:toggle-excalidraw-view": [
{
"modifiers": [
"Mod",
"Shift"
],
"key": "E"
}
],
"unicode-search:search-unicode-chars": [
{
"modifiers": [
"Mod",
"Shift"
],
"key": "U"
}
]
}

2
.obsidian/plugins/breadcrumbs/data.json vendored
View File

@ -59,7 +59,7 @@
"showAllAliases": false,
"showBCs": true,
"showBCsInEditLPMode": true,
"showRefreshNotice": false,
"showRefreshNotice": true,
"showImpliedRelations": true,
"showTrail": false,
"showGrid": true,

8
.obsidian/plugins/obsidian-citation-plugin/data.json vendored
View File

@ -1,8 +0,0 @@
{
"citationExportFormat": "csl-json",
"literatureNoteTitleTemplate": "@{{citekey}}",
"literatureNoteFolder": "Reading notes",
"literatureNoteContentTemplate": "---\ntitle: {{title}}\nyear: {{year}}\n---\nauthor:: {{authorString}}\nlink:: {{URL}}\n\n",
"markdownCitationTemplate": "[@{{citekey}}]",
"alternativeMarkdownCitationTemplate": "@{{citekey}}"
}

85889
.obsidian/plugins/obsidian-citation-plugin/main.js vendored
View File

File diff suppressed because one or more lines are too long

10
.obsidian/plugins/obsidian-citation-plugin/manifest.json vendored
View File

@ -1,10 +0,0 @@
{
"id": "obsidian-citation-plugin",
"name": "Citations",
"version": "0.4.5",
"minAppVersion": "0.9.20",
"description": "Automatically search and insert citations from a Zotero library",
"author": "Jon Gauthier",
"authorUrl": "http://foldl.me",
"isDesktopOnly": true
}

114
.obsidian/plugins/obsidian-citation-plugin/styles.css vendored
View File

@ -1,114 +0,0 @@
/** Citations modal **/
/*
* Loading animation from
* https://loading.io/css/
*/
.zoteroModalLoading {
color: var(--text-muted);
text-align: center;
}
.zoteroModalLoadingAnimation {
display: inline-block;
width: 80px;
height: 80px;
}
.zoteroModalLoadingAnimation {
content: " ";
display: block;
width: 32px;
height: 32px;
margin: 10px auto;
border-radius: 50%;
border: 3px solid #eee;
border-color: #eee transparent #eee transparent;
animation: lds-dual-ring 1.2s linear infinite;
}
@keyframes lds-dual-ring {
0% {
transform: rotate(0deg);
}
100% {
transform: rotate(360deg);
}
}
#zoteroSettingTab .text-monospace {
font-family: monospace;
}
.zoteroModalResults .suggestion-item {
height: fit-content;
line-height: 1.5rem;
}
.zoteroTitle {
font-size: 14px;
display: block;
}
.zoteroAuthors {
color: #555;
font-size: 13px;
}
.zoteroAuthorsEmpty::after {
font-style: italic;
content: 'Unknown authors';
}
.zoteroCitekey {
color: #555;
font-size: 13px;
font-family: monospace;
display: inline-block;
margin-right: 5px;
padding-right: 5px;
border-right: 1px solid #ccc;
}
.theme-dark .zoteroTitle {
font-size: 14px;
display: block;
}
.theme-dark .zoteroAuthors {
color: #aaa;
font-size: 13px;
}
.theme-dark .zoteroCitekey {
color: #aaa;
font-size: 13px;
font-family: monospace;
display: inline-block;
margin-right: 5px;
padding-right: 5px;
border-right: 1px solid #aaa;
}
/** Settings dialog **/
.d-none {
display: none;
}
.zoteroSettingCitationPathLoading,
.zoteroSettingCitationPathError,
.zoteroSettingCitationPathSuccess {
font-size: 14px;
}
.zoteroSettingCitationPathLoading {
color: var(--text-muted);
}
.zoteroSettingCitationPathError {
color: var(--text-error);
}
.zoteroSettingCitationPathError:hover {
color: var(--text-error-hover);
}
.zoteroSettingCitationPathSuccess {
color: var(--text-accent);
}
.zoteroSettingCitationPathSuccess:hover {
color: var(--text-accent-hover);
}
#zoteroSettingTab textarea {
resize: vertical;
width: 100%;
min-height: 10em;
}

12335
.obsidian/plugins/obsidian-excalidraw-plugin/data.json vendored
View File

File diff suppressed because it is too large Load Diff

16
.obsidian/plugins/obsidian-excalidraw-plugin/main.js vendored
View File

File diff suppressed because one or more lines are too long

2
.obsidian/plugins/obsidian-excalidraw-plugin/manifest.json vendored
View File

@ -1,7 +1,7 @@
{
"id": "obsidian-excalidraw-plugin",
"name": "Excalidraw",
"version": "2.1.7",
"version": "2.2.2",
"minAppVersion": "1.1.6",
"description": "An Obsidian plugin to edit and view Excalidraw drawings",
"author": "Zsolt Viczian",

2
.obsidian/plugins/obsidian-excalidraw-plugin/styles.css vendored
View File

File diff suppressed because one or more lines are too long

4
.obsidian/plugins/obsidian-hypothesis-plugin/data.json vendored
View File

@ -4,7 +4,7 @@
"highlightsFolder": "sources/hypothesis",
"isConnected": true,
"template": "{% if is_new_article %}{% if author %}author:: [[{{author}}]]\nurl:: [{{author}}]({{url}})\n{% else %}\nurl:: {{url}}\n{% endif %}{% endif %}\n\n{% if is_new_article %}\n## Annotations\n{% for highlight in highlights %}\n> [!zotero] [{{highlight.updated}}]({{highlight.incontext}}){% for line in highlight.text.split(\"\\n\") %}\n> {{line}}{% endfor %}{% if highlight.annotation %}\n> > [!note] Annotations{% for line in highlight.annotation.split(\"\\n\") %}\n> > {{line}}{% endfor %}\n{% endif %}{% endfor %}{% endif %}\n\n{% if is_new_article %}\n## Notes de pages\n{% for highlight in page_notes %}\n> [!note] [{{highlight.updated}}]({{highlight.incontext}})\n> {{highlight.annotation}}\n{% endfor %}\n{% endif %}\n",
"syncOnBoot": false,
"syncOnBoot": true,
"autoSyncInterval": 0,
"dateTimeFormat": "YYYY-MM-DD HH:mm:ss",
"history": {
@ -21,5 +21,5 @@
}
],
"useDomainFolders": false,
"lastSyncDate": "2024-05-14T10:11:14.434Z"
"lastSyncDate": "2024-05-21T09:40:39.769Z"
}

4
.obsidian/plugins/obsidian-pandoc-reference-list/data.json vendored
View File

@ -5,12 +5,12 @@
{
"id": 2,
"name": "memoire-L3",
"lastUpdate": 1715677571514
"lastUpdate": 1716284434994
},
{
"id": 1,
"name": "Ma bibliothèque",
"lastUpdate": 1715677571539
"lastUpdate": 1716284435014
}
],
"renderCitations": true,

2
.obsidian/plugins/obsidian-spaced-repetition/data.json vendored
View File

@ -43,7 +43,7 @@
"singlelineCardSeparator": "::",
"singlelineReversedCardSeparator": ":::"
},
"buryDate": "2024-05-14",
"buryDate": "2024-05-21",
"buryList": [],
"historyDeck": ""
}

19
.obsidian/plugins/obsidian-zotero-desktop-connector/data.json vendored
View File

@ -1,19 +0,0 @@
{
"database": "Zotero",
"noteImportFolder": "sources",
"pdfExportImageDPI": 120,
"pdfExportImageFormat": "jpg",
"pdfExportImageQuality": 90,
"citeFormats": [],
"exportFormats": [
{
"name": "Import #1",
"outputPathTemplate": "sources/{{citekey}}.md",
"imageOutputPathTemplate": "images/{{citekey}}/",
"imageBaseNameTemplate": "image"
}
],
"citeSuggestTemplate": "[[{{citekey}}]]",
"openNoteAfterImport": true,
"whichNotesToOpenAfterImport": "first-imported-note"
}

191
.obsidian/plugins/obsidian-zotero-desktop-connector/main.js vendored
View File

File diff suppressed because one or more lines are too long

10
.obsidian/plugins/obsidian-zotero-desktop-connector/manifest.json vendored
View File

@ -1,10 +0,0 @@
{
"id": "obsidian-zotero-desktop-connector",
"name": "Zotero Integration",
"version": "3.1.8",
"minAppVersion": "1.1.1",
"description": "Insert and import citations, bibliographies, notes, and PDF annotations from Zotero.",
"author": "mgmeyers",
"authorUrl": "https://github.com/mgmeyers/obsidian-zotero-integration",
"isDesktopOnly": true
}

238
.obsidian/plugins/obsidian-zotero-desktop-connector/styles.css vendored
View File

@ -1,238 +0,0 @@
.zt-format {
border: 1px solid var(--background-modifier-border);
padding: 1rem;
background-color: var(--background-primary);
border-radius: 10px;
margin-bottom: 10px;
}
.zt-format__form {
display: flex;
flex-direction: column;
align-items: stretch;
margin-bottom: 1rem;
max-width: 600px;
}
.zt-format__form:last-child {
margin-bottom: 0;
}
.zt-format__label {
font-size: 0.9em;
font-weight: 600;
margin-bottom: 5px;
}
.is-deprecated .zt-format__label {
color: var(--text-error);
}
.zt-format__input-wrapper {
display: flex;
align-items: center;
}
.zt-format__input-wrapper textarea {
resize: vertical;
}
.zt-format__input-wrapper > *:not(.checkbox-container) {
width: 100% !important;
}
.is-deprecated .zt-format__input-wrapper button {
width: auto !important;
flex-grow: 0;
flex-shrink: 0;
margin-left: 5px;
}
.zt-format__delete-btn {
display: flex;
align-items: center;
justify-content: center;
line-height: 1;
padding: 7px 9px;
margin-left: 10px;
flex-shrink: 0;
flex-grow: 0;
}
.zt-json-viewer {
font-size: 13px;
}
.zt-json-viewer .react-json-view {
padding: 1em;
border-radius: 10px;
margin-top: 1em;
overflow: auto;
font-family: var(--font-monospace) !important;
}
.zt-json-viewer__btns {
display: flex;
align-items: center;
justify-content: flex-start;
}
.zt-json-viewer__btns label {
display: block;
font-weight: bold;
padding-top: 1em;
}
.zt-json-viewer__btns select {
font-size: 1em;
}
.zt-json-viewer__btns button {
font-size: 1em;
margin-right: 5px;
}
.zt-json-viewer__preview,
.zt-json-viewer__data {
border: 1px solid var(--background-modifier-border);
border-radius: 10px;
padding: 1em;
margin-top: 1em;
}
.zt-json-viewer__preview.error {
background-color: #ff000011;
font-family: var(--font-monospace);
}
.zt-json-viewer__preview pre {
overflow: auto;
white-space: pre-wrap;
margin: 0;
}
.zt-json-viewer__preview pre,
.zt-json-viewer__preview code {
font-family: inherit;
}
.zt-json-viewer__preview:not(.error) pre {
font-family: var(--font-text, --font-default, --default-font);
max-height: 70vh;
min-height: 400px;
}
.zt-multiselect {
width: 300px;
text-align: left;
}
.zt-multiselect input {
outline: none !important;
box-shadow: none !important;
}
.zt-format__input-note {
font-style: italic;
font-size: 0.9em;
padding-top: 10px;
margin-bottom: 10px;
}
.zt-setting-item pre,
.zt-format__input-note pre {
display: inline-block;
margin: 0;
padding: 0 6px;
background-color: var(--background-secondary-alt);
border-radius: 4px;
}
.zt-asset-success {
text-align: left;
display: flex;
}
.zt-asset-success__icon {
color: var(--interactive-success);
font-size: 24px;
margin-right: 5px;
}
.zt-asset-success__icon svg {
width: 1em !important;
height: 1em !important;
}
.zt-asset-success__message {
font-size: 0.9em;
}
.zt-suggest-title {
font-size: var(--font-ui-small);
color: var(--text-muted);
display: block;
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
padding-top: var(--size-4-1);
}
.zt-suggest-loading-wrapper {
display: flex;
position: relative;
align-items: center;
justify-content: center;
padding: var(--size-4-2) 0;
}
.zt-suggest-loading,
.zt-suggest-loading:before,
.zt-suggest-loading:after {
border-radius: 999px;
width: 1em;
height: 1em;
animation-fill-mode: both;
animation: bblFadInOut 1.6s infinite ease-in-out;
}
.zt-suggest-loading {
display: block;
color: var(--text-muted);
font-size: 7px;
position: relative;
animation-delay: -0.16s;
top: -1em;
}
.zt-suggest-loading:before,
.zt-suggest-loading:after {
content: '';
position: absolute;
}
.zt-suggest-loading:before {
left: -2em;
animation-delay: -0.32s;
}
.zt-suggest-loading:after {
left: 2em;
}
.zt-color-chip {
display: inline-block;
width: 1em;
height: 1em;
border: 1px solid var(--background-modifier-border);
border-radius: var(--radius-s);
margin-right: var(--size-4-1);
}
@keyframes bblFadInOut {
0%,
80%,
100% {
box-shadow: 0 1em 0 -1.3em;
}
40% {
box-shadow: 0 1em 0 0;
}
}

7
.obsidian/plugins/templater-obsidian/data.json vendored
View File

@ -7,7 +7,7 @@
""
]
],
"trigger_on_file_creation": false,
"trigger_on_file_creation": true,
"auto_jump_to_cursor": false,
"enable_system_commands": false,
"shell_path": "",
@ -15,11 +15,12 @@
"enable_folder_templates": true,
"folder_templates": [
{
"folder": "",
"template": ""
"folder": "/",
"template": "templates/nouvelle note.md"
}
],
"syntax_highlighting": true,
"syntax_highlighting_mobile": false,
"enabled_templates_hotkeys": [
""
],

6
.obsidian/plugins/templater-obsidian/main.js vendored
View File

@ -1671,7 +1671,7 @@ var FolderSuggest = class extends TextInputSuggest {
folders.push(folder);
}
});
return folders;
return folders.slice(0, 1e3);
}
renderSuggestion(file, el) {
el.setText(file.path);
@ -1791,7 +1791,7 @@ var FileSuggest = class extends TextInputSuggest {
files.push(file);
}
});
return files;
return files.slice(0, 1e3);
}
renderSuggestion(file, el) {
el.setText(file.path);
@ -3659,7 +3659,7 @@ var Templater = class {
const oldSelections = doc.listSelections();
doc.replaceSelection(output_content);
if (active_editor.file) {
await app.vault.append(active_editor.file, "");
await app.vault.modify(active_editor.file, editor.getValue());
}
app.workspace.trigger("templater:template-appended", {
view: active_view,

2
.obsidian/plugins/templater-obsidian/manifest.json vendored
View File

@ -1,7 +1,7 @@
{
"id": "templater-obsidian",
"name": "Templater",
"version": "2.3.1",
"version": "2.3.2",
"description": "Create and use templates",
"minAppVersion": "1.5.0",
"author": "SilentVoid",

78955
.obsidian/plugins/unicode-search/data.json vendored Normal file
View File

File diff suppressed because it is too large Load Diff

21
.obsidian/plugins/unicode-search/main.js vendored Normal file
View File

File diff suppressed because one or more lines are too long

10
.obsidian/plugins/unicode-search/manifest.json vendored Normal file
View File

@ -0,0 +1,10 @@
{
"id": "unicode-search",
"name": "Unicode Search",
"version": "0.6.0",
"minAppVersion": "0.15.0",
"description": "Search and insert Unicode characters into your editor",
"author": "BambusControl",
"authorUrl": "https://github.com/BambusControl",
"isDesktopOnly": false
}

1
.obsidian/plugins/unicode-search/styles.css vendored Normal file
View File

@ -0,0 +1 @@
.plugin.unicode-search.result-item{display:flex;gap:1em;justify-content:flex-start;align-items:center}.plugin.unicode-search.result-item>.character-preview{font-size:1.5em;width:1.75em;display:flex;justify-content:center;align-items:center}.plugin.unicode-search.result-item>.character-match{flex-grow:1;display:flex;flex-direction:column;justify-content:center;align-items:flex-start;column-gap:1em;row-gap:.05em;min-height:2.5em}@media (min-width: 40em){.plugin.unicode-search.result-item>.character-match{flex-direction:row;justify-content:space-between;align-items:center}}.plugin.unicode-search.result-item>.character-match>.character-codepoint{color:var(--code-normal);font-family:var(--font-monospace);font-size:var(--code-size);letter-spacing:.055em;text-transform:uppercase}@media (min-width: 40em){.plugin.unicode-search.result-item>.character-match>.character-codepoint{border-radius:var(--radius-s);background-color:var(--code-background);padding:.1em .3em}}.plugin.unicode-search.result-item>.character-match>.character-codepoint:before{content:"U+";letter-spacing:.15em}.plugin.unicode-search.result-item>.character-match>.character-codepoint>.suggestion-highlight{color:var(--text-normal)}.plugin.unicode-search.result-item>.detail{display:flex;flex-direction:row;justify-content:flex-end;align-items:center;gap:.5em}.plugin.unicode-search.result-item>.detail>.attributes{display:flex;flex-direction:column;justify-content:center;align-items:center;font-size:var(--font-smallest);width:1.25em}.plugin.unicode-search .icon{color:var(--icon-color);opacity:var(--icon-opacity)}.plugin.unicode-search .icon:hover{color:var(--icon-color-hover);opacity:var(--icon-opacity-hover)}.plugin.unicode-search .icon:hover.interactive{color:var(--interactive-accent-hover)}.plugin.unicode-search.setting-tab .group-container{gap:1em;flex-direction:column;align-items:stretch;align-content:stretch;flex-wrap:wrap;justify-content:flex-start}.plugin.unicode-search.setting-tab .group-container:not(.hidden){display:flex}.plugin.unicode-search.setting-tab .group-container.hidden{display:none}.plugin.unicode-search.setting-tab .item-container{border:1px solid var(--background-modifier-border);border-radius:var(--radius-s);padding:.5em .75em;background-color:var(--background-primary-alt)}@media (min-width: 40em){.plugin.unicode-search.setting-tab .item-container>.setting-item.setting-item-heading{margin:.75em 0}}.plugin.unicode-search.setting-tab .item-container>.setting-item.setting-item-heading>.setting-item-info{flex-grow:1}.plugin.unicode-search.setting-tab .item-container>.setting-item.setting-item-heading>.setting-item-info>.setting-item-name{display:flex;flex-direction:row;flex-wrap:wrap;justify-content:space-between;align-items:center}.plugin.unicode-search.setting-tab .item-container>.setting-item.setting-item-heading>.setting-item-control{flex-grow:0}@media (min-width: 40em){.plugin.unicode-search.setting-tab .blocks-list .setting-item>.setting-item-info{display:inline-flex;flex-direction:row;flex-wrap:wrap;justify-content:space-between;align-items:center}.plugin.unicode-search.setting-tab .blocks-list .setting-item>.setting-item-info>.setting-item-name{font-size:90%}.plugin.unicode-search.setting-tab .blocks-list .setting-item>.setting-item-info>.setting-item-description{padding-top:0}.plugin.unicode-search.setting-tab .blocks-list .setting-item>.setting-item-control{flex-grow:0}}.plugin.unicode-search.setting-tab .monospace{color:var(--code-normal);font-family:var(--font-monospace)}.plugin.unicode-search.setting-tab .character-codepoint{letter-spacing:.055em;text-transform:uppercase;font-size:var(--code-size)}@media (min-width: 40em){.plugin.unicode-search.setting-tab .character-codepoint{border-radius:var(--radius-s);background-color:var(--code-background);padding:.1em .3em}}.plugin.unicode-search.setting-tab .character-codepoint>.suggestion-highlight{color:var(--text-normal)}

3
.obsidian/types.json vendored
View File

@ -23,6 +23,7 @@
"excalidraw-autoexport": "text",
"excalidraw-iframe-theme": "text",
"excalidraw-open-md": "checkbox",
"excalidraw-export-embed-scene": "checkbox"
"excalidraw-export-embed-scene": "checkbox",
"excalidraw-embeddable-theme": "text"
}
}

3
.trash/Untitled 1 5.md Normal file
View File

@ -0,0 +1,3 @@

0
.trash/Untitled 1 6.md Normal file
View File

90
.trash/Untitled.md Normal file
View File

@ -0,0 +1,90 @@
---
excalidraw-plugin: parsed
tags:
- excalidraw
excalidraw-open-md: true
---
up::
#
%%
# Drawing
```json
{
"type": "excalidraw",
"version": 2,
"source": "https://github.com/zsviczian/obsidian-excalidraw-plugin/releases/tag/2.1.7",
"elements": [
{
"id": "TlBb7WofomQ_LWnBjKu5z",
"type": "ellipse",
"x": -88.40234375,
"y": -219.78125,
"width": 259.30078125,
"height": 159.1484375,
"angle": 0,
"strokeColor": "#1e1e1e",
"backgroundColor": "transparent",
"fillStyle": "solid",
"strokeWidth": 2,
"strokeStyle": "solid",
"roughness": 1,
"opacity": 100,
"groupIds": [],
"frameId": null,
"index": "a0",
"roundness": {
"type": 2
},
"seed": 613532562,
"version": 12,
"versionNonce": 1158102286,
"isDeleted": false,
"boundElements": null,
"updated": 1716243881062,
"link": null,
"locked": false
}
],
"appState": {
"theme": "dark",
"viewBackgroundColor": "#ffffff",
"currentItemStrokeColor": "#1e1e1e",
"currentItemBackgroundColor": "transparent",
"currentItemFillStyle": "solid",
"currentItemStrokeWidth": 2,
"currentItemStrokeStyle": "solid",
"currentItemRoughness": 1,
"currentItemOpacity": 100,
"currentItemFontFamily": 1,
"currentItemFontSize": 20,
"currentItemTextAlign": "left",
"currentItemStartArrowhead": null,
"currentItemEndArrowhead": "arrow",
"scrollX": 495.5859375,
"scrollY": 397.73046875,
"zoom": {
"value": 1
},
"currentItemRoundness": "round",
"gridSize": null,
"gridColor": {
"Bold": "#C9C9C9FF",
"Regular": "#EDEDEDFF"
},
"currentStrokeOptions": null,
"previousGridSize": null,
"frameRendering": {
"enabled": true,
"clip": true,
"name": true,
"outline": true
},
"objectsSnapModeEnabled": false
},
"files": {}
}
```
%%

34
.trash/bonjour.md Normal file
View File

@ -0,0 +1,34 @@
---
excalidraw-plugin: parsed
tags:
- excalidraw
excalidraw-open-md: true
---
up::
![[tEst]]
%%
# Excalidraw Data
## Text Elements
## Drawing
```compressed-json
N4KAkARALgngDgUwgLgAQQQDwMYEMA2AlgCYBOuA7hADTgQBuCpAzoQPYB2KqATLZMzYBXUtiRoIACyhQ4zZAHoFAc0JRJQgEYA6bGwC2CgF7N6hbEcK4OCtptbErHALRY8RMpWdx8Q1TdIEfARcZgRmBShcZQUebTieGjoghH0EDihmbgBtcDBQMEKIEm4IAGEYAHkASQRlABlqqCMAawAlAGk2AClqgAUANQBZAHEBpMLIWERSoKI5JH4izG5n
AEYADgBWbS2ATi2AZj2AFgB2Q4A2DZOeAAYNpcgYVbWTy+0Ny7O7/bu7k57Q63Ph5SAUEjqbj3Q7aNZnHg8L6bW5rX6gyZSBCEZTSaF3WHwxHIm48NFbDFFazKYLcO5PCDMKCkNgtBBlNj4NikUoAYjWCAFAomRU0uGwLWULKEHGIHK5PIkzOszDguECGRFkAAZoR8PgAMqwWkSQQeLWM5mshAAdUhkmhDKZLLZRpgJvQZpKDOluI44SyaDWDLYa
uwaheQf+DKlwjg1WIgdQ2QAugzteQ0gnuBwhPqGYRZVhSrg1hbpbL/cwkwVMdNxLwwQBfJ0IBDEbjwgk8IEPR5ghhMVicbiHM4MxgsdgcABynDEo62ZzWawph0pkEIzAAIikoO3uNqCGEGZphLKAKLBNIZJO5/MDoRwYi4fcdoPLy5I4EbQ5Ly4MkQHAtDmeb4IBbASgeaBHvgYR5C2eS1lM8ANhg+iaO2L6aLSE5DtOo6HHhU6cHOHALmg9wEls
WyXFsawbsURYrBIuB3BaW67sEb7cMyQgIAW77oEacBCDaPA2g66Z6oaxpoZI4oaIEFrOtadrEFCQZOlarpyaUXodj6wh+gGnYhmGEadtGA7Uh69IDixqDODwZxnHCPBbAykZOS5GzaJclwnHcX6eQOqlsvK3J8v8MXsae4qShWcqclFSrkBwqrqukUAWhCGkOmgQX2ZikjYriOVoFs1mYmE0GoIcwV3MGA6xk+CZJqm6aZgg2ZoPe4EDklVZ3mBp
7nsQV6pNlHVpo+z6vnV8JrF+v7nBsexooBhYgRI2TZAAqhkajBMQ2j6MQvLqFuqDXbgqDEKkbApimFpclBQmwSeA7YEITIGNur64NwyGQOdfQsnIwNgkUv0IJU9gkE4u5HnmmSHseAnQ5AYoSq1spDK+2CSGU1j0KE6NwZjkyiglePEATUBE5NN4VagfFU9TEA44l42RYq6C8tqQtajTuNJZUFmwNwlzFZzZ6kA9pAM0z17ZbxpD8U8orcorfN8k
L2oi9jOtMBL4qWWgsuYrqwQcLgaQDFuhA4Q2n0INDTbNk67gNrk1PNf7YIpgh4CzZAuBwHARoLVDRTqFNpQvqQIFLAwhAIBQABCtNJXrEiCwbwupz9pAalATSpEaLrsil/MQPygqNyKEAl2XFf6NnYu87XpTKhlapl83rfZe3ABiMluh6jKct6eQtyIbf7voVdqfajpz8PGTtyvunumhBlDwvI9L20xmSMNZkb0fW9L2b4ZS1Gsvz6Xx+pKPnBQK
P9t6t5AeQJv5cl7vwyAaQgRgGz3GLtfQBqQAAqWAoAAEEiDKC4BIYI2ocpQJfjfSuURSBINLmwCgpVcBCX6tgxeqQLyykQUQkhIQhIQHVCyKgqdmDYBZPqAAGtwd4Jx4hnD2DLCklxDirjOF8dhnDOT4AAJrQj2HcbQTVvgNV+GcWiWx+xFCMGwAwscihk18A2NY2glGxUsbFNYCFKGv30KfGUxAL4SCSs3KUJBQHgNAg+IoHjkoKkMZATOnImG8
jKHsCJETR6jwtG0OoeZ1R8gvNuFJKSYkQFsVfHBUAd5wzgFAacI1fGQDgIEMwwhmAjFIJ4sBDYKFzwzPbBA8Siw1I4MoIJGA7YuyEuzBk2B5jq01gOO2aRhkc0gMIKAQEGzsyyUUOwAArBA2BMgGjtnAIYbAHo0NwL0im8EwCIR1HqcIwNPZNiAA
```
%%

34
.trash/test.md Normal file
View File

@ -0,0 +1,34 @@
---
excalidraw-plugin: parsed
tags:
- excalidraw
excalidraw-open-md: true
---
up::
![[test]]
%%
# Excalidraw Data
## Text Elements
## Drawing
```compressed-json
N4KAkARALgngDgUwgLgAQQQDwMYEMA2AlgCYBOuA7hADTgQBuCpAzoQPYB2KqATLZMzYBXUtiRoIACyhQ4zZAHoFAc0JRJQgEYA6bGwC2CgF7N6hbEcK4OCtptbErHALRY8RMpWdx8Q1TdIEfARcZgRmBShcZQUebTieGjoghH0EDihmbgBtcDBQMEKIEm4IAGEYAHkASQRlABlqqCMAawAlAGk2AClqgAUANQBZAHEBpMLIWERSoKI5JH4izG5n
AEYADgBWbS2ATi2AZj2AFgB2Q4A2DZOeAAYNpcgYVbWTy+0Ny7O7/bu7k57Q63Ph5SAUEjqbj3Q7aNZnHg8L6bW5rX6gyZSBCEZTSaF3WHwxHIm48NFbDFFazKYLcO5PCDMKCkNgtBBlNj4NikUoAYjWCAFAomRU0uGwLWULKEHGIHK5PIkzOszDguECGRFkAAZoR8PgAMqwWkSQQeLWM5mshAAdUhkmhDKZLLZRpgJvQZpKDOluI44SyaDWDLYa
uwaheQf+DKlwjg1WIgdQ2QAugzteQ0gnuBwhPqGYRZVhSrg1hbpbL/cwkwVMdNxLwwQBfJ0IBDEbjwgk8IEPR5ghhMVicbiHM4MxgsdgcABynDEo62ZzWawph0pkEIzAAIikoO3uNqCGEGZphLKAKLBNIZJO5/MDoRwYi4fcdoPLy5I4EbQ5Ly4MkQHAtDmeb4IBbASgeaBHvgYR5C2eS1lM8ANhg+iaO2L6aLSE5DtOo6HHhU6cHOHALmg9wEls
WyXFsawbsURYrBIuB3BaW67sEb7cMyQgIAW77oEacBCDaPA2g66Z6oaxpoZI4oaIEFrOtadrEFCQZOlarpyaUXodj6wh+gGnYhmGEadtGA7Uh69IDixqDODwZxnHCPBbAykZOS5GzaJclwnHcX6eQOqlsvK3J8v8MXsae4qShWcqclFSrkBwqrqukUAWhCGkOmgQX2ZikjYriOVoFs1mYmE0GoIcwV3MGA6xk+CZJqm6aZgg2ZoPe4EDklVZ3mBp
7nsQV6pNlHVpo+z6vnV8JrF+v7nBsexooBhYgRI2TZAAqhkajBMQ2j6MQvLqFuqDXbgqDEKkbApimFpclBQmwSeA7YEITIGNur64NwyGQOdfQsnIwNgkUv0IJU9gkE4u5HnmmSHseAnQ5AYoSq1spDK+2CSGU1j0KE6NwZjkyiglePEATUBE5NN4VagfFU9TEA44l42RYq6C8tqQtajTuNJZUFmwNwlzFZzZ6kA9pAM0z17ZbxpD8U8orcorfN8k
L2oi9jOtMBL4qWWgsuYrqwQcLgaQDFuhA4Q2n0INDTbNk67gNrk1PNf7YIpgh4CzZAuBwHARoLVDRTqFNpQvqQIFLAwhAIBQABCtNJXrEiCwbwupz9pAalATSpEaLrsil/MQPygqNyKEAl2XFf6NnYu87XpTKhlapl83rfZe3ABiMluh6jKct6eQtyIbf7voVdqfajpz8PGTtyvunumhBlDwvI9L20xmSMNZkb0fW9L2b4ZS1Gsvz6Xx+pKPnBQK
P9t6t5AeQJv5cl7vwyAaQgRgGz3GLtfQBqQAAqWAoAAEEiDKC4BIYI2ocpQJfjfSuURSBINLmwCgpVcBCX6tgxeqQLyykQUQkhIQhIQHVCyKgqdmDYBZPqAAGtwd4Jx4hnD2DLCklxDirjOF8dhnDOT4AAJrQj2HcbQTVvgNV+GcWiWx+xFCMGwAwscihk18A2NY2glGxUsbFNYCFKGv30KfGUxAL4SCSs3KUJBQHgNAg+IoHjkoKkMZATOnImG8
jKHsCJETR6jwtG0OoeZ1R8gvNuFJKSYkQFsVfHBUAd5wzgFAacI1fGQDgIEMwwhmAjFIJ4sBDYKFzwzPbBA8Siw1I4MoIJGA7YuyEuzBk2B5jq01gOO2aRhkc0gMIKAQEGzsyyUUOwAArBA2BMgGjtnAIYbAHo0NwL0im8EwCIR1HqcIwNPZNiAA
```
%%

2
1.md
View File

@ -1,3 +1,3 @@
#cube
#autres
- [[2]]
- [[5]]

2
2.md
View File

@ -1,3 +1,3 @@
#cube
#autres
- [[3]]
- [[8]]

2
3.md
View File

@ -1,2 +1,2 @@
#cube
#autres
- [[4]]

2
4.md
View File

@ -1,2 +1,2 @@
#cube
#autres
- [[1]]

2
5.md
View File

@ -1,2 +1,2 @@
#cube
#autres
- [[6]]

2
6.md
View File

@ -1,3 +1,3 @@
#cube
#autres
- [[4]]
- [[7]]

2
7.md
View File

@ -1,3 +1,3 @@
#cube
#autres
- [[3]]

2
8.md
View File

@ -1,4 +1,4 @@
#cube
#autres
- [[5]]
- [[7]]

9
Baruch de Spinoza.md Normal file
View File

@ -0,0 +1,9 @@
link::
#personne
> [!smallquery]+ Sous-notes de `$= dv.el("span", "[[" + dv.current().file.name + "]]")`
> ```breadcrumbs
> title: false
> type: tree
> dir: down
> ```

12
Il n'y a pas de force intrinsèque des idées vraies.md Normal file
View File

@ -0,0 +1,12 @@
author:: [[Baruch de Spinoza]]
source::
link::
date-seen::2024-05-15
#citation #philosphie
> [!cite] Titre
> Il n'y a pas de force intrinsèque des idées vraies.
^cite
## Interprétation
- [[Pierre Bourdieu]] en à dit que c'était la phrase la plus triste de toute la philosophie

2
Kanban mémoire L3.md
View File

@ -3,7 +3,7 @@
kanban-plugin: basic
---
up:: [[mémoire de L3]]
up:: [[notes mémoire de L3]]
## ❓ A définir

389
Remplissage du plan de L3.md
View File

@ -1,389 +0,0 @@
up:: [[plan du mémoire de L3]]
#informatique #fac
# Introduction
![[mémoire de L3#^abstract]]
# Définition et concepts importants
## Définition de concepts importants
### état
L'état est la capacité, pour un programme, à retenir de l'information.
"State is the ability to remember information, or more precisely, to store a sequence of values in time." (L'état est la capacité à retenir de l'information, ou, plus précisément, à stocker une séquence de valeurs dans le temps) [@royProgrammingParadigmsDummies, p.14].
Il est important de noter que la présence de variables n'implique pas toujours la présence d'état. En effet, une fonction peut avoir un paramètre sans avoir nécessairement d'état. Les variables des fonctions, si elles constituent une référence à une valeur, n'impliquent pas la présence d'état.
Note: la logique combinatoire fournit la preuve qu'il est possible d'établir un système de calcul sans aucune variable ni référence, ce qui rend l'absence d'état évidente [@LogiqueCombinatoire2023].
### 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.
> [!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
Par exemple, le livre "Structure and interpretation of computer programs" [@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 proprié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 [^1].
Cependant, certains auteurs utilisent le terme *procedure* même pour parler du concept théorique et mathématique (qui se rapproche du lambda-calcul) [^2].
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.
> Une fonction peut être appelée plusieurs fois et à plusieurs endroits, ce qui la rend réutilisable dans plusieurs contextes.
> [!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).
### Effet de bord
Un effet de bord est la modification d'état par une fonction.
Du point de vue du développeur, cela arrive lorsqu'une fonction effectue des modifications en dehors de son propre corps. Cela peut être fait en utilisant des références ou des constructions particulières du langage.
Voici des exemples de mécanismes qui permettent des effets de bord [^49]:
- Les variables globales : en permettant à toutes les fonctions d'accéder à un même champ de mémoire, les variables globales leur donnent la possibilité de modifier l'état du système
- les variables statiques locales : en permettant aux objets d'une même classe de partager une variable, on leur permet de générer des effets de bord contrôlés
- les arguments mutables (les arguments passés par référence) : ce mécanisme permet de répercuter la modification d'un paramètre en modification de l'argument, ce qui permet à la fonction de modifier une valeur qui lui a été passée en argument. Cela constitue un effet de bord
-
### Fermeture
Une fermeture (de l'anglais *closure*) est une fonction à laquelle on attache l'environnement local de l'endroit où elle a été définie [^7] [^8].
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) [^8].
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ù elle a été définie) la fermeture a été créée [^6].
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 a été libéré de la pile d'exécution) [^9].
## 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 leur formalisation dans un langage de programmation [^47]. 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 traiter des problèmes spécifiques et reconnus, et comment aboutir à une solution conceptuelle [@ParadigmeProgrammation2023].
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 [^3].
Un paradigme de programmation est souvent principalement décrit par les concepts qu'il implémente ou non [^40].
C'est notamment cette approche qu'emploie la [[taxonomie des paradigmes de programmation]] (référence à une annexe) [@TaxonomiePrincipauxParadigmes].
Cependant, J.Huges, dans son article "Why Functional Programming Matters" [@hughesWhyFunctionalProgramming1989, p.1], fustige le fait que certains paradigmes (particulièrement la programmation fonctionnelle *ref* et la programmation structurée *ref*) sont trop fréquemment définis en termes des fonctionnalités qu'ils n'implémentent pas, ou des contraintes qu'ils posent [^4].
Cela est problématique, car l'absence d'une fonctionnalité ne peut pas expliquer pourquoi un paradigme serait plus intéressant dans certains cas [^5]. L'auteur insiste donc sur le fait que les paradigmes devraient être définis en fonction des avantages structurels qu'ils 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 à notre problématique.
## Description de quelques paradigmes
[[taxonomie des paradigmes de programmation]]
### Programmation impérative
La programmation impérative est un paradigme de programmation dans lequel le contrôle de flot d'exécution est explicite.
Cela signifie que le programme spécifie pas à pas la marche à suivre pour obtenir le bon résultat.
En programmation impérative, chaque étape modifie l'état global du système [^10].
### Programmation déclarative
La programmation déclarative est un paradigme de programmation dans lequel la définition des programmes se fait en déclarant la forme du résultat plutôt que la manière l'obtenir (comme on le fait en [[Remplissage du plan de L3#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.
Le contrôle du flot d'exécution est implicite. En cela, la programmation déclarative s'oppose à la programmation impérative [^11].
Un avantage évident de la programmation déclarative est qu'elle libère le programmeur de certaines charges mentales, notamment celle de spécifier l'ordre d'exécution, le flot de contrôle de l'exécution. Cela rend le paradigme déclaratif plus pratique pour le développeur (plus haut niveau), puisqu'il ne requiert pas de s'occuper de certains détails qui n'influent pas sur le sens du programme [^50].
<!-- 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*). -->
### 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 [^12]: la fonction principale prend en argument l'entrée du problème, puis elle est définie à partir d'autres fonctions, qui sont elles-mêmes 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 langage, ou bien des constantes [^13].
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.
Ces propriétés rapprochent beaucoup la programmation fonctionnelle des mathématiques [^13].
Voici une définition de la programmation fonctionnelle : "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." [@jenkisWhatFunctionalProgramming2015]. Cette définition met l'accent sur le fait que la programmation fonctionnelle cherche à décrire, le plus possible, les programme comme des relations entre une entrée et une sortie, définie par des fonctions. L'auteur appelle "entrées et sorties cachées" ("hidden inputs and outputs") toute référence qui ne passe pas par les paramètres ou le retour des fonctions, ce qui inclut notamment les effets de bord.
Les fonctions 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 d'autres fonctions [^14].
Pour que les fonctions d'ordre supérieur existent, il est nécessaire que les fonctions soient des citoyens de première classe, c'est-à-dire des entités traitées comme des valeurs du langage.
Il est également nécessaire que le langage implémente les [[Remplissage du plan de L3#Fermeture|fermetures]], le cas échéant il serait impossible d'implémenter certaines fonctions d'ordre supérieur.
La programmation fonctionnelle privée des fermetures (et donc des fonctions d'ordre supérieur) s'appelle la programmation fonctionnelle de premier ordre (ref à la taxonomie en annexe).
#### Programmation fonctionnelle pure
La programmation fonctionnelle pure (parfois appelée simplement programmation fonctionnelle) est un paradigme dans lequel toutes les fonctions sont pures, c'est-à-dire qu'il n'existe pas d'état [^15].
### programmation structurée
La programmation structurée peut être définie, du point de vue théorique, comme un paradigme dans lequel le contrôle du flot se fait en utilisant des instructions de contrôle du flot d'exécution particulières (des structures de sélection et d'itération), et qui sont sous la forme de blocks [^16].
Les structures de sélection sont des structures particulières qui permettent de choisir quel groupe d'instruction sera exécuté en fonction de l'état du programme [^17].
Les structures d'itération sont des instructions qui exécutent répétitivement un block jusqu'à ce que le programme atteigne un certain état, ou bien que certaines opérations aient été appliquées sur chaque élément d'une collection [^18].
Il est important de voir que le but de la programmation structurée est de produire des programmes plus clairs et de meilleure qualité, de par la modularité induite par la structuration du programme [^19].
Une autre définition de la programmation structurée est une façon de concevoir les programmes
"In the first phase, that of top-down design, or stepwise refinement, the problem is decomposed into a very small number of simpler subproblems." [@floydParadigmsProgramming1979a, p.1]
"The second phase of the structured programming paradigm entails working upward from the concrete objects and functions of the underlying machine to the more abstract objects and functions used throughout the modules produced by the top-down design. [...] This approach is reffered to as the method of levels of abstraction, or of information hiding." [@floydParadigmsProgramming1979a, pp. 1-2]
"The absence of **gotos** and so on, has very little to do with this [the advantages strutcured programming, especially modularity]. It helps with 'programming in the small', whereas modular design helps with 'programming in the large'. Thus one can enjoy the benefits of structured programming in FORTRAN or assembly language, even if it is a little more work." [@hughesWhyFunctionalProgramming1989, p.2]
### Programmation concurrente
La programmation concurrente permet de gérer des programmes avec plusieurs ensembles d'instructions dont l'exécution doit être indépendante.
En programmation impérative stricte, l'ordre des instructions définit leur ordre d'exécution, ce qui les rend interdépendantes. On dit alors que ces instructions sont séquentielles.
La programmation concurrente introduit le concept de concurrence, lorsque deux parties d'un programme n'ont pas de dépendance l'une avec l'autre [^41].
"Le monde réel est concurrent : il consiste en des activités qui évoluent indépendamment" ("The real world is concurrent: it consists of activities that evolve independently." [@royProgrammingParadigmsDummies, p.25]).
### Les langages multiparadigmes
Il existe beaucoup de langages qui implémentent plusieurs paradigmes de programmation [@ComparisonMultiparadigmProgramming2024]. Ces langages sont appelés langages multiparadigmes.
Par exemple, le langage Prolog implémente à la fois la programmation logique et la programmation impérative [^20].
Un autre exemple peut être trouvé lorsque l'on ajoute une librairie de résolution de contraintes à un langage de programmation. Le paradigme de programmation par contraintes est alors ajouté au langage hôte, qui peut, par exemple, être un langage impératif et orienté objet [^21].
Nous verrons l'avantage des langages de programmation multiparadigmes dans la section [[Remplissage du plan de L3#diversité des approches]]
## Intérêt intrinsèque des paradigmes
On comprend par leur simple définition un premier intérêt des paradigmes de programmation : ils permettent d'exprimer des concepts différents, de donner des approches différentes sur la programmation.
## Définition de la puissance d'expression
La puissance d'expression (ou expressivité) d'un langage est la quantité et la diversité d'idées qu'il peut représenter ou communiquer [^22][^23].
On distingue deux sens du terme. D'un côté, l'expressivité théorique, qui se concentre sur la possibilité théorique d'exprimer une idée dans un langage, indépendamment de la difficulté pour exprimer cette idée. De l'autre côté, l'expressivité pratique, qui se concentre sur la concision et la facilité d'expression de ces idées [^24].
### Expressivité au sens formel
La puissance d'expression au sens formel (ou expressivité formelle) est mesurée en regardant l'ensemble des idées qu'un langage peut exprimer.
Ce concept d'expressivité formelle est surtout utile en mathématiques ou en informatique théorique (notamment dans la théorie des langages formels) [^25]
Pour un langage de programmation, il est presque indispensable d'être aussi expressif qu'une machine de Turing (Turing-complets) (ou un autre modèle de calcul équivalent), car cela est la condition nécessaire et suffisante pour qu'il puisse exprimer les problèmes calculables (par définition).
Il existe tout de même des langages qui n'ont pas la même expressivité formelle.
On peut notamment citer les langages de description de données, dont le but est de représenter des données organisées (par exemple, les langages XML, JSON, YAML...), ou bien les langages de description d'ontologies, qui servent à représenter de façon informatique certains types d'ontologie. Notamment, OWL2 EL et OWL2 RL sont deux langages de description d'ontologies qui n'ont pas la même expressivité formelle : OWL2 EL n'implémente pas certains concepts qui peuvent pourtant être exprimés dans OWL2 RL [^26].
Cependant, ces langages ne sont généralement pas qualifiés de "langages de programmation", puisqu'ils sont incapables d'exprimer un programme (c'est-à-dire des instructions exécutables), mais expriment seulement des données.
Il existe également des langages de programmation qui ne sont pas Turing-complets (par exemple, le langage G-code, dans certaines implémentations [^28]), mais ces langages ne sont pas utilisés pour résoudre des problèmes de programmation : ils sont utilisés à des fins théoriques, ou pour des applications particulières (par exemple, le langage G-code est utilisé pour commander des machines à commande numérique [^27]).
### Expressivité au sens pratique
L'expressivité pratique est la diversité et la quantité d'idées qu'un langage de programmation peut exprimer facilement.
Dans ce sens de l'expressivité, la facilité d'exprimer une idée est primordiale. Comme il est dit dans la section [[Remplissage du plan de L3#Expressivité au sens formel]], la plupart des langages de programmation ont la même expressivité théorique. Cependant, il n'est pas suffisant pour l'expressivité pratique qu'une idée soit théoriquement exprimable : il est nécessaire qu'il soit aisé de le faire, que le langage implémente des fonctionnalités directement. Il est, par exemple, possible de faire de la programmation structurée (voir : [[Remplissage du plan de L3#programmation structurée]]) ou de la programmation fonctionnelle (voir : [[Remplissage du plan de L3#programmation fonctionnelle]]) dans un langage qui ne supporte pas nativement ces paradigmes (par exemple le langage assembleur). En général, pour tout concept $x$ implémenté par un langage de programmation $A$, il sera toujours possible de créer un équivalent de $x$ dans un langage $B$ qui ne l'implémente pas nativement (à condition que $B$ soit Turing Complet). Cependant, l'expressivité au sens pratique ne prend pas en compte cette possibilité, et ne considère que les idées directement (ou presque directement) implémentées et exprimables dans un langage.
L'expressivité pratique d'un langage est donc très liée aux paradigmes qu'il implémente. On pourrait même définir l'expressivité au sens pratique d'un langage comme la quantité de paradigmes qu'il implémente.
### Compromis entre expressivité et analysabilité
Plus un langage est expressif, plus il est complexe de l'analyser mathématiquement.
Plus un langage est puissant expressivement au sens formel, plus il devient difficile (et impossible) de démontrer certains théorèmes sur ce formalisme [^29].
Cela est vrai également pour l'expressivité au sens pratique : "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." [@ParadigmeProgrammation2023].
#### Exemple de compromis : automates et grammaires
Les automates à pile et les machines de Turing forment un exemple de compromis entre analysabilité et expressivité formelle.
Les automates à pile reconnaissent les langages non contextuels [^31]. Les machines de Turing reconnaissent les langages contextuels [^32].
Or, les langages non contextuels sont strictement inclus dans les langages récursivement énumérables [^33] .
On peut donc conclure que les machines de Turing ont un pouvoir d'expression formel supérieur à celui des automates à pile.
Cependant, si on pose le problème de l'appartenance d'un mot à un langage donné.
Ce problème est décidable pour tous les langages non contextuels [^34].
Pourtant, ce problème est indécidable pour les machines de Turing [^35].
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 moins analysable (certains problèmes sont décidables sur les automates à pile, mais pas sur les machines de Turing).
#### Exemple de compromis : le non-déterminisme
Un langage de programmation est dit non déterministe lorsque son exécution ne dépend pas uniquement des spécifications du programme, c'est-à-dire que les spécifications laissent un choix lors de l'exécution du programme [^38]. Le non-déterminisme est donc problématique, puisqu'il peut amener à créer des programmes dont le résultat est inattendu ou incertain : il rend les programmes moins analysables.
Ce pendant, certains paradigmes qui peuvent exprimer du non-déterminisme restent utiles pour modéliser certains problèmes (par exemple, la programmation concurrente, voir [[Remplissage du plan de L3#Programmation concurrente]]) [^39].
Une critique
C'est pourquoi certaines fonctionnalités, certains paradigmes, comme le non-déterminisme et les paradigmes qui l'impliquent, devraient être utilisés seulement si cela est nécessaire [^30].
### Implications sur la diversité des paradigmes
Nous avons montré qu'il est nécessaire de faire des choix dans les concepts qu'implémente un paradigme, afin de faire un compromis entre analysabilité et expressivité.
Cela donne une justification à l'existence de différents paradigmes : l'implémentation ou non de certains concepts à de réelles influences, non seulement sur l'expressivité des langages, mais également sur les propriétés de celui-ci (comme le déterminisme).
Il est donc important de pouvoir choisir quels concepts utiliser selon les situations, afin de trouver le meilleur compromis entre expressivité et analysabilité.
# Paradigmes dans l'apprentissage
## Importance des paradigmes dans l'apprentissage
Les paradigmes de programmation jouent un rôle dans l'apprentissage d'un langage. Théoriquement les mêmes idées pourraient être représentées indépendamment du paradigme, mais le paradigme fournit un modèle de pensée, une approche, un cadre. Ces modèles de pensée sont utiles pour apprendre, car le fait d'avoir en tête des modèles, des idées générales sur la façon d'envisager un programme, permet d'apprendre plus aisément [^a]. Les paradigmes sont encore plus importants du point de vue de l'enseignant, qui doit identifier clairement les paradigmes qu'il enseigne pour pouvoir transmettre efficacement les concepts de la programmation [^b].
Le fait d'apprendre des paradigmes, des modèles mentaux, permet également de se détacher du langage de programmation particulier, et d'acquérir des connaissances générales, qui restent valides même lorsque l'on change de langage. Maîtriser un paradigme est utile pour tous les langages qui implémentent ce paradigme[^b].
## Avantages de la diversité
On peut se demander s'il est intéressant d'apprendre plusieurs paradigmes au travers d'un ou plusieurs langages de programmation, si cette diversité des paradigmes est utile pour l'apprentissage.
Au fil du temps, à force de lire et travailler avec du code, nos compétences en programmation augment[^f] et l'on mémorise beaucoup de cas qui nous aideront à résoudre des problèmes plus intuitivement et à construire une bibliothèque mentale de modèles[^c] que n'aura pas un développeur débutant. Les sciences cognitives montrent que la différence principale entre un expert et un débutant n'est pas sa capacité à raisonner, mais plutôt à reconnaître des motifs qu'il a déjà vus [^g]. Cela montre l'importance de se construire une telle "bibliothèque mentale de modèles".
## Conclusion sur les paradigmes pour l'apprentissage
Dans le contexte de l'apprentissage de la programmation, les paradigmes présentent plusieurs intérêts :
- fournir des modèles mentaux à ceux qui apprennent, afin de mieux envisager la programmation
- fournir des abstractions et des connaissances utiles indépendamment du langage.
- fournir des abstractions, des motifs reconnaissables, qui finissent par former une "bibliothèque mentale de modèles"
# Paradigmes pour la résolution de problèmes
## Les paradigmes fournissent un cadre pour la pensée
La définition même de paradigme explique déjà en partie l'existence des différents paradigmes : un paradigme donne une façon d'envisager la programmation. Comme il existe de nombreux types de problèmes, de nombreuses situations à modéliser, il semble normal que de nombreux paradigmes existent pour donner les concepts et outils nécessaires afin d'implémenter efficacement des solutions à ces problèmes.
L'existence de nombreux paradigmes de programmation peut donc être justifiée par diversité des problèmes rencontrés : chaque paradigme permet de répondre à une classe de problèmes précis. Par exemple, la programmation concurrente (voir : [[Remplissage du plan de L3#Programmation concurrente]]) permet de modéliser des situations dans lesquelles deux événements indépendants évoluent en même temps et indépendamment.
L'efficacité peut ici avoir deux sens : l'efficacité pour l'humain, c'est-à-dire l'aisance avec laquelle le développeur pourra implémenter une solution à son problème ; et l'efficacité lors de l'exécution (efficacité pour la machine), qui dépend du temps et de l'espace mémoire nécessaires à l'exécution du programme.
La nécessité de faire des compromis entre expressivité et analysabilité décris plus haut (voir [[Remplissage du plan de L3#compromis entre expressivité et analysabilité]]) peut avoir pour conséquence la nécessité de faire des compromis entre efficacité pour l'humain et efficacité pour la machine. En effet, une plus grande efficacité pour l'humain peut être atteinte par une plus grande expressivité (théorique, mais surtout pratique) ; or, nous avons vu que cela pouvait mener à une moins grande analysabilité du langage, ce qui implique notamment que moins d'optimisation seront possibles lors de l'exécution d'un programme.
## Avantages des langages multiparadigmes
Lors de la résolution de problèmes, il peut être utile d'avoir de nombreux modèles à disposition, afin de pouvoir choisir celui qui correspond le mieux au problème actuel. Si ces modèles sont directement implémentés dans notre langage de programmation (s'il supporte les bons paradigmes), la résolution de notre problème sera beaucoup plus aisée. "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." : Un langage devrait, dans l'idéal, intégrer de manière cohérente un grand nombre de paradigmes, pour permettre au développeur de choisir quels concepts il souhaite utiliser, sans être encombré par les autres [@royProgrammingParadigmsDummies p.10].
Certains langages ne nécessitent pas un grand pouvoir d'expression, car ils répondent à un besoin spécifique (voir [[Remplissage du plan de L3#Expressivité au sens formel]]). Cependant, la plupart des langages ont pour but de pouvoir résoudre une grande diversité de problèmes, et il est donc nécessaire qu'ils permettent de décrire et manipuler aisément un grand nombre de concepts.
## créer un paradigme pour chaque type de problème
Le principe de l'extension créative (de l'anglais *creative extension principle*) est une méthode qui permet de créer de nouveaux paradigmes.
Elle permet de trouver et d'organiser des concepts utiles à la programmation, pour réellement former un paradigme [^42].
L'extension créative part de la constatation qu'un problème nécessite des modifications envahissantes (des modifications dans l'ensemble des contextes du programme) pour être résolu.
Il est alors nécessaire de comprendre cette difficulté (pourquoi cette modification devient-elle envahissante ?), et de trouver un concept plus général, plus fondamental, qui résout cette difficulté, c'est-à-dire qui permet d'éliminer ces modifications envahissantes pour retrouver un programme simple [^43].
Par exemple, si l'on cherche à modéliser plusieurs activités indépendantes dans un langage purement impératif, il faut implémenter soi-même plusieurs piles d'exécution, ainsi qu'un ordonnanceur... Les modifications impliquées par ce problème sont envahissantes. Cette complexité peut être évitée si notre langage implémente un concept (et donc un paradigme) : la concurrence (voir [[Remplissage du plan de L3#Programmation concurrente]]) [^44].
La même logique peut s'appliquer à la gestion d'erreurs dans un programme. Si l'on veut être capable de gérer les erreurs dans un programme, il faut ajouter des conditions dans le corps de chaque fonction, pour que chacune retourne le code d'erreur jusqu'à l'appel initial. Les modifications impliquées par ce problème sont envahissantes. Cette complexité peut être évitée si notre langage implémente un concept (et donc un paradigme) : les exceptions [^45].
Floyd, dans son papier "The Paradigms of Programming", explique une méthode similaire qui lui permet de créer de nouveaux paradigmes : lorsqu'il résout un problème complexe, il essaie d'extraire l'essence de sa solution, de la simplifier pour obtenir une solution aussi directe que possible. Il cherche ensuite une règle générale qui lui permettrait de résoudre des problèmes semblables. Cette règle, s'il la trouve, peut être le concept fondateur d'un nouveau paradigme [^46].
On peut donc voir chaque paradigme comme la réponse à un problème particulier, à une situation qui serait complexe à modéliser sans ce paradigme.
Il serait même pertinent, de ce point de vue, d'encourager la création de nouveaux paradigmes dès que l'on trouve des problèmes nouveaux qui sont complexes à résoudre avec les paradigmes existants.
## 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é]]
Connaître un langage de programmation ne permet pas de savoir immédiatement comment résoudre tous les problèmes que l'on risque de rencontrer. Par exemple, la syntaxe des langages dérivés de LISP est très simple, et peut être apprise en peu de temps. Cependant, connaître la syntaxe complète et le fonctionnement d'un langage ne permettra pas de résoudre tous les problèmes : il est également nécessaire d'être capable de "faire le lien" entre un problème et son expression dans un langage de programmation.
C'est ce lien que les paradigmes de programmation permettent de faire. Plus précisément, les paradigmes permettent de faire le lien entre un problème et une solution théorique, un modèle conceptuel qui permet ensuite d'implémenter une solution.
On peut notamment opposer les paradigmes et les méthodes. Une méthode permet de convertir en programme des problèmes déjà reconnus dans le cadre d'un paradigme, d'un écosystème. La méthode ne s'occupe pas de fournir une solution à un problème, ni un modèle pour ce problème, mais permet de convertir cette solution conceptuelle, ce modèle abstrait, en programme dans un langage particulier.
Au contraire, les paradigmes explicitent plutôt quelle vision le développeur doit avoir, et quels concepts il peut utiliser pour construire son modèle du problème. Un paradigme donne donc un cadre pour modéliser un problème donné.
La figure (*figref*) montre les différentes étapes lorsque l'on est confronté à un problème :
1. **Résoudre** le problème : trouver une idée de solution, et construire conceptuellement un modèle qui permet de résoudre notre problème. Ce sont les paradigmes qui nous permettent de faire cela, en donnant une vision sur ce qu'est un programme, et en fournissant des concepts utiles.
2. **Designer** le programme : implémenter concrètement le programme dans un langage de programmation. Ce sont des méthodes, par exemple des design patterns, qui guide le développeur dans cette étape, en lui permettant de convertir des problèmes reconnus en programme dans un langage.
3. **Exécuter** le programme : cette étape est réalisée par un compilateur ou un interpréteur.
4. **Interpréter** les résultats : Pour que les données de sortie du programme deviennent véritablement de la connaissance, il faut leur attacher du sens et un contexte. Il faut pour cela qu'un être humain les interprète. Les statistiques fournissent notamment des outils pour interpréter des séries de données.
![[paradigme_methode_execution_interprétation.excalidraw|300]]
Les paradigmes de programmations peuvent donc être vus comme un outil pour la pensée, qui permet de traduire un problème en une pré-solution, en un modèle conceptuel, en fournissant une vision sur la programmation, des modèles mentaux et des concepts utiles.
# Conclusion
En fournissant un modèle pour penser les programmes informatiques, les paradigmes de programmation permettent à la fois d'améliorer l'apprentissage et la résolution de problèmes.
En effet, l'abstraction fournie par les langages est utile à l'enseignement de la programmation (voir : [[Remplissage du plan de L3#Paradigmes dans l'apprentissages]]).
Les divers concepts fournis par les différents paradigmes permettent également de modéliser au mieux les différents problèmes. Pour un programmeur, avoir à sa disposition un grand nombre de paradigmes permet alors de résoudre plus simplement une plus grande variété de problèmes (voir : [[Remplissage du plan de L3#Paradigmes pour la résolution de problèmes#Les paradigmes fournissent un cadre pour la pensée]].
On comprend notamment, dans ce contexte, l'intérêt particulier des langages multiparadigmes, qui laissent au développeur le choix d'utiliser ou non certains concepts selon ses besoins, mais sans avoir à changer de langage de programmation (voir : [[Remplissage du plan de L3#Paradigmes pour la résolution de problèmes#avantages des langages multi-paradigme]]).
On peut par ailleurs voir les paradigmes comme résultant de la nécessité de résoudre certaines classes de problèmes. Un paradigme serait alors à créer pour chaque nouveau type de problème (voir : [[Remplissage du plan de L3#Paradigmes pour la résolution de problèmes#créer un paradigme pour chaque type de problème]]).
Finalement, on peut comprendre le rôle général des paradigmes dans la résolution de problèmes : permettre la traduction des spécifications et enjeux d'un problème en un modèle conceptuel, en une idée de solution qui est entendable par le développeur (voir : [[Remplissage du plan de L3#Paradigmes pour la résolution de problèmes#Les paradigmes comme outil pour la pensée]] ).
Toutes ces raisons justifient l'existence des nombreux paradigmes de programmation, et encouragent même à en créer de nouveaux.
# Annexes
## contre la distinction entre les paradigmes
La distinction entre les différents paradigmes n'est pas toujours claire : beaucoup de langages sont [[Remplissage du plan de L3#les langages multi-paradigmes|multi-paradigmes]], et certains paradigmes peuvent être utilisés dans presque tous les langages (par exemple, la programmation structurée *ref*)
Certains auteurs considèrent que les paradigmes ne sont pas fondamentalement différents (voir : [[Remplissage du plan de L3#Au sens formel|puissance d'expression > 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 [^36].
Greg Michaelson critique la distinction des paradigmes, en expliquant que, lorsqu'on les analyse profondément, les paradigmes sont en fait proches entre eux [^37].
# footnotes
[^1]: "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." [@abelsonStructureInterpretationComputer1996, p.28]
[^2]: par exemple, Fellesein dans cette expression : "(let x be v in e) is expressible as (apply (procedure x e) v)" [@felleisenExpressivePowerProgramming1990, p.135]
[^3]: "A programming paradigm is an approach to programming a computer based on a mathematical theory or a coherent set of principles." [@royProgrammingParadigmsDummies]
[^4]: "It says a lot about what functional programming is _not_ [...] but not much about what it is." [@hughesWhyFunctionalProgramming1989, p.1]
[^5]: "It is a logical impossibility to make a language more powerful by ommitting features, no matter how bad they may be" [@hughesWhyFunctionalProgramming1989, p.1]
[^6]: 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. [@royProgrammingParadigmsDummies, p.24]
[^7]: "From an implementation viewpoint, a closure combines a procedure with its external references (the references it uses at its definition)." [@royProgrammingParadigmsDummies, p.24]
[^8]: "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." [@FermetureInformatique2024]
[^9]: "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." [@FermetureInformatique2024]
[^10]: "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." [@toalProgrammingParadigms]
[^11]: "Control flow in declarative programming is implicit: the programmer states only what the result should look like, not how to obtain it." [@toalProgrammingParadigms]
[^12]: "In functional programming, control flow is expressed by combining function calls, rather than by assigning values to variables" [@toalProgrammingParadigms]
[^13]: "Functional programming is so called because a program consists entirely of functions. The main program itself is written as a function which recieves the program's input as its argument and delivers the program's output as its result. Typically the main function is defined in terms of other functions, which in turn are defined in terms of still more functions, until at the bottom level the functions are language primitives. These functions are much like ordinary mathematical functions, and in this paper will be defined by ordinary equations." [@hughesWhyFunctionalProgramming1989, p.1]
[^14]: "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." [@FonctionOrdreSuperieur2023]
[^15]: La logique combinatoire est un système de calcul dans lequel toutes les fonctions sont pures (il n'y a que des fonctions d'ordre supérieur dans ce système) [@LogiqueCombinatoire2023]
[^16]: "Structured programming is a programming paradigm aimed at improving the clarity, quality, and development time of a computer program by making extensive use of the structured control flow constructs of selection (if/then/else) and repetition (while and for), block structures, and subroutines." [@StructuredProgrammingWikipedia]
[^17]: "'Selection'; one or a number of statements is executed depending on the state of the program. This is usually expressed with keywords such as if..then..else..endif. The conditional statement should have at least one true condition and each condition should have one exit point at max." [@StructuredProgrammingWikipedia]
[^18]: "'Iteration'; a statement or block is executed until the program reaches a certain state, or operations have been applied to every element of a collection. This is usually expressed with keywords such as while, repeat, for or do..until. Often it is recommended that each loop should only have one entry point (and in the original structural programming, also only one exit point, and a few languages enforce this)." [@StructuredProgrammingWikipedia]
[^19]: "The most important difference between structured and unstructured programs is that the former are designed in a modular way. Modular design brings great productivity improvements. First of all, small modules can be coded quickly and easily. Secondly, general purpose modules can be reused, leading to faster development of subsequent programs. Thirdly, the modules of a program can be tested independently, helping to reduce the time spent debugging." [@hughesWhyFunctionalProgramming1989, p.2]
[^20]: "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." [@royProgrammingParadigmsDummies, p.18]
[^21]: "Solving libraries (e.g., Gecode): The first paradigm is a solver library based on advanced search algorithms, such as Gecode. The second paradigm is added by the host language, e.g., C++ and Java support object-oriented programming." [@royProgrammingParadigmsDummies, p.18]
[^22]: "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." [@ExpressivePowerComputer2023]
[^23]: "The more expressive a language is, the greater the variety and quantity of ideas it can be used to represent" [@ExpressivePowerComputer2023]
[^24]: "The term expressive power may be used with a range of meaning. It may mean a measure of the ideas expressible in that language: regardless of ease (theoretical expressivity); concisely and readily (practical expressivity)" [@ExpressivePowerComputer2023]
[^25]: "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" [@ExpressivePowerComputer2023]
[^26]: "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)." [@ExpressivePowerComputer2023]
[^27]: "G-code (also RS-274) is the most widely used computer numerical control (CNC) and 3D printing programming language. It is used mainly in computer-aided manufacturing to control automated machine tools, as well as for 3D-printer slicer applications. The G stands for geometry. G-code has many variants." [@Gcode2023]
[^28]: "G-code began as a limited language that lacked constructs such as loops, conditional operators, and programmer-declared variables with natural-word-including names (or the expressions in which to use them). It was unable to encode logic but was just a way to "connect the dots" where the programmer figured out many of the dots' locations longhand." [@Gcode2023]
[^29]: "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." [@ExpressivePowerComputer2023]
[^30]: "We conclude that observable nondeterminism should be supported only if its expressive power is needed." [@royProgrammingParadigmsDummies, p.14]
[^31]: "[...] les langages algébriques, appelés aussi langages hors contexte, langages acontextuels, ou langages non contextuels. Ils sont reconnus par un automate à pile." [@HierarchieChomsky2023]
[^32]: "Les 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." [@HierarchieChomsky2023]
[^33]: "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." [@HierarchieChomsky2023]
[^34]: "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)." [@AutomatePile2021]
[^35]: "Le problème de l'appartenance d'un mot à un langage de cette classe [la classe des langages récursivement énumérables] est indécidable." [@HierarchieChomsky2023]
[^36]: "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." [@floydParadigmsProgramming1979a, p.2]
[^37]: "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." [@michaelsonProgrammingParadigmsTuring2020, p.41]
[^38]: "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" [@royProgrammingParadigmsDummies, p.14]
[^39]: "But paradigms that have the power to express observable nondeterminism can be used to model real-world situations and to program independent activities." [@royProgrammingParadigmsDummies, p.14]
[^40]: "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." [@royProgrammingParadigmsDummies, p.10]
[^41]: "For example, consider a program that consists of instructions executing one after the other. The instructions are not independent since they are ordered in time. To implement independence we need a new programming concept called concurrency. When two parts do not interact at all, we say they are concurrent.3 (When the order of execution of two parts is given, we say they are sequential.)" [@royProgrammingParadigmsDummies, p.25]
[^42]: "Concepts are not combined arbitrarily to form paradigms. They can be organized according to the creative extension principle." [@royProgrammingParadigmsDummies, p.16]
[^43]: "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" [@royProgrammingParadigmsDummies, p.17]
[^44]: "If we need to model several independent activities, then we will have to implement several execution stacks, a scheduler, and a mechanism for preempting execution from one activity to another. All this complexity is unnecessary if we add one concept to the language: concurrency." [@royProgrammingParadigmsDummies, p.17]
[^45]: "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." [@royProgrammingParadigmsDummies, p.17]
[^46]: "After solving a challenging problem, ! solve it again from scratch, retracing only the insight of the earlier solution. I repeat this until the solution is as clear and direct as I can hope for. Then I look for a general rule for attacking similar problems, that would have led me to approach the given problem in the most efficient way the first time. Often, such a rule is of permanent value." [@floydParadigmsProgramming1979a, p.3]
[^47]: "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é. 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." [@ParadigmeProgrammation2023]
[^49]: "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" [@EffetBordInformatique2023]
[^50]: "A programming language is low level when its programs require attention to the irrelevant." [@perlisSpecialFeatureEpigrams1982]
[^a]: " - 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." (Minsky, 1970, p.5)
[^b]: "To the teacher of programming, even more, I say: identify the paradigms you use, as fully as you can, then teach them explicitly. They will serve your students when Fortran has replaced Latin and Sanskrit as the archetypal dead language." (Floyd, 1979, p.9)
[^c]: "Experts build up a mental library of patterns" (Brown, 2023, p.81)
[^d]: "If the advancement of the general art of programming requires the continuing invention and elaboration of paradigms, advancement of the art of the individual programmer requires that he expand his repertory of paradigms." (Floyd, 1979, p.3)
[^e]: "seeing a variety of programming paradigms will help further." (Brown, 2023, p.81)
[^f]: "reading and working with more code, and more types of code, will increase proficiency at programming." (Brown, 2023, p.81)
[^g]: "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." (Brown, 2023, p.81)
[^h]: "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" (Brown, 2023, p.84)
Chaque paradigme permet d'avoir une vision différente d'un problème, si un problème nous parait trop complexe à résoudre avec un paradigme, un autre permettra certainement de résoudre plus simplement ce problème. Le fait de connaître une variété de paradigmes de programmation pourra aider[^e] le développeur, en lui permettant de choisir le plus approprié face aux nouveaux problèmes auquel il devra faire face.
D'où l'utilité de voir plusieurs paradigmes de programmation ceux-ci nous permettent d'aborder un problème sous différents angles de vue afin de choisir le plus adapté à nos besoins.
De plus si l'évolution générale de l'art de la programmation exige la continuation de l'invention et l'élaboration de nouveau paradigmes, les développeurs devront étendre leur répertoire de paradigmes[^d].

12
Untitled.md
View File

@ -1,12 +0,0 @@
Bonjour Madame, Monsieur,
Je vous écris car je suis actuellement employé par le SSU pour donner des cours de soutient en informatique à Mlle. Avril THIERRY.
Comme vous me l'aviez expliqué, il lui est difficile de communiquer avec elle pendant les cours.
Je donne des cours d'informatique et de mathématiques depuis plusieurs années, mais je le fais habituellement en présentiel, et je m'appuie sur les réactions, les réponses spontanées, pour connaître les difficultés et orienter mes conseils.
Je me retrouve forcé de constater qu'il a été difficile pour moi de lui donner tous les cours prévus dans le contrat, parce qu'il est presque impossible de savoir si elle a compris ou non, ce qui m'oblige à parler seul et sans retour pendant 1h30.
Face à cette difficulté, je voulais vous avertir que je ne suis pas en capacité de l'accompagner correctement.
Il me semblait important de vous prévenir de cette situation, veuillez m'excuser de ne pas l'avoir fait plus tôt, et je reste à votre disposition pour un échange éventuel à ce sujet.
Très cordialement,
Oscar Plaisant.

1897
actions.excalidraw.md
View File

File diff suppressed because it is too large Load Diff

34
bonjour.md Normal file
View File

@ -0,0 +1,34 @@
---
excalidraw-plugin: parsed
tags:
- excalidraw
excalidraw-open-md: true
---
up::
`$= "[[" + dv.current().file.name + "]]"`
%%
# Excalidraw Data
## Text Elements
## Drawing
```compressed-json
N4KAkARALgngDgUwgLgAQQQDwMYEMA2AlgCYBOuA7hADTgQBuCpAzoQPYB2KqATLZMzYBXUtiRoIACyhQ4zZAHoFAc0JRJQgEYA6bGwC2CgF7N6hbEcK4OCtptbErHALRY8RMpWdx8Q1TdIEfARcZgRmBShcZQUebTieGjoghH0EDihmbgBtcDBQMEKIEm4IAGEYAHkASQRlABlqqCMAawAlAGk2AClqgAUANQBZAHEBpMLIWERSoKI5JH4izG5n
AEYADgBWbS2ATi2AZj2AFgB2Q4A2DZOeAAYNpcgYVbWTy+0Ny7O7/bu7k57Q63Ph5SAUEjqbj3Q7aNZnHg8L6bW5rX6gyZSBCEZTSaF3WHwxHIm48NFbDFFazKYLcO5PCDMKCkNgtBBlNj4NikUoAYjWCAFAomRU0uGwLWULKEHGIHK5PIkzOszDguECGRFkAAZoR8PgAMqwWkSQQeLWM5mshAAdUhkmhDKZLLZRpgJvQZpKDOluI44SyaDWDLYa
uwaheQf+DKlwjg1WIgdQ2QAugzteQ0gnuBwhPqGYRZVhSrg1hbpbL/cwkwVMdNxLwwQBfJ0IBDEbjwgk8IEPR5ghhMVicbiHM4MxgsdgcABynDEo62ZzWawph0pkEIzAAIikoO3uNqCGEGZphLKAKLBNIZJO5/MDoRwYi4fcdoPLy5I4EbQ5Ly4MkQHAtDmeb4IBbASgeaBHvgYR5C2eS1lM8ANhg+iaO2L6aLSE5DtOo6HHhU6cHOHALmg9wEls
WyXFsawbsURYrBIuB3BaW67sEb7cMyQgIAW77oEacBCDaPA2g66Z6oaxpoZI4oaIEFrOtadrEFCQZOlarpyaUXodj6wh+gGnYhmGEadtGA7Uh69IDixqDODwZxnHCPBbAykZOS5GzaJclwnHcX6eQOqlsvK3J8v8MXsae4qShWcqclFSrkBwqrqukUAWhCGkOmgQX2ZikjYriOVoFs1mYmE0GoIcwV3MGA6xk+CZJqm6aZgg2ZoPe4EDklVZ3mBp
7nsQV6pNlHVpo+z6vnV8JrF+v7nBsexooBhYgRI2TZAAqhkajBMQ2j6MQvLqFuqDXbgqDEKkbApimFpclBQmwSeA7YEITIGNur64NwyGQOdfQsnIwNgkUv0IJU9gkE4u5HnmmSHseAnQ5AYoSq1spDK+2CSGU1j0KE6NwZjkyiglePEATUBE5NN4VagfFU9TEA44l42RYq6C8tqQtajTuNJZUFmwNwlzFZzZ6kA9pAM0z17ZbxpD8U8orcorfN8k
L2oi9jOtMBL4qWWgsuYrqwQcLgaQDFuhA4Q2n0INDTbNk67gNrk1PNf7YIpgh4CzZAuBwHARoLVDRTqFNpQvqQIFLAwhAIBQABCtNJXrEiCwbwupz9pAalATSpEaLrsil/MQPygqNyKEAl2XFf6NnYu87XpTKhlapl83rfZe3ABiMluh6jKct6eQtyIbf7voVdqfajpz8PGTtyvunumhBlDwvI9L20xmSMNZkb0fW9L2b4ZS1Gsvz6Xx+pKPnBQK
P9t6t5AeQJv5cl7vwyAaQgRgGz3GLtfQBqQAAqWAoAAEEiDKC4BIYI2ocpQJfjfSuURSBINLmwCgpVcBCX6tgxeqQLyykQUQkhIQhIQHVCyKgqdmDYBZPqAAGtwd4Jx4hnD2DLCklxDirjOF8dhnDOT4AAJrQj2HcbQTVvgNV+GcWiWx+xFCMGwAwscihk18A2NY2glGxUsbFNYCFKGv30KfGUxAL4SCSs3KUJBQHgNAg+IoHjkoKkMZATOnImG8
jKHsCJETR6jwtG0OoeZ1R8gvNuFJKSYkQFsVfHBUAd5wzgFAacI1fGQDgIEMwwhmAjFIJ4sBDYKFzwzPbBA8Siw1I4MoIJGA7YuyEuzBk2B5jq01gOO2aRhkc0gMIKAQEGzsyyUUOwAArBA2BMgGjtnAIYbAHo0NwL0im8EwCIR1HqcIwNPZNiAA
```
%%

10
chimie.md Normal file
View File

@ -0,0 +1,10 @@
up:: [[science]]
#science
> [!smallquery]+ Sous-notes de `$= dv.el("span", "[[" + dv.current().file.name + "]]")`
> ```breadcrumbs
> title: false
> type: tree
> dir: down
> ```

2
daily/2024-03-26.md
View File

@ -2,7 +2,7 @@
spaced_repetition: 0
kung_fu: 0
---
[[mémoire de L3]]
[[notes mémoire de L3]]
## Todo
- spaced repetition : `INPUT[toggle(onValue(1), offValue(0)):spaced_repetition]`
- kung-fu : `INPUT[number:kung_fu]` minutes

18
daily/2024-05-18.md Normal file
View File

@ -0,0 +1,18 @@
---
spaced_repetition: 0
kung_fu: 0
---
## Todo
- spaced repetition : `INPUT[toggle(onValue(1), offValue(0)):spaced_repetition]`
- kung-fu : `INPUT[number:kung_fu]` minutes
## I did
> [!smallquery]+ Modified files
> ```dataview
> LIST file.mtime
> where file.mtime > date(this.file.name) and file.mtime < (date(this.file.name) + dur(1 day)) sort file.mtime asc
> ```
## I am gratefull to

18
daily/2024-05-19.md Normal file
View File

@ -0,0 +1,18 @@
---
spaced_repetition: 0
kung_fu: 0
---
## Todo
- spaced repetition : `INPUT[toggle(onValue(1), offValue(0)):spaced_repetition]`
- kung-fu : `INPUT[number:kung_fu]` minutes
## I did
> [!smallquery]+ Modified files
> ```dataview
> LIST file.mtime
> where file.mtime > date(this.file.name) and file.mtime < (date(this.file.name) + dur(1 day)) sort file.mtime asc
> ```
## I am gratefull to

18
daily/2024-05-21.md Normal file
View File

@ -0,0 +1,18 @@
---
spaced_repetition: 0
kung_fu: 0
---
## Todo
- spaced repetition : `INPUT[toggle(onValue(1), offValue(0)):spaced_repetition]`
- kung-fu : `INPUT[number:kung_fu]` minutes
## I did
> [!smallquery]+ Modified files
> ```dataview
> LIST file.mtime
> where file.mtime > date(this.file.name) and file.mtime < (date(this.file.name) + dur(1 day)) sort file.mtime asc
> ```
## I am gratefull to

23
daily/2024-05-14.md → daily/2024-05-25.md
View File

@ -4,18 +4,25 @@ kung_fu: 0
---
## Todo
- [ ] #task demander SSU copie dossier 1/3 temps ⏫ 📅 2024-06-04
- [ ] #task envoyer culture internet (feldup, myhouse, la maison des livres) à julien
- [ ] #task remettre camille
- [ ] #task courrier recommandé pour annuler plainte 🔺
- [ ] #task payer felix
- [ ] #task gérer CERCIP ⏫
- spaced repetition : `INPUT[toggle(onValue(1), offValue(0)):spaced_repetition]`
- kung-fu : `INPUT[number:kung_fu]` minutes
## I did
- fait fonctionner le [[obsidian plugin hypothesis]]
### Anniversaire
#### Personnes invitées
check si elles ont confirmé
- [ ] Antonin
- [-] Benoit
- [x] Manon et son compagnon
- [x] Anna
- [x] Nicolas
- [x] Max
- [x] Catherine
- [x] Dario
- [-] Matiss
- [-] Victor
## I did
> [!smallquery]+ Modified files
> ```dataview
> LIST file.mtime

18
flashcards citations.md
View File

@ -1 +1,19 @@
André Comte-Sponville
Sur le travail qui n'est pas une valeur morale
L_ t_ n_ p_ u_ v_ m_, c_ c_ q_ p_ l_ p_ m_, l_ v_, e_ l_ s_ (*c'_-a-d_, a_ f_, t_ c_ s*).
L_ t_ e_ l_-m_ n_ v_ r_ - a_ s_ d_ v_ m_ - c'_ p_ o_ l_ p_.
I_ n'_ p_ u_ v_ m_, c_ p_ i_ u_ v_ m_.
I_ n'_ p_ u_ d_, c_ p_ i_ u_.
??
Le travail n'est pas une valeur morale, c'est ce que prouvent le premier mai, les vacances, et le salaire (c'est-à-dire, au fond, trois conquêtes syndicales).
Le travail en lui-même ne vaut rien - au sens des valeurs morales - c'est pourquoi on le paie.
Il n'est pas une valeur morale, c'est pourquoi il a une valeur marchande.
Il n'est pas un devoir, c'est pourquoi il a un prix.
Voltaire sur ce qu'est une nation.
L'e_ d'u_ n_ r_ t_ d_ l_ p_ n_ q_ f_ t_ l_ g_, e_ n_ p_ l_ e_ l_ g_.
??
L'esprit d'une nation réside toujours dans le petit nombre qui fait travailler le grand, est nourri par lui et le gouverne.

2
la raison ne saurait réprimer les affects.md
View File

@ -5,7 +5,7 @@ aliases:
- la connaissance vraie du bien et du mal ne saurait réprimer aucun affect en tant que c'est une connaissance vraie
---
author::[[Spinoza]]
author::[[Baruch de Spinoza]]
source::[[Spinoza - Ethique]]
link::
date-seen::2024-04-15

16
la vertu ne sauvera pas le monde.md Normal file
View File

@ -0,0 +1,16 @@
author::[[Frédéric Lordon]]
source::Les blogs du monde diplo - La pompe à finance
link::https://blog.mondediplo.net/detruire-le-capitalisme-avant-qu-il-ne-nous
date-seen::2024-05-16
#citation #politique #science/économie
> [!cite] `$= dv.current().author + (" — " + dv.current().source).repeat(!!dv.current().source)`
> Il n’y a que les amateurs de bondieuseries sécularisées pour croire que la vertu sauvera le monde, c’est-à-dire auto-régulera les salaires patronaux, auto-disciplinera la finance, et auto-nettoiera les petites salissures de l’industrie. Sauf imbécillité complète caparaçonnée d’idéologie, nul ne peut croire que ceux à qui on donne toutes les autorisations n’iront pas au bout de toutes les autorisations. D’ailleurs ils y vont.
^cite
## Interprétation
- l'auto-régulation des marchés est impossible
- cela supposerait que les vertus individuelles empêchent quiconque d'abuser des autorisations données
- tout ce qui est autorisé sera fait
- il faut nécessairement réguler, interdire au patrons, marchés, financiers...

420
mémoire de L3.md
View File

@ -1,43 +1,389 @@
---
difficulty: 8
due: 2024-03-05
---
up::[[devoirs]]
title::
#devoir #fac #informatique
up:: [[notes mémoire de L3]]
#informatique #fac
> [!smallquery]+ Sous-notes de `$= dv.el("span", "[[" + dv.current().file.name + "]]")`
> ```breadcrumbs
> title: false
> type: tree
> dir: down
> ```
# Sujet
- il existe de nombreux paradigmes de programmation
- sachant que 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 allons étudier :
- une définition de ce qu'est un paradigme de programmation
- une présentation de plusieurs paradigmes
- en quoi certains paradigmes sont plus adaptés
- pour l'apprentissage
- pour la résolution de problèmes particuliers
- 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
# Introduction
![[notes mémoire de L3#^abstract]]
# Définition et concepts importants
## Définition de concepts importants
# Réglages
### état
A rendre pour le
```meta-bind
INPUT[date:due]
```
L'état est la capacité, pour un programme, à retenir de l'information.
"State is the ability to remember information, or more precisely, to store a sequence of values in time." (L'état est la capacité à retenir de l'information, ou, plus précisément, à stocker une séquence de valeurs dans le temps) [@royProgrammingParadigmsDummies, p.14].
Difficulté :
```meta-bind
INPUT[slider(minValue(0), maxValue(10)):difficulty]
```
Il est important de noter que la présence de variables n'implique pas toujours la présence d'état. En effet, une fonction peut avoir un paramètre sans avoir nécessairement d'état. Les variables des fonctions, si elles constituent une référence à une valeur, n'impliquent pas la présence d'état.
Note: la logique combinatoire fournit la preuve qu'il est possible d'établir un système de calcul sans aucune variable ni référence, ce qui rend l'absence d'état évidente [@LogiqueCombinatoire2023].
### 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.
> [!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
Par exemple, le livre "Structure and interpretation of computer programs" [@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 propriétés de cette fonction (une définition déclarative, voir [[mémoire 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 [^1].
Cependant, certains auteurs utilisent le terme *procedure* même pour parler du concept théorique et mathématique (qui se rapproche du lambda-calcul) [^2].
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.
> Une fonction peut être appelée plusieurs fois et à plusieurs endroits, ce qui la rend réutilisable dans plusieurs contextes.
> [!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).
### Effet de bord
Un effet de bord est la modification d'état par une fonction.
Du point de vue du développeur, cela arrive lorsqu'une fonction effectue des modifications en dehors de son propre corps. Cela peut être fait en utilisant des références ou des constructions particulières du langage.
Voici des exemples de mécanismes qui permettent des effets de bord [^49]:
- Les variables globales : en permettant à toutes les fonctions d'accéder à un même champ de mémoire, les variables globales leur donnent la possibilité de modifier l'état du système
- les variables statiques locales : en permettant aux objets d'une même classe de partager une variable, on leur permet de générer des effets de bord contrôlés
- les arguments mutables (les arguments passés par référence) : ce mécanisme permet de répercuter la modification d'un paramètre en modification de l'argument, ce qui permet à la fonction de modifier une valeur qui lui a été passée en argument. Cela constitue un effet de bord
-
### Fermeture
Une fermeture (de l'anglais *closure*) est une fonction à laquelle on attache l'environnement local de l'endroit où elle a été définie [^7] [^8].
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) [^8].
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ù elle a été définie) la fermeture a été créée [^6].
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 a été libéré de la pile d'exécution) [^9].
## 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 leur formalisation dans un langage de programmation [^47]. 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 traiter des problèmes spécifiques et reconnus, et comment aboutir à une solution conceptuelle [@ParadigmeProgrammation2023].
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 [^3].
Un paradigme de programmation est souvent principalement décrit par les concepts qu'il implémente ou non [^40].
C'est notamment cette approche qu'emploie la [[taxonomie des paradigmes de programmation]] (référence à une annexe) [@TaxonomiePrincipauxParadigmes].
Cependant, J.Huges, dans son article "Why Functional Programming Matters" [@hughesWhyFunctionalProgramming1989, p.1], fustige le fait que certains paradigmes (particulièrement la programmation fonctionnelle *ref* et la programmation structurée *ref*) sont trop fréquemment définis en termes des fonctionnalités qu'ils n'implémentent pas, ou des contraintes qu'ils posent [^4].
Cela est problématique, car l'absence d'une fonctionnalité ne peut pas expliquer pourquoi un paradigme serait plus intéressant dans certains cas [^5]. L'auteur insiste donc sur le fait que les paradigmes devraient être définis en fonction des avantages structurels qu'ils 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 à notre problématique.
## Description de quelques paradigmes
[[taxonomie des paradigmes de programmation]]
### Programmation impérative
La programmation impérative est un paradigme de programmation dans lequel le contrôle de flot d'exécution est explicite.
Cela signifie que le programme spécifie pas à pas la marche à suivre pour obtenir le bon résultat.
En programmation impérative, chaque étape modifie l'état global du système [^10].
### Programmation déclarative
La programmation déclarative est un paradigme de programmation dans lequel la définition des programmes se fait en déclarant la forme du résultat plutôt que la manière l'obtenir (comme on le fait en [[mémoire de L3#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.
Le contrôle du flot d'exécution est implicite. En cela, la programmation déclarative s'oppose à la programmation impérative [^11].
Un avantage évident de la programmation déclarative est qu'elle libère le programmeur de certaines charges mentales, notamment celle de spécifier l'ordre d'exécution, le flot de contrôle de l'exécution. Cela rend le paradigme déclaratif plus pratique pour le développeur (plus haut niveau), puisqu'il ne requiert pas de s'occuper de certains détails qui n'influent pas sur le sens du programme [^50].
<!-- 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*). -->
### 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 [^12]: la fonction principale prend en argument l'entrée du problème, puis elle est définie à partir d'autres fonctions, qui sont elles-mêmes 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 langage, ou bien des constantes [^13].
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.
Ces propriétés rapprochent beaucoup la programmation fonctionnelle des mathématiques [^13].
Voici une définition de la programmation fonctionnelle : "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." [@jenkisWhatFunctionalProgramming2015]. Cette définition met l'accent sur le fait que la programmation fonctionnelle cherche à décrire, le plus possible, les programme comme des relations entre une entrée et une sortie, définie par des fonctions. L'auteur appelle "entrées et sorties cachées" ("hidden inputs and outputs") toute référence qui ne passe pas par les paramètres ou le retour des fonctions, ce qui inclut notamment les effets de bord.
Les fonctions 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 d'autres fonctions [^14].
Pour que les fonctions d'ordre supérieur existent, il est nécessaire que les fonctions soient des citoyens de première classe, c'est-à-dire des entités traitées comme des valeurs du langage.
Il est également nécessaire que le langage implémente les [[mémoire de L3#Fermeture|fermetures]], le cas échéant il serait impossible d'implémenter certaines fonctions d'ordre supérieur.
La programmation fonctionnelle privée des fermetures (et donc des fonctions d'ordre supérieur) s'appelle la programmation fonctionnelle de premier ordre (ref à la taxonomie en annexe).
#### Programmation fonctionnelle pure
La programmation fonctionnelle pure (parfois appelée simplement programmation fonctionnelle) est un paradigme dans lequel toutes les fonctions sont pures, c'est-à-dire qu'il n'existe pas d'état [^15].
### programmation structurée
La programmation structurée peut être définie, du point de vue théorique, comme un paradigme dans lequel le contrôle du flot se fait en utilisant des instructions de contrôle du flot d'exécution particulières (des structures de sélection et d'itération), et qui sont sous la forme de blocks [^16].
Les structures de sélection sont des structures particulières qui permettent de choisir quel groupe d'instruction sera exécuté en fonction de l'état du programme [^17].
Les structures d'itération sont des instructions qui exécutent répétitivement un block jusqu'à ce que le programme atteigne un certain état, ou bien que certaines opérations aient été appliquées sur chaque élément d'une collection [^18].
Il est important de voir que le but de la programmation structurée est de produire des programmes plus clairs et de meilleure qualité, de par la modularité induite par la structuration du programme [^19].
Une autre définition de la programmation structurée est une façon de concevoir les programmes
"In the first phase, that of top-down design, or stepwise refinement, the problem is decomposed into a very small number of simpler subproblems." [@floydParadigmsProgramming1979a, p.1]
"The second phase of the structured programming paradigm entails working upward from the concrete objects and functions of the underlying machine to the more abstract objects and functions used throughout the modules produced by the top-down design. [...] This approach is reffered to as the method of levels of abstraction, or of information hiding." [@floydParadigmsProgramming1979a, pp. 1-2]
"The absence of **gotos** and so on, has very little to do with this [the advantages strutcured programming, especially modularity]. It helps with 'programming in the small', whereas modular design helps with 'programming in the large'. Thus one can enjoy the benefits of structured programming in FORTRAN or assembly language, even if it is a little more work." [@hughesWhyFunctionalProgramming1989, p.2]
### Programmation concurrente
La programmation concurrente permet de gérer des programmes avec plusieurs ensembles d'instructions dont l'exécution doit être indépendante.
En programmation impérative stricte, l'ordre des instructions définit leur ordre d'exécution, ce qui les rend interdépendantes. On dit alors que ces instructions sont séquentielles.
La programmation concurrente introduit le concept de concurrence, lorsque deux parties d'un programme n'ont pas de dépendance l'une avec l'autre [^41].
"Le monde réel est concurrent : il consiste en des activités qui évoluent indépendamment" ("The real world is concurrent: it consists of activities that evolve independently." [@royProgrammingParadigmsDummies, p.25]).
### Les langages multiparadigmes
Il existe beaucoup de langages qui implémentent plusieurs paradigmes de programmation [@ComparisonMultiparadigmProgramming2024]. Ces langages sont appelés langages multiparadigmes.
Par exemple, le langage Prolog implémente à la fois la programmation logique et la programmation impérative [^20].
Un autre exemple peut être trouvé lorsque l'on ajoute une librairie de résolution de contraintes à un langage de programmation. Le paradigme de programmation par contraintes est alors ajouté au langage hôte, qui peut, par exemple, être un langage impératif et orienté objet [^21].
Nous verrons l'avantage des langages de programmation multiparadigmes dans la section [[mémoire de L3#diversité des approches]]
## Intérêt intrinsèque des paradigmes
On comprend par leur simple définition un premier intérêt des paradigmes de programmation : ils permettent d'exprimer des concepts différents, de donner des approches différentes sur la programmation.
## Définition de la puissance d'expression
La puissance d'expression (ou expressivité) d'un langage est la quantité et la diversité d'idées qu'il peut représenter ou communiquer [^22][^23].
On distingue deux sens du terme. D'un côté, l'expressivité théorique, qui se concentre sur la possibilité théorique d'exprimer une idée dans un langage, indépendamment de la difficulté pour exprimer cette idée. De l'autre côté, l'expressivité pratique, qui se concentre sur la concision et la facilité d'expression de ces idées [^24].
### Expressivité au sens formel
La puissance d'expression au sens formel (ou expressivité formelle) est mesurée en regardant l'ensemble des idées qu'un langage peut exprimer.
Ce concept d'expressivité formelle est surtout utile en mathématiques ou en informatique théorique (notamment dans la théorie des langages formels) [^25]
Pour un langage de programmation, il est presque indispensable d'être aussi expressif qu'une machine de Turing (Turing-complets) (ou un autre modèle de calcul équivalent), car cela est la condition nécessaire et suffisante pour qu'il puisse exprimer les problèmes calculables (par définition).
Il existe tout de même des langages qui n'ont pas la même expressivité formelle.
On peut notamment citer les langages de description de données, dont le but est de représenter des données organisées (par exemple, les langages XML, JSON, YAML...), ou bien les langages de description d'ontologies, qui servent à représenter de façon informatique certains types d'ontologie. Notamment, OWL2 EL et OWL2 RL sont deux langages de description d'ontologies qui n'ont pas la même expressivité formelle : OWL2 EL n'implémente pas certains concepts qui peuvent pourtant être exprimés dans OWL2 RL [^26].
Cependant, ces langages ne sont généralement pas qualifiés de "langages de programmation", puisqu'ils sont incapables d'exprimer un programme (c'est-à-dire des instructions exécutables), mais expriment seulement des données.
Il existe également des langages de programmation qui ne sont pas Turing-complets (par exemple, le langage G-code, dans certaines implémentations [^28]), mais ces langages ne sont pas utilisés pour résoudre des problèmes de programmation : ils sont utilisés à des fins théoriques, ou pour des applications particulières (par exemple, le langage G-code est utilisé pour commander des machines à commande numérique [^27]).
### Expressivité au sens pratique
L'expressivité pratique est la diversité et la quantité d'idées qu'un langage de programmation peut exprimer facilement.
Dans ce sens de l'expressivité, la facilité d'exprimer une idée est primordiale. Comme il est dit dans la section [[mémoire de L3#Expressivité au sens formel]], la plupart des langages de programmation ont la même expressivité théorique. Cependant, il n'est pas suffisant pour l'expressivité pratique qu'une idée soit théoriquement exprimable : il est nécessaire qu'il soit aisé de le faire, que le langage implémente des fonctionnalités directement. Il est, par exemple, possible de faire de la programmation structurée (voir : [[mémoire de L3#programmation structurée]]) ou de la programmation fonctionnelle (voir : [[mémoire de L3#programmation fonctionnelle]]) dans un langage qui ne supporte pas nativement ces paradigmes (par exemple le langage assembleur). En général, pour tout concept $x$ implémenté par un langage de programmation $A$, il sera toujours possible de créer un équivalent de $x$ dans un langage $B$ qui ne l'implémente pas nativement (à condition que $B$ soit Turing Complet). Cependant, l'expressivité au sens pratique ne prend pas en compte cette possibilité, et ne considère que les idées directement (ou presque directement) implémentées et exprimables dans un langage.
L'expressivité pratique d'un langage est donc très liée aux paradigmes qu'il implémente. On pourrait même définir l'expressivité au sens pratique d'un langage comme la quantité de paradigmes qu'il implémente.
### Compromis entre expressivité et analysabilité
Plus un langage est expressif, plus il est complexe de l'analyser mathématiquement.
Plus un langage est puissant expressivement au sens formel, plus il devient difficile (et impossible) de démontrer certains théorèmes sur ce formalisme [^29].
Cela est vrai également pour l'expressivité au sens pratique : "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." [@ParadigmeProgrammation2023].
#### Exemple de compromis : automates et grammaires
Les automates à pile et les machines de Turing forment un exemple de compromis entre analysabilité et expressivité formelle.
Les automates à pile reconnaissent les langages non contextuels [^31]. Les machines de Turing reconnaissent les langages contextuels [^32].
Or, les langages non contextuels sont strictement inclus dans les langages récursivement énumérables [^33] .
On peut donc conclure que les machines de Turing ont un pouvoir d'expression formel supérieur à celui des automates à pile.
Cependant, si on pose le problème de l'appartenance d'un mot à un langage donné.
Ce problème est décidable pour tous les langages non contextuels [^34].
Pourtant, ce problème est indécidable pour les machines de Turing [^35].
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 moins analysable (certains problèmes sont décidables sur les automates à pile, mais pas sur les machines de Turing).
#### Exemple de compromis : le non-déterminisme
Un langage de programmation est dit non déterministe lorsque son exécution ne dépend pas uniquement des spécifications du programme, c'est-à-dire que les spécifications laissent un choix lors de l'exécution du programme [^38]. Le non-déterminisme est donc problématique, puisqu'il peut amener à créer des programmes dont le résultat est inattendu ou incertain : il rend les programmes moins analysables.
Ce pendant, certains paradigmes qui peuvent exprimer du non-déterminisme restent utiles pour modéliser certains problèmes (par exemple, la programmation concurrente, voir [[mémoire de L3#Programmation concurrente]]) [^39].
Une critique
C'est pourquoi certaines fonctionnalités, certains paradigmes, comme le non-déterminisme et les paradigmes qui l'impliquent, devraient être utilisés seulement si cela est nécessaire [^30].
### Implications sur la diversité des paradigmes
Nous avons montré qu'il est nécessaire de faire des choix dans les concepts qu'implémente un paradigme, afin de faire un compromis entre analysabilité et expressivité.
Cela donne une justification à l'existence de différents paradigmes : l'implémentation ou non de certains concepts à de réelles influences, non seulement sur l'expressivité des langages, mais également sur les propriétés de celui-ci (comme le déterminisme).
Il est donc important de pouvoir choisir quels concepts utiliser selon les situations, afin de trouver le meilleur compromis entre expressivité et analysabilité.
# Paradigmes dans l'apprentissage
## Importance des paradigmes dans l'apprentissage
Les paradigmes de programmation jouent un rôle dans l'apprentissage d'un langage. Théoriquement les mêmes idées pourraient être représentées indépendamment du paradigme, mais le paradigme fournit un modèle de pensée, une approche, un cadre. Ces modèles de pensée sont utiles pour apprendre, car le fait d'avoir en tête des modèles, des idées générales sur la façon d'envisager un programme, permet d'apprendre plus aisément [^a]. Les paradigmes sont encore plus importants du point de vue de l'enseignant, qui doit identifier clairement les paradigmes qu'il enseigne pour pouvoir transmettre efficacement les concepts de la programmation [^b].
Le fait d'apprendre des paradigmes, des modèles mentaux, permet également de se détacher du langage de programmation particulier, et d'acquérir des connaissances générales, qui restent valides même lorsque l'on change de langage. Maîtriser un paradigme est utile pour tous les langages qui implémentent ce paradigme[^b].
## Avantages de la diversité
On peut se demander s'il est intéressant d'apprendre plusieurs paradigmes au travers d'un ou plusieurs langages de programmation, si cette diversité des paradigmes est utile pour l'apprentissage.
Au fil du temps, à force de lire et travailler avec du code, nos compétences en programmation augment[^f] et l'on mémorise beaucoup de cas qui nous aideront à résoudre des problèmes plus intuitivement et à construire une bibliothèque mentale de modèles[^c] que n'aura pas un développeur débutant. Les sciences cognitives montrent que la différence principale entre un expert et un débutant n'est pas sa capacité à raisonner, mais plutôt à reconnaître des motifs qu'il a déjà vus [^g]. Cela montre l'importance de se construire une telle "bibliothèque mentale de modèles".
## Conclusion sur les paradigmes pour l'apprentissage
Dans le contexte de l'apprentissage de la programmation, les paradigmes présentent plusieurs intérêts :
- fournir des modèles mentaux à ceux qui apprennent, afin de mieux envisager la programmation
- fournir des abstractions et des connaissances utiles indépendamment du langage.
- fournir des abstractions, des motifs reconnaissables, qui finissent par former une "bibliothèque mentale de modèles"
# Paradigmes pour la résolution de problèmes
## Les paradigmes fournissent un cadre pour la pensée
La définition même de paradigme explique déjà en partie l'existence des différents paradigmes : un paradigme donne une façon d'envisager la programmation. Comme il existe de nombreux types de problèmes, de nombreuses situations à modéliser, il semble normal que de nombreux paradigmes existent pour donner les concepts et outils nécessaires afin d'implémenter efficacement des solutions à ces problèmes.
L'existence de nombreux paradigmes de programmation peut donc être justifiée par diversité des problèmes rencontrés : chaque paradigme permet de répondre à une classe de problèmes précis. Par exemple, la programmation concurrente (voir : [[mémoire de L3#Programmation concurrente]]) permet de modéliser des situations dans lesquelles deux événements indépendants évoluent en même temps et indépendamment.
L'efficacité peut ici avoir deux sens : l'efficacité pour l'humain, c'est-à-dire l'aisance avec laquelle le développeur pourra implémenter une solution à son problème ; et l'efficacité lors de l'exécution (efficacité pour la machine), qui dépend du temps et de l'espace mémoire nécessaires à l'exécution du programme.
La nécessité de faire des compromis entre expressivité et analysabilité décris plus haut (voir [[mémoire de L3#compromis entre expressivité et analysabilité]]) peut avoir pour conséquence la nécessité de faire des compromis entre efficacité pour l'humain et efficacité pour la machine. En effet, une plus grande efficacité pour l'humain peut être atteinte par une plus grande expressivité (théorique, mais surtout pratique) ; or, nous avons vu que cela pouvait mener à une moins grande analysabilité du langage, ce qui implique notamment que moins d'optimisation seront possibles lors de l'exécution d'un programme.
## Avantages des langages multiparadigmes
Lors de la résolution de problèmes, il peut être utile d'avoir de nombreux modèles à disposition, afin de pouvoir choisir celui qui correspond le mieux au problème actuel. Si ces modèles sont directement implémentés dans notre langage de programmation (s'il supporte les bons paradigmes), la résolution de notre problème sera beaucoup plus aisée. "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." : Un langage devrait, dans l'idéal, intégrer de manière cohérente un grand nombre de paradigmes, pour permettre au développeur de choisir quels concepts il souhaite utiliser, sans être encombré par les autres [@royProgrammingParadigmsDummies p.10].
Certains langages ne nécessitent pas un grand pouvoir d'expression, car ils répondent à un besoin spécifique (voir [[mémoire de L3#Expressivité au sens formel]]). Cependant, la plupart des langages ont pour but de pouvoir résoudre une grande diversité de problèmes, et il est donc nécessaire qu'ils permettent de décrire et manipuler aisément un grand nombre de concepts.
## créer un paradigme pour chaque type de problème
Le principe de l'extension créative (de l'anglais *creative extension principle*) est une méthode qui permet de créer de nouveaux paradigmes.
Elle permet de trouver et d'organiser des concepts utiles à la programmation, pour réellement former un paradigme [^42].
L'extension créative part de la constatation qu'un problème nécessite des modifications envahissantes (des modifications dans l'ensemble des contextes du programme) pour être résolu.
Il est alors nécessaire de comprendre cette difficulté (pourquoi cette modification devient-elle envahissante ?), et de trouver un concept plus général, plus fondamental, qui résout cette difficulté, c'est-à-dire qui permet d'éliminer ces modifications envahissantes pour retrouver un programme simple [^43].
Par exemple, si l'on cherche à modéliser plusieurs activités indépendantes dans un langage purement impératif, il faut implémenter soi-même plusieurs piles d'exécution, ainsi qu'un ordonnanceur... Les modifications impliquées par ce problème sont envahissantes. Cette complexité peut être évitée si notre langage implémente un concept (et donc un paradigme) : la concurrence (voir [[mémoire de L3#Programmation concurrente]]) [^44].
La même logique peut s'appliquer à la gestion d'erreurs dans un programme. Si l'on veut être capable de gérer les erreurs dans un programme, il faut ajouter des conditions dans le corps de chaque fonction, pour que chacune retourne le code d'erreur jusqu'à l'appel initial. Les modifications impliquées par ce problème sont envahissantes. Cette complexité peut être évitée si notre langage implémente un concept (et donc un paradigme) : les exceptions [^45].
Floyd, dans son papier "The Paradigms of Programming", explique une méthode similaire qui lui permet de créer de nouveaux paradigmes : lorsqu'il résout un problème complexe, il essaie d'extraire l'essence de sa solution, de la simplifier pour obtenir une solution aussi directe que possible. Il cherche ensuite une règle générale qui lui permettrait de résoudre des problèmes semblables. Cette règle, s'il la trouve, peut être le concept fondateur d'un nouveau paradigme [^46].
On peut donc voir chaque paradigme comme la réponse à un problème particulier, à une situation qui serait complexe à modéliser sans ce paradigme.
Il serait même pertinent, de ce point de vue, d'encourager la création de nouveaux paradigmes dès que l'on trouve des problèmes nouveaux qui sont complexes à résoudre avec les paradigmes existants.
## 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 [[mémoire de L3#compromis expressivité vs analysabilité]]
Connaître un langage de programmation ne permet pas de savoir immédiatement comment résoudre tous les problèmes que l'on risque de rencontrer. Par exemple, la syntaxe des langages dérivés de LISP est très simple, et peut être apprise en peu de temps. Cependant, connaître la syntaxe complète et le fonctionnement d'un langage ne permettra pas de résoudre tous les problèmes : il est également nécessaire d'être capable de "faire le lien" entre un problème et son expression dans un langage de programmation.
C'est ce lien que les paradigmes de programmation permettent de faire. Plus précisément, les paradigmes permettent de faire le lien entre un problème et une solution théorique, un modèle conceptuel qui permet ensuite d'implémenter une solution.
On peut notamment opposer les paradigmes et les méthodes. Une méthode permet de convertir en programme des problèmes déjà reconnus dans le cadre d'un paradigme, d'un écosystème. La méthode ne s'occupe pas de fournir une solution à un problème, ni un modèle pour ce problème, mais permet de convertir cette solution conceptuelle, ce modèle abstrait, en programme dans un langage particulier.
Au contraire, les paradigmes explicitent plutôt quelle vision le développeur doit avoir, et quels concepts il peut utiliser pour construire son modèle du problème. Un paradigme donne donc un cadre pour modéliser un problème donné.
La figure (*figref*) montre les différentes étapes lorsque l'on est confronté à un problème :
1. **Résoudre** le problème : trouver une idée de solution, et construire conceptuellement un modèle qui permet de résoudre notre problème. Ce sont les paradigmes qui nous permettent de faire cela, en donnant une vision sur ce qu'est un programme, et en fournissant des concepts utiles.
2. **Designer** le programme : implémenter concrètement le programme dans un langage de programmation. Ce sont des méthodes, par exemple des design patterns, qui guide le développeur dans cette étape, en lui permettant de convertir des problèmes reconnus en programme dans un langage.
3. **Exécuter** le programme : cette étape est réalisée par un compilateur ou un interpréteur.
4. **Interpréter** les résultats : Pour que les données de sortie du programme deviennent véritablement de la connaissance, il faut leur attacher du sens et un contexte. Il faut pour cela qu'un être humain les interprète. Les statistiques fournissent notamment des outils pour interpréter des séries de données.
![[paradigme_methode_execution_interprétation.excalidraw|300]]
Les paradigmes de programmations peuvent donc être vus comme un outil pour la pensée, qui permet de traduire un problème en une pré-solution, en un modèle conceptuel, en fournissant une vision sur la programmation, des modèles mentaux et des concepts utiles.
# Conclusion
En fournissant un modèle pour penser les programmes informatiques, les paradigmes de programmation permettent à la fois d'améliorer l'apprentissage et la résolution de problèmes.
En effet, l'abstraction fournie par les langages est utile à l'enseignement de la programmation (voir : [[mémoire de L3#Paradigmes dans l'apprentissages]]).
Les divers concepts fournis par les différents paradigmes permettent également de modéliser au mieux les différents problèmes. Pour un programmeur, avoir à sa disposition un grand nombre de paradigmes permet alors de résoudre plus simplement une plus grande variété de problèmes (voir : [[mémoire de L3#Paradigmes pour la résolution de problèmes#Les paradigmes fournissent un cadre pour la pensée]].
On comprend notamment, dans ce contexte, l'intérêt particulier des langages multiparadigmes, qui laissent au développeur le choix d'utiliser ou non certains concepts selon ses besoins, mais sans avoir à changer de langage de programmation (voir : [[mémoire de L3#Paradigmes pour la résolution de problèmes#avantages des langages multi-paradigme]]).
On peut par ailleurs voir les paradigmes comme résultant de la nécessité de résoudre certaines classes de problèmes. Un paradigme serait alors à créer pour chaque nouveau type de problème (voir : [[mémoire de L3#Paradigmes pour la résolution de problèmes#créer un paradigme pour chaque type de problème]]).
Finalement, on peut comprendre le rôle général des paradigmes dans la résolution de problèmes : permettre la traduction des spécifications et enjeux d'un problème en un modèle conceptuel, en une idée de solution qui est entendable par le développeur (voir : [[mémoire de L3#Paradigmes pour la résolution de problèmes#Les paradigmes comme outil pour la pensée]] ).
Toutes ces raisons justifient l'existence des nombreux paradigmes de programmation, et encouragent même à en créer de nouveaux.
# Annexes
## contre la distinction entre les paradigmes
La distinction entre les différents paradigmes n'est pas toujours claire : beaucoup de langages sont [[mémoire de L3#les langages multi-paradigmes|multi-paradigmes]], et certains paradigmes peuvent être utilisés dans presque tous les langages (par exemple, la programmation structurée *ref*)
Certains auteurs considèrent que les paradigmes ne sont pas fondamentalement différents (voir : [[mémoire de L3#Au sens formel|puissance d'expression > 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 [^36].
Greg Michaelson critique la distinction des paradigmes, en expliquant que, lorsqu'on les analyse profondément, les paradigmes sont en fait proches entre eux [^37].
# footnotes
[^1]: "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." [@abelsonStructureInterpretationComputer1996, p.28]
[^2]: par exemple, Fellesein dans cette expression : "(let x be v in e) is expressible as (apply (procedure x e) v)" [@felleisenExpressivePowerProgramming1990, p.135]
[^3]: "A programming paradigm is an approach to programming a computer based on a mathematical theory or a coherent set of principles." [@royProgrammingParadigmsDummies]
[^4]: "It says a lot about what functional programming is _not_ [...] but not much about what it is." [@hughesWhyFunctionalProgramming1989, p.1]
[^5]: "It is a logical impossibility to make a language more powerful by ommitting features, no matter how bad they may be" [@hughesWhyFunctionalProgramming1989, p.1]
[^6]: 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. [@royProgrammingParadigmsDummies, p.24]
[^7]: "From an implementation viewpoint, a closure combines a procedure with its external references (the references it uses at its definition)." [@royProgrammingParadigmsDummies, p.24]
[^8]: "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." [@FermetureInformatique2024]
[^9]: "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." [@FermetureInformatique2024]
[^10]: "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." [@toalProgrammingParadigms]
[^11]: "Control flow in declarative programming is implicit: the programmer states only what the result should look like, not how to obtain it." [@toalProgrammingParadigms]
[^12]: "In functional programming, control flow is expressed by combining function calls, rather than by assigning values to variables" [@toalProgrammingParadigms]
[^13]: "Functional programming is so called because a program consists entirely of functions. The main program itself is written as a function which recieves the program's input as its argument and delivers the program's output as its result. Typically the main function is defined in terms of other functions, which in turn are defined in terms of still more functions, until at the bottom level the functions are language primitives. These functions are much like ordinary mathematical functions, and in this paper will be defined by ordinary equations." [@hughesWhyFunctionalProgramming1989, p.1]
[^14]: "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." [@FonctionOrdreSuperieur2023]
[^15]: La logique combinatoire est un système de calcul dans lequel toutes les fonctions sont pures (il n'y a que des fonctions d'ordre supérieur dans ce système) [@LogiqueCombinatoire2023]
[^16]: "Structured programming is a programming paradigm aimed at improving the clarity, quality, and development time of a computer program by making extensive use of the structured control flow constructs of selection (if/then/else) and repetition (while and for), block structures, and subroutines." [@StructuredProgrammingWikipedia]
[^17]: "'Selection'; one or a number of statements is executed depending on the state of the program. This is usually expressed with keywords such as if..then..else..endif. The conditional statement should have at least one true condition and each condition should have one exit point at max." [@StructuredProgrammingWikipedia]
[^18]: "'Iteration'; a statement or block is executed until the program reaches a certain state, or operations have been applied to every element of a collection. This is usually expressed with keywords such as while, repeat, for or do..until. Often it is recommended that each loop should only have one entry point (and in the original structural programming, also only one exit point, and a few languages enforce this)." [@StructuredProgrammingWikipedia]
[^19]: "The most important difference between structured and unstructured programs is that the former are designed in a modular way. Modular design brings great productivity improvements. First of all, small modules can be coded quickly and easily. Secondly, general purpose modules can be reused, leading to faster development of subsequent programs. Thirdly, the modules of a program can be tested independently, helping to reduce the time spent debugging." [@hughesWhyFunctionalProgramming1989, p.2]
[^20]: "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." [@royProgrammingParadigmsDummies, p.18]
[^21]: "Solving libraries (e.g., Gecode): The first paradigm is a solver library based on advanced search algorithms, such as Gecode. The second paradigm is added by the host language, e.g., C++ and Java support object-oriented programming." [@royProgrammingParadigmsDummies, p.18]
[^22]: "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." [@ExpressivePowerComputer2023]
[^23]: "The more expressive a language is, the greater the variety and quantity of ideas it can be used to represent" [@ExpressivePowerComputer2023]
[^24]: "The term expressive power may be used with a range of meaning. It may mean a measure of the ideas expressible in that language: regardless of ease (theoretical expressivity); concisely and readily (practical expressivity)" [@ExpressivePowerComputer2023]
[^25]: "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" [@ExpressivePowerComputer2023]
[^26]: "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)." [@ExpressivePowerComputer2023]
[^27]: "G-code (also RS-274) is the most widely used computer numerical control (CNC) and 3D printing programming language. It is used mainly in computer-aided manufacturing to control automated machine tools, as well as for 3D-printer slicer applications. The G stands for geometry. G-code has many variants." [@Gcode2023]
[^28]: "G-code began as a limited language that lacked constructs such as loops, conditional operators, and programmer-declared variables with natural-word-including names (or the expressions in which to use them). It was unable to encode logic but was just a way to "connect the dots" where the programmer figured out many of the dots' locations longhand." [@Gcode2023]
[^29]: "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." [@ExpressivePowerComputer2023]
[^30]: "We conclude that observable nondeterminism should be supported only if its expressive power is needed." [@royProgrammingParadigmsDummies, p.14]
[^31]: "[...] les langages algébriques, appelés aussi langages hors contexte, langages acontextuels, ou langages non contextuels. Ils sont reconnus par un automate à pile." [@HierarchieChomsky2023]
[^32]: "Les 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." [@HierarchieChomsky2023]
[^33]: "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." [@HierarchieChomsky2023]
[^34]: "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)." [@AutomatePile2021]
[^35]: "Le problème de l'appartenance d'un mot à un langage de cette classe [la classe des langages récursivement énumérables] est indécidable." [@HierarchieChomsky2023]
[^36]: "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." [@floydParadigmsProgramming1979a, p.2]
[^37]: "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." [@michaelsonProgrammingParadigmsTuring2020, p.41]
[^38]: "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" [@royProgrammingParadigmsDummies, p.14]
[^39]: "But paradigms that have the power to express observable nondeterminism can be used to model real-world situations and to program independent activities." [@royProgrammingParadigmsDummies, p.14]
[^40]: "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." [@royProgrammingParadigmsDummies, p.10]
[^41]: "For example, consider a program that consists of instructions executing one after the other. The instructions are not independent since they are ordered in time. To implement independence we need a new programming concept called concurrency. When two parts do not interact at all, we say they are concurrent.3 (When the order of execution of two parts is given, we say they are sequential.)" [@royProgrammingParadigmsDummies, p.25]
[^42]: "Concepts are not combined arbitrarily to form paradigms. They can be organized according to the creative extension principle." [@royProgrammingParadigmsDummies, p.16]
[^43]: "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" [@royProgrammingParadigmsDummies, p.17]
[^44]: "If we need to model several independent activities, then we will have to implement several execution stacks, a scheduler, and a mechanism for preempting execution from one activity to another. All this complexity is unnecessary if we add one concept to the language: concurrency." [@royProgrammingParadigmsDummies, p.17]
[^45]: "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." [@royProgrammingParadigmsDummies, p.17]
[^46]: "After solving a challenging problem, ! solve it again from scratch, retracing only the insight of the earlier solution. I repeat this until the solution is as clear and direct as I can hope for. Then I look for a general rule for attacking similar problems, that would have led me to approach the given problem in the most efficient way the first time. Often, such a rule is of permanent value." [@floydParadigmsProgramming1979a, p.3]
[^47]: "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é. 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." [@ParadigmeProgrammation2023]
[^49]: "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" [@EffetBordInformatique2023]
[^50]: "A programming language is low level when its programs require attention to the irrelevant." [@perlisSpecialFeatureEpigrams1982]
[^a]: " - 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." (Minsky, 1970, p.5)
[^b]: "To the teacher of programming, even more, I say: identify the paradigms you use, as fully as you can, then teach them explicitly. They will serve your students when Fortran has replaced Latin and Sanskrit as the archetypal dead language." (Floyd, 1979, p.9)
[^c]: "Experts build up a mental library of patterns" (Brown, 2023, p.81)
[^d]: "If the advancement of the general art of programming requires the continuing invention and elaboration of paradigms, advancement of the art of the individual programmer requires that he expand his repertory of paradigms." (Floyd, 1979, p.3)
[^e]: "seeing a variety of programming paradigms will help further." (Brown, 2023, p.81)
[^f]: "reading and working with more code, and more types of code, will increase proficiency at programming." (Brown, 2023, p.81)
[^g]: "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." (Brown, 2023, p.81)
[^h]: "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" (Brown, 2023, p.84)
Chaque paradigme permet d'avoir une vision différente d'un problème, si un problème nous parait trop complexe à résoudre avec un paradigme, un autre permettra certainement de résoudre plus simplement ce problème. Le fait de connaître une variété de paradigmes de programmation pourra aider[^e] le développeur, en lui permettant de choisir le plus approprié face aux nouveaux problèmes auquel il devra faire face.
D'où l'utilité de voir plusieurs paradigmes de programmation ceux-ci nous permettent d'aborder un problème sous différents angles de vue afin de choisir le plus adapté à nos besoins.
De plus si l'évolution générale de l'art de la programmation exige la continuation de l'invention et l'élaboration de nouveau paradigmes, les développeurs devront étendre leur répertoire de paradigmes[^d].

43
notes mémoire de L3.md Normal file
View File

@ -0,0 +1,43 @@
---
difficulty: 8
due: 2024-03-05
---
up::[[devoirs]]
title::
#devoir #fac #informatique
> [!smallquery]+ Sous-notes de `$= dv.el("span", "[[" + dv.current().file.name + "]]")`
> ```breadcrumbs
> title: false
> type: tree
> dir: down
> ```
# Sujet
- il existe de nombreux paradigmes de programmation
- sachant que 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 allons étudier :
- une définition de ce qu'est un paradigme de programmation
- une présentation de plusieurs paradigmes
- en quoi certains paradigmes sont plus adaptés
- pour l'apprentissage
- pour la résolution de problèmes particuliers
- 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
# Réglages
A rendre pour le
```meta-bind
INPUT[date:due]
```
Difficulté :
```meta-bind
INPUT[slider(minValue(0), maxValue(10)):difficulty]
```

2
notes stage de L3.md
View File

@ -27,5 +27,5 @@ up:: [[stage de L3]]
- implémentation de la loss modale
- la loss est 1 si l'ordre est égal à l'hypothèse, et 0 sinon
- on calcule la loss moyenne ainsi que la loss
- début de rédaction

1
obsidian plugin hypothesis.md
View File

@ -6,6 +6,7 @@ Plugin pour importer les annotations de [[hypothes.is]] dans obsidian
# Importation des annotations
L'importation des annotations
## Template
```
{% if is_new_article %}{% if author %}author:: [[{{author}}]]

8
payer les enseignants en fonction du nombre d'étudiants.md
View File

@ -1,3 +1,4 @@
up:: [[éducation nationale]]
#science/économie #apprendre
@ -5,6 +6,7 @@
> Par exemple :
> - $\text{salaire} = \text{taux horaire} \times \text{nombre d'étudiants}$
> [!check] Avantages
> - permet un prix par élève constant quelle que soit la taille de la classe
> - encourage moins l'[[éducation nationale]] à faire des calsses plus grandes
@ -14,5 +16,11 @@
> [!fail] Inconvénients
> - [[salaire attaché au poste|salaire au poste]] et pas [[salaire attaché à la qualification|salaire à la qualification]] ou [[salaire à la personne|à la personne]]
> - encourage les enseignants à avoir des classes plus grandes
> - encourage une pratique mauvaise
> - pour la pédagogie
> - pour les enseignants
> - pour les étudiants
> - équilibre naturel possible ? (rétribution $\leftrightarrow$ difficulté)
> - évitable avec une formule graduelle ?

19
phil chetwynd sur la scandalisation du contexte.md Normal file
View File

@ -0,0 +1,19 @@
---
aliases:
- scandalisation du contexte du conflit Israel Palestine depuis le 7 octobre
---
author:: [[Phil Chetwynd]]
source:: Le 1 hebdo n°471
link::
date-seen::2024-05-20
#citation
> [!cite] `$= dv.current().author + (" - " + dv.current().source).repeat(!!dv.current().source)`
> Dans un épisode récent du podcast *The Ezra Klein Show* , ce journaliste américain, évoquant les attentats du 11 septembre 2001, parle de "*scandalization of context*" : tenter de contextualiser un tel drame, explique-t-il, était devenu un scandale. Depuis le 7 octobre, nous faisons face aux mêmes difficultés. Informer, contextualiser devient, dans notre société de plus en plus polarisée, une gageure. L'explication n'a plus de place, seule la prise de position compte. C'est une crise pour la presse, mais aussi pour la démocratie.
^cite
## Interprétation
- à propos du [[conflit israélo-palestinien]], et des [[attaques du 7 octobre 2024]]
- difficulté à informer à cause de la [[polarisation du débat]]
- "interdiction" de contextualiser
-

3
phrases.md
View File

@ -27,6 +27,7 @@
# Autres
- M. Labroche
- "Si vous voulez parler en cours, c'est simple : Master, Doctorat, Concours de prof, et vous avez le droit de parler en cours !"
- Il ne veut pas lâcher le bord de la piscine, sauf que là c'est pas une piscine, c'est un pédiluve
- Evelyne Moreau
- "Ca converge vers $+\infty$"
- "le voisinage de $+\infty$, on y va pas souvent"
@ -49,4 +50,6 @@
- Je veux conduire, mais je louche
- Claudette Louchart
- "Je vais dire un truc, je sait que ça sert à rien, mais je vais le dire quand même"
- E. Escriva et J. Aligon
- Un "sex" de 0.051 ne signifie rien, un IMC de -0.03 n'a aucun sens médical

2
plan du mémoire de L3.md
View File

@ -1,4 +1,4 @@
up:: [[mémoire de L3]]
up:: [[notes mémoire de L3]]
#fac #informatique
Problématique : pourquoi existe-t-il de nombreux paradigmes de programmation.

4
polarisation du débat.md Normal file
View File

@ -0,0 +1,4 @@
---
aliases:
- polarisation
---

7
réaction chimique oscillante.md Normal file
View File

@ -0,0 +1,7 @@
up:: [[réaction chimique]]
#science/chimie
> [!zotero]+ <span style="color: #2ea8e5; --link-external-color: #2ea8e5;">[Réaction oscillante](zotero://select/library/items/ANM9A8QA) - [Page ](zotero://open-pdf/library/items/PC6HDH4T?annotation=XIX5I5RM)</span>
> Une réaction oscillante est un mélange complexe de composés chimiques dont la concentration d'un ou plusieurs composants présente des changements périodiques, jusqu'à épuisement de sa source d'énergie (généralement, un des réactifs).
> ^XIX5I5RMaPC6HDH4T

9
réaction chimique.md Normal file
View File

@ -0,0 +1,9 @@
up:: [[chimie]]
#science/chimie
> [!smallquery]+ Sous-notes de `$= dv.el("span", "[[" + dv.current().file.name + "]]")`
> ```breadcrumbs
> title: false
> type: tree
> dir: down
> ```

13
scandalisation du contexte.md Normal file
View File

@ -0,0 +1,13 @@
---
aliases:
- scandalisation of context
- rendre la contextualisation scandaleuse
---
up:: [[débat public]], [[information]], [[presse]]
#politique
> [!definition] scandalisation du contexte
> Lorsque le fait de *contextualiser* un événement grave (attentat, attaque terroriste...), devient scandaleux, notamment à cause de la [[polarisation du débat]].
^definition
source:: [[phil chetwynd sur la scandalisation du contexte]]

2
science.md
View File

@ -10,6 +10,8 @@
> ```
# Notes de #science
```dataview
LIST title FROM #science
```

BIN
sources/.DS_Store vendored
View File

Binary file not shown.

54
sources/hypothesis/0SK42 - challenges docstring - 13 août 2023.md
View File

@ -1,54 +0,0 @@
---
doc_type: hypothesis-highlights
url: >-
https://osk42.quarto.pub/posts/informatique/docstring%20challenges/docstring%20challenges%20-%2013%20ao%C3%BBt%202023.html
---
author:: [[osk42.quarto.pub]]
url:: [osk42.quarto.pub](https://osk42.quarto.pub/posts/informatique/docstring%20challenges/docstring%20challenges%20-%2013%20ao%C3%BBt%202023.html)
## Annotations
> [!zotero] [2023-08-25 13:30:24](https://hyp.is/yIwatEM6Ee6p5MsYO_LDzw/osk42.quarto.pub/posts/informatique/docstring%20challenges/docstring%20challenges%20-%2013%20ao%C3%BBt%202023.html)
> in"aeiou"for
> > [!note] Annotations
> > Tous les espaces inutiles ont été returés. En général, on sait que l'on a pas besoin de mettre d'espaces autour des opérateur, des `"` et des parenthèses.
> [!zotero] [2023-08-25 13:37:19](https://hyp.is/v77OikM7Ee610a_gupolHw/osk42.quarto.pub/posts/informatique/docstring%20challenges/docstring%20challenges%20-%2013%20ao%C3%BBt%202023.html)
> sum(l in"aeiou"for l in p)
> > [!note] Annotations
> > Il n'est pas nécessaire de mettre des crochets autour de la boucle :
> >
> > ```python
> > sum([l in"aeiou"for l in p])
> > ```
> >
> > Lorsque l'on ne met pas de crochets, mais des parenthèses, la boucle ne va pas créer une liste, mais un [générateur](https://python.doctor/page-iterateurs-iterator-generateur-generator-python).
> >
> > Cela ne change pas le résultat, mais peut éventuellement donner des performances différentes sur un grand nombre de valeurs.
> >
> [!zotero] [2023-08-25 13:37:58](https://hyp.is/1tSwikM7Ee693IMmcZxmpA/osk42.quarto.pub/posts/informatique/docstring%20challenges/docstring%20challenges%20-%2013%20ao%C3%BBt%202023.html)
> certains principes
> > [!note] Annotations
> > Notamment, ici, l'héritage et les objets aggrégateurs.
> [!zotero] [2023-08-25 13:39:16](https://hyp.is/BYq5fkM8Ee6pquMffDjeQQ/osk42.quarto.pub/posts/informatique/docstring%20challenges/docstring%20challenges%20-%2013%20ao%C3%BBt%202023.html)
> Cet objet est un Callable
> > [!note] Annotations
> > On définit un `Callable` en surchargeant la méthode `__call__` dans un objet. Cette méthode a les mêmes arguments que ceux de l'objet créé, et va retourner la valeur que l'objet doit retourner.
> [!zotero] [2023-08-25 13:43:43](https://hyp.is/pKLaCkM8Ee6pq_uURmbtdQ/osk42.quarto.pub/posts/informatique/docstring%20challenges/docstring%20challenges%20-%2013%20ao%C3%BBt%202023.html)
> y n’est pas pris en compte
> > [!note] Annotations
> > En anglais, y n'est pas toujours une voyelle. Voici un article qui détaille la question :
> >
> > [The truth about 'Y' : It's mostly a vowel](https://www.merriam-webster.com/grammar/why-y-is-sometimes-a-vowel-usage)
> >
> > On peut également imaginer que cela est un piège posé par le créateur de la question pour détecter ceux qui lisent les consignes trop vite.
## Notes de pages

273
sources/zotero/antoninPOURDESIGNMINIMAL.md Normal file
View File

@ -0,0 +1,273 @@
---
zotero-key: 785JFFET
zt-attachments:
- "309"
citekey: antoninPOURDESIGNMINIMAL
---
up:: [[zotero literature notes]]
link:: [Zotero](zotero://select/library/items/785JFFET) [attachment](<file:///Users/oscarplaisant/Zotero/storage/SRGAVEY9/Antonin%20-%20POUR%20UN%20DESIGN%20MINIMAL.pdf>)
#pkm #zotero
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 12](zotero://open-pdf/library/items/SRGAVEY9?page=12&annotation=QUKCR9MS)</span>
> Sauf dans de rares cas, tout est en interaction, mélangé, différent à toutes les échelles…
>
> > [!note] Notes
> > Ces rares cas sont des substances (ce dont le concept peut être formé sans avoir besoin d'autre chose).
> > Spinoza :
> >
> > - Une substance est une chose qui existe par elle-même et pour elle-même.
> > - Dieu (c'est-à-dire la Nature) est la seule substance (qui est infinie et éternelle)
> ^QUKCR9MSaSRGAVEY9p12
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 12](zotero://open-pdf/library/items/SRGAVEY9?page=12&annotation=6NRFY88T)</span>
> un objet qui remplit exactement sa fonction, ni plus ni moins
>
> > [!note] Notes
> > Cela suppose que la fonction est entièrement contenue dans l'objet.
> > Il est pourtant possible d'étendre la fonction d'un objet sans changer l'objet lui-même.
> > Par exemple, un marteau peut aujouter des fonction à un clou, sans que le clou en tant qu'objet soit changé (sans marteau, un clou ne peut pas clouer).
> > Même sans ajout d'un autre objet, beaucoup d'objets, aussi simples qu'ils soient, peuvent être détournés de leur fonction. Un bon exemple est l'expression "every tool is a hammer" (tous les outils sont des marteaux), qui suggère que tout objet lourd peut être utilisé comme un marteau.
> > Pour qu'un objet remplisse exactement sa fonction, il faudrait qu'il soit impossible de le détourner, par la nature même de cet objet.
> > Je ne trouve pas d'exemple d'objet qui ne puisse pas être détourné.
> >
> > Il y à une différence entre :
> >  - "un objet qu'on ne peut ni simplifier ni réduire sans empêcher la fonction X" 
> >  - "un objet qui remplit exactement la fonction X, ni plus ni moins"
> ^6NRFY88TaSRGAVEY9p12
> [!zotero]+ <span style="color: #ff6666; --link-external-color: #ff6666;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 12](zotero://open-pdf/library/items/SRGAVEY9?page=12&annotation=N2FHNHU2)</span>
> C’est cette obsession de la simplicité qui a fait la réussite d’Apple.
>
> > [!note] Notes
> > ref nécessaire
> >
> > cela reste à prouver.
> > Est-ce que ça n'est pas plutôt le *marketting sur le minimalisme* qui a fait sa réussite, plutôt que le minimalisme lui-même ?
> ^N2FHNHU2aSRGAVEY9p12
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 14](zotero://open-pdf/library/items/SRGAVEY9?page=14&annotation=BE9TVEK8)</span>
> La plupart des gens ont déjà allumé un interrupteur avec le dos de la main, un coude, voire même un genou
> ^BE9TVEK8aSRGAVEY9p14
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 14](zotero://open-pdf/library/items/SRGAVEY9?page=14&annotation=U7D6SNE6)</span>
> Un design qui fonctionne dans votre tête n’est probablement pas adapté aux contraintes des utilisateurs.
>
> > [!note] Notes
> > Erreur d'ergonomie : solution n'est pas adaptée aux **besoins fonctionnels**.
> ^U7D6SNE6aSRGAVEY9p14
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 14](zotero://open-pdf/library/items/SRGAVEY9?page=14&annotation=HMVQYXQQ)</span>
> Si tous les boutons sont au même endroit, on mélange toutes les routines, et c’est l’erreur assurée !
>
> > [!note] Notes
> > Erreur d'ergonomie : problème de robustesse.
> ^HMVQYXQQaSRGAVEY9p14
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 14](zotero://open-pdf/library/items/SRGAVEY9?page=14&annotation=WQZDXNLS)</span>
> Mais retenir la signification de 6 items identiques seulement à partir de leur position, c’est long. Voir impossible.
>
> > [!note] Notes
> > Erreur d'ergonomie : problème d'apprenabilité.
> ^WQZDXNLSaSRGAVEY9p14
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 15](zotero://open-pdf/library/items/SRGAVEY9?page=15&annotation=Q3Z3DEM4)</span>
> une partie de moi a envie que l’idéal du minimalisme triomphe.
>
> > [!note] Notes
> > Reformulation que je trouve plus jolie :
> > "[...] une partie de moi a [désire|souhaite] le triomphe de l'idéal minimaliste."
> ^Q3Z3DEM4aSRGAVEY9p15
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 16](zotero://open-pdf/library/items/SRGAVEY9?page=16&annotation=MBC797NJ)</span>
> vouloir simplifier, c’est se battre contre un standard.
>
> > [!note] Notes
> > Concept de dette technique.
> ^MBC797NJaSRGAVEY9p16
> [!zotero]+ <span style="color: #2ea8e5; --link-external-color: #2ea8e5;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 17](zotero://open-pdf/library/items/SRGAVEY9?page=17&annotation=7N28TI33)</span>
> Quelque chose de compliqué, c’est quelque chose qui n’est pas simple, car constitué de beaucoup d’entités ou de règles.
>
> > [!note] Notes
> > compliqué := grand nombre de parties
> ^7N28TI33aSRGAVEY9p17
> [!zotero]+ <span style="color: #2ea8e5; --link-external-color: #2ea8e5;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 17](zotero://open-pdf/library/items/SRGAVEY9?page=17&annotation=XB99K2XX)</span>
> quelque chose de complexe, c’est quelque chose qui n’est pas simple car composé de parties qui interagissent de manière imprévisible.
>
> > [!note] Notes
> > complexe := richesse des relations/interactions entre les parties
> ^XB99K2XXaSRGAVEY9p17
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 17](zotero://open-pdf/library/items/SRGAVEY9?page=17&annotation=UN4VX4Z4)</span>
> Typiquement, une pièce de puzzle est simple, un puzzle est compliqué, et le cerveau de celui qui le résout est complexe.
>
> > [!note] Notes
> > Je n'ai pas compris l'exemple tout de suite à cause du fait que le cerveau est à la fois compliqué et complexe.
> ^UN4VX4Z4aSRGAVEY9p17
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 18](zotero://open-pdf/library/items/SRGAVEY9?page=18&annotation=NFHZIPLI)</span>
> Une approche pour résoudre ce problème est de cacher les fonctionnalités non essentielles.
>
> > [!note] Notes
> > Cela a un nom en ergonomie (il faudrait que je cherche dans mon cours).
> ^NFHZIPLIaSRGAVEY9p18
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 18](zotero://open-pdf/library/items/SRGAVEY9?page=18&annotation=JQ2LD2DD)</span>
> l’apprentissage du logiciel n’est pas intuitif.
>
> > [!note] Notes
> > Erreur d'ergonomie : mauvaise apprenabilité.
> ^JQ2LD2DDaSRGAVEY9p18
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 18](zotero://open-pdf/library/items/SRGAVEY9?page=18&annotation=JX34ZBD2)</span>
> on assiste à des comportements inattendus, et on ne comprend pas ce qui se passe
>
> > [!note] Notes
> > Erreurs d'ergonomie : problèmes de guidage, de causalité, de cohérence interne ou externe.
> ^JX34ZBD2aSRGAVEY9p18
> [!zotero]+ <span style="color: #ff6666; --link-external-color: #ff6666;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 19](zotero://open-pdf/library/items/SRGAVEY9?page=19&annotation=AUAS6ZMA)</span>
> Atteindre ce niveau de maîtrise nécessite de comprendre l’objet dans ses moindres détails.
>
> > [!note] Notes
> > La plupart des sportifs ne comprennent pas les lois de l'aérodynamique, le fonctionnement physique précis de leur outil.
> > Ils ont plutôt une compréhension des conséquences.
> ^AUAS6ZMAaSRGAVEY9p19
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 19](zotero://open-pdf/library/items/SRGAVEY9?page=19&annotation=R9B66PQZ)</span>
> Dans le domaine de l’art, maîtriser l’outil prend quelques heures, et devenir doué prend des années.
>
> > [!note] Notes
> > Je ferais ici une nuance entre "maîtriser l'outil" et "comprendre le fonctionnement de l'outil".
> > Pour moi, maîtriser l'outil demande parfois un long travail.
> > Typiquement, un pinceau est simple à *comprendre*, mais très complexe à *maîtriser*.
> ^R9B66PQZaSRGAVEY9p19
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 19](zotero://open-pdf/library/items/SRGAVEY9?page=19&annotation=PU8SCM43)</span>
> Je pense également au tricot : Avec seulement un fil et deux aiguilles, on peut créer un nombre de motifs incroyable.
>
> > [!note] Notes
> > Pour moi, tu parles ici d'émergence : un système simple qui permet une grande diversité de comportements / résultats.
> ^PU8SCM43aSRGAVEY9p19
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 19](zotero://open-pdf/library/items/SRGAVEY9?page=19&annotation=IG65VNHW)</span>
> Celui ci permet de rester plus concentré, d’être focalisé entièrement sur la tâche.
>
> > [!note] Notes
> > ref nécessaire.
> >
> > Je vois des contre-exemples :
> >  - un ordinateur est meilleur qu'une machine à écrire pour produire des documents propres, parce qu'on peut corriger a-posteriori, on ne gache pas sa concentration sur les éventuelles typos
> >  -
> ^IG65VNHWaSRGAVEY9p19
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 20](zotero://open-pdf/library/items/SRGAVEY9?page=20&annotation=HCKRJASJ)</span>
> Il faut associer minimalisme et compréhension de l’humain.
>
> > [!note] Notes
> > Le minimalisme est il conséquence de la compréhension de l'humain ?
> > Ou bien est-il indépendant ?
> >
> >
> > Si il est indépendant, alors c'est simplement une mouvance artistique.
> > Si il est conséquence, alors il n'est pas à *associer*, puisqu'il est déjà inclus dans la compréhension de l'humain.
> ^HCKRJASJaSRGAVEY9p20
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 21](zotero://open-pdf/library/items/SRGAVEY9?page=21&annotation=TZAEFRSF)</span>
> Je pourrais dédier un livre entier au papier et au crayon, vu à quel point cet outil est formidablement puissant.
>
> > [!note] Notes
> > "Je pourrais dédier un livre entier à montrer la puissance formidable de cet outil".
> ^TZAEFRSFaSRGAVEY9p21
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 21](zotero://open-pdf/library/items/SRGAVEY9?page=21&annotation=96TNYM56)</span>
> Ce ne sont pas que les fonctionnalités qui importent, mais le fait que l’objet permette la concentration et la créativité.
>
> > [!note] Notes
> > - Permettre concentration et créativité, c'est une fonctionnalité (au sens large). C'est un besoin non-fonctionnel.
> > - sans fonctionnalité, il n'est pas de tâche sur laquelle se concentrer, ni de création possible
> >
> > - certaines fonctionnalités libèrent des contraintes précédentes, et permettent donc d'améliorer concentration et créativité
> >   - ex : invention du piano par rapport au clavecin
> ^96TNYM56aSRGAVEY9p21
> [!zotero]+ <span style="color: #ff6666; --link-external-color: #ff6666;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 21](zotero://open-pdf/library/items/SRGAVEY9?page=21&annotation=4NSLQUSQ)</span>
> Pour le bien de l’utilisateur, il faut donc éliminer le compliqué. Mais très vite, cela nécessite de supprimer des fonctionnalités.
>
> > [!note] Notes
> > En quoi l'élimination du compliqué supprime-t-il des fonctionnalités ?
> > On peut simplifier en gardant les mêmes fonctionnalités !
> ^4NSLQUSQaSRGAVEY9p21
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 22](zotero://open-pdf/library/items/SRGAVEY9?page=22&annotation=LTRTMKUK)</span>
> Quand tout notre système économique encourage un marketing intensif et l’obsolescence programmée, il est nécessaire de se demander : Est‑ce que ces nouveaux produits toujours plus sophistiqués reflètent vraiment un besoin de l’utilisateur ?
>
> > [!note] Notes
> > Le marketing semble effectivement être le problème.
> ^LTRTMKUKaSRGAVEY9p22
> [!zotero]+ <span style="color: #ff6666; --link-external-color: #ff6666;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 24](zotero://open-pdf/library/items/SRGAVEY9?page=24&annotation=C35IRUWE)</span>
> C’est une valeur que je suis près à défendre, car je pense qu’elle rend les gens plus heureux sur le long terme.
>
> > [!note] Notes
> > Pourquoi le minimalisme rendrait-t-il plus heureux ?
> ^C35IRUWEaSRGAVEY9p24
> [!zotero]+ <span style="color: #ff6666; --link-external-color: #ff6666;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 25](zotero://open-pdf/library/items/SRGAVEY9?page=25&annotation=84666T2Z)</span>
> Que l’on le veuille ou non, une forme de marketing reste nécessaire.
>
> > [!note] Notes
> > L'idée sous-tendue est qu'il faut nécessairement vendre.
> > Cela est vrai *dans notre société actuelle*, mais n'est pas universel.
> ^84666T2ZaSRGAVEY9p25
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 25](zotero://open-pdf/library/items/SRGAVEY9?page=25&annotation=R6WT49T2)</span>
> Cet objet ne sera jamais vendu et l’entreprise fera faillite.
>
> > [!note] Notes
> > On voit dans cette étape de raisonnement que l'entreprise et le marché sont sous-tendu à cette réflexion.
> > Qu'en serait-il pour une société sans marchés ?
> ^R6WT49T2aSRGAVEY9p25
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 26](zotero://open-pdf/library/items/SRGAVEY9?page=26&annotation=F5L5E43E)</span>
> Même si les gens qui achètent un tel produit constituent une niche, cette entreprise est prospère. La valeur marketing du minimalisme fonctionne très bien.
>
> > [!note] Notes
> > Il faudrait étudier la sociologie de ce genre de produits.
> > En effet, il est très possible que ce marketting fonctionne plus à cause de l'envie de distinction (le minimalisme étant un moyen de se distinguer), que par le minimalisme lui-même.
> ^F5L5E43EaSRGAVEY9p26
> [!zotero]+ <span style="color: #ff6666; --link-external-color: #ff6666;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 26](zotero://open-pdf/library/items/SRGAVEY9?page=26&annotation=FNLWEBMB)</span>
> Et l’entreprise peut diriger plus de ressources vers l’aide au client. Que ce soit des guides d’achat pour savoir quelle chaussure convient mieux à notre pied ou un service après vente de qualité, tout est centré sur le client.
>
> > [!note] Notes
> > Les entreprises ne sont pas tournées vers le client parce qu'elles ont la *valeur minimalisme*, ou bien que l'humain est important pour elles.
> >
> > Elles agissent par intérêt économique, dans un marché qui les pousse / oblige à faire ainsi.
> ^FNLWEBMBaSRGAVEY9p26
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 26](zotero://open-pdf/library/items/SRGAVEY9?page=26&annotation=JT6946LQ)</span>
> Ces particularités créent un climat de confiance entre le client et l’entreprise. C’est peut être une erreur, mais Freet est l’entreprise envers lequel j’ai le plus confiance. Je me sens respecté en tant que client, et je sais que je ne serais pas obligé d’acheter des fonctionnalités dont je n’ai pas réellement besoin.
>
> > [!note] Notes
> > Cela semble faire partie du marketting.
> > Encore une fois, les entreprises ne peuvent faire autrement que d'agir par intérêt, à cause de la pression des marchés.
> ^JT6946LQaSRGAVEY9p26
> [!zotero]+ <span style="color: #ff6666; --link-external-color: #ff6666;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 28](zotero://open-pdf/library/items/SRGAVEY9?page=28&annotation=XY85J99W)</span>
> Quand les gens comprendront à quel point notre société est aveuglée par l’innovation et le matérialisme et verrons leurs dangers, une création différente sera possible.
>
> > [!note] Notes
> > Cela fait porter sur les individus la responsabilité du changement.
> > Les problèmes soulevés s'inscrivent dans des systèmes à beaucoup plus haute échelle. Pour les résoudre, il faut jouer sur les marchés, la finance, la macroéconomie...
> ^XY85J99WaSRGAVEY9p28
> [!zotero]+ <span style="color: #5fb236; --link-external-color: #5fb236;">[POUR UN DESIGN MINIMAL](zotero://select/library/items/785JFFET) - [Page 31](zotero://open-pdf/library/items/SRGAVEY9?page=31&annotation=WNS2KCA4)</span>
> Remettre en cause le capitalisme.
>
> > [!note] Notes
> > Le terme à été posé.
> > Peut-être est-t-il dommage que cet angle d'approche n'aie pas été pris dans la réflexion.
> ^WNS2KCA4aSRGAVEY9p31

40
sources/zotero/hughesWhyFunctionalProgramming1989.md Normal file
View File

@ -0,0 +1,40 @@
---
zotero-key: AZ2PNJYZ
zt-attachments:
- "403"
citekey: hughesWhyFunctionalProgramming1989
---
up:: [[zotero literature notes]]
link:: [Zotero](zotero://select/library/items/AZ2PNJYZ) [attachment](<file:///Users/oscarplaisant/Zotero/storage/ARFZTMBK/Hughes%20-%201989%20-%20Why%20Functional%20Programming%20Matters.pdf>)
#pkm #zotero
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[Why Functional Programming Matters](zotero://select/library/items/AZ2PNJYZ) - [Page 1](zotero://open-pdf/library/items/ARFZTMBK?page=1&annotation=M9YCV9GB)</span>
> 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.
> ^M9YCV9GBaARFZTMBKp1
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[Why Functional Programming Matters](zotero://select/library/items/AZ2PNJYZ) - [Page 1](zotero://open-pdf/library/items/ARFZTMBK?page=1&annotation=292Z4WZK)</span>
> 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.
> ^292Z4WZKaARFZTMBKp1
> [!zotero]+ <span style="color: #2ea8e5; --link-external-color: #2ea8e5;">[Why Functional Programming Matters](zotero://select/library/items/AZ2PNJYZ) - [Page 1](zotero://open-pdf/library/items/ARFZTMBK?page=1&annotation=HL9BCWP6)</span>
> ![[images/zotero/HL9BCWP6.png]]
>
> > [!note] Notes
> > programme écrit comme des fonctions qui reçoivent l'entrée en argument et renvoie le résultat.
> ^HL9BCWP6aARFZTMBKp1
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[Why Functional Programming Matters](zotero://select/library/items/AZ2PNJYZ) - [Page 1](zotero://open-pdf/library/items/ARFZTMBK?page=1&annotation=4YFZKF4B)</span>
> ![[images/zotero/4YFZKF4B.png]]
> ^4YFZKF4BaARFZTMBKp1
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[Why Functional Programming Matters](zotero://select/library/items/AZ2PNJYZ) - [Page 2](zotero://open-pdf/library/items/ARFZTMBK?page=2&annotation=VA8DPCLG)</span>
> ![[images/zotero/VA8DPCLG.png]]
> ^VA8DPCLGaARFZTMBKp2
> [!zotero]+ <span style="color: #ffd400; --link-external-color: #ffd400;">[Why Functional Programming Matters](zotero://select/library/items/AZ2PNJYZ) - [Page 2](zotero://open-pdf/library/items/ARFZTMBK?page=2&annotation=CSPRXGEB)</span>
> ![[images/zotero/CSPRXGEB.png]]
>
> > [!note] Notes
> > Pour augmenter la capacité à modulariser, il faut augmenter les types de colle disponibles.
> ^CSPRXGEBaARFZTMBKp2

2
templates/citation.md
View File

@ -4,7 +4,7 @@ link::
date-seen::{{DATE:yyyy-MM-DD}}
#citation
> [!cite] Titre
> [!cite] `$= dv.current().author + (" - " + dv.current().source).repeat(!!dv.current().source)`
> ...
^cite

34
templates/nouvelle note.md Normal file
View File

@ -0,0 +1,34 @@
---
excalidraw-plugin: parsed
tags:
- excalidraw
excalidraw-open-md: true
---
up::
![[<% tp.file.title %>]]
%%
# Excalidraw Data
## Text Elements
## Drawing
```compressed-json
N4KAkARALgngDgUwgLgAQQQDwMYEMA2AlgCYBOuA7hADTgQBuCpAzoQPYB2KqATLZMzYBXUtiRoIACyhQ4zZAHoFAc0JRJQgEYA6bGwC2CgF7N6hbEcK4OCtptbErHALRY8RMpWdx8Q1TdIEfARcZgRmBShcZQUebTieGjoghH0EDihmbgBtcDBQMEKIEm4IAGEYAHkASQRlABlqqCMAawAlAGk2AClqgAUANQBZAHEBpMLIWERSoKI5JH4izG5n
AEYADgBWbS2ATi2AZj2AFgB2Q4A2DZOeAAYNpcgYVbWTy+0Ny7O7/bu7k57Q63Ph5SAUEjqbj3Q7aNZnHg8L6bW5rX6gyZSBCEZTSaF3WHwxHIm48NFbDFFazKYLcO5PCDMKCkNgtBBlNj4NikUoAYjWCAFAomRU0uGwLWULKEHGIHK5PIkzOszDguECGRFkAAZoR8PgAMqwWkSQQeLWM5mshAAdUhkmhDKZLLZRpgJvQZpKDOluI44SyaDWDLYa
uwaheQf+DKlwjg1WIgdQ2QAugzteQ0gnuBwhPqGYRZVhSrg1hbpbL/cwkwVMdNxLwwQBfJ0IBDEbjwgk8IEPR5ghhMVicbiHM4MxgsdgcABynDEo62ZzWawph0pkEIzAAIikoO3uNqCGEGZphLKAKLBNIZJO5/MDoRwYi4fcdoPLy5I4EbQ5Ly4MkQHAtDmeb4IBbASgeaBHvgYR5C2eS1lM8ANhg+iaO2L6aLSE5DtOo6HHhU6cHOHALmg9wEls
WyXFsawbsURYrBIuB3BaW67sEb7cMyQgIAW77oEacBCDaPA2g66Z6oaxpoZI4oaIEFrOtadrEFCQZOlarpyaUXodj6wh+gGnYhmGEadtGA7Uh69IDixqDODwZxnHCPBbAykZOS5GzaJclwnHcX6eQOqlsvK3J8v8MXsae4qShWcqclFSrkBwqrqukUAWhCGkOmgQX2ZikjYriOVoFs1mYmE0GoIcwV3MGA6xk+CZJqm6aZgg2ZoPe4EDklVZ3mBp
7nsQV6pNlHVpo+z6vnV8JrF+v7nBsexooBhYgRI2TZAAqhkajBMQ2j6MQvLqFuqDXbgqDEKkbApimFpclBQmwSeA7YEITIGNur64NwyGQOdfQsnIwNgkUv0IJU9gkE4u5HnmmSHseAnQ5AYoSq1spDK+2CSGU1j0KE6NwZjkyiglePEATUBE5NN4VagfFU9TEA44l42RYq6C8tqQtajTuNJZUFmwNwlzFZzZ6kA9pAM0z17ZbxpD8U8orcorfN8k
L2oi9jOtMBL4qWWgsuYrqwQcLgaQDFuhA4Q2n0INDTbNk67gNrk1PNf7YIpgh4CzZAuBwHARoLVDRTqFNpQvqQIFLAwhAIBQABCtNJXrEiCwbwupz9pAalATSpEaLrsil/MQPygqNyKEAl2XFf6NnYu87XpTKhlapl83rfZe3ABiMluh6jKct6eQtyIbf7voVdqfajpz8PGTtyvunumhBlDwvI9L20xmSMNZkb0fW9L2b4ZS1Gsvz6Xx+pKPnBQK
P9t6t5AeQJv5cl7vwyAaQgRgGz3GLtfQBqQAAqWAoAAEEiDKC4BIYI2ocpQJfjfSuURSBINLmwCgpVcBCX6tgxeqQLyykQUQkhIQhIQHVCyKgqdmDYBZPqAAGtwd4Jx4hnD2DLCklxDirjOF8dhnDOT4AAJrQj2HcbQTVvgNV+GcWiWx+xFCMGwAwscihk18A2NY2glGxUsbFNYCFKGv30KfGUxAL4SCSs3KUJBQHgNAg+IoHjkoKkMZATOnImG8
jKHsCJETR6jwtG0OoeZ1R8gvNuFJKSYkQFsVfHBUAd5wzgFAacI1fGQDgIEMwwhmAjFIJ4sBDYKFzwzPbBA8Siw1I4MoIJGA7YuyEuzBk2B5jq01gOO2aRhkc0gMIKAQEGzsyyUUOwAArBA2BMgGjtnAIYbAHo0NwL0im8EwCIR1HqcIwNPZNiAA
```
%%