" Le principe KISS, Keep it simple, stupid (en français, mot à mot : « garde ça simple, idiot », dans le sens de « ne complique pas les choses ») "

Souvent cité pour expliquer la #philosophie_pensée #linux (Unix)
( https://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond's_17_Unix_Rules )

Fil #wiki ( articles connexes )

• https://fr.wikipedia.org/wiki/Simplexité
• https://fr.wikipedia.org/wiki/YAGNI
• https://fr.wikipedia.org/wiki/Ne_vous_répétez_pas
• https://fr.wikipedia.org/wiki/Méthode_MoSCoW

Il s'agit de rendre simple une tâche pourant complexe ( par exemple en la découpant )

Un exemple que j'ai retenu : celui des commandes apellées "pipe(lines)" dans l'univers Unix (par lesquelles l'info passe d'un traitement à l'autre) : un procédé simple car combinatoire.

cat mondocument.txt | grep "titre"

Dans cet exemple, cat ( sort/output le texte présent dans mondocument.txt ) qui est ensuite combiné à l'outil grep ( qui cherche dans le résultat de cat, les lignes contenant "titre" ).

| sur mac (et unix) je fais Ctrl+Shift+L (wiki + clavier)

Simple sans perdre la complexité

• Cette combinatoire (parmis d'autres tel >>) permet avec un ensemble de commandes.logiciels simples de faire des choses complexes en bout de chaine.
• Le principet est simple à intégrer-apprendre. Sa généralisation au sein d'un système d'outils variés ouvre à une grande créativité.

D'autres exemples de commandes "simples" profitant de cette combinatoire

• https://liens.vincent-bonnefille.fr/?g1sn6Q
• https://liens.vincent-bonnefille.fr/?2i41mQ

OK pour le dev mais pour les idées ? #méthodologie
( ma question : y aurait il du bon dans les méthodes_stratégies de dev. à appliquer.implémenter à une recherche (en thèse ou autre ) ? Quelles hybridités programatives pourraient en sortir ? Et moi, quels sont mes outils de d'auto-/feedback/ et d'orientation face à un problème (par exemple de restructuration face à une nouvelle hypothèse, un doute) ? )

Cité dans ce wiki (source) :
( explications, point de vu pratique.empirique d'un dev. )

http://people.apache.org/~fhanik/kiss.html
What does that mean?
This principle has been a key, and a huge success in my years of software engineering. A common problem among software engineers and developers today is that they tend to over complicate problems.

Typically when a developer is faced with a problem, they break it down into smaller pieces that they think they understand and then try to implement the solution in code. I would say 8 or 9 out of 10 developers make the mistake that they don't break down the problem into small enough or understandable enough pieces. This results in very complex implementations of even the most simple problems, another side effect is spagetthi code, something we tought only BASIC would do with its goto statements, but in Java this results in classes with 500-1000 lines of code, methods that each have several hundreds of lines.

How will I benefit from KISS

• You will be able to solve more problems, faster.
• You will be able to produce code to solve complex problems in fewer lines of code
• You will be able to produce higher quality code
• You will be able to build larger systems, easier to maintain
• You're code base will be more flexible, easier to extend, modify or refactor when new requirements arrive
• You will be able to achieve more than you ever imagined
• You will be able to work in large development groups and large projects since all the code is stupid simple

.... la suite de l'article donne de plutôt bons conseils pour optimiser son dev. (par exemple, réfléchir avant de coder...)

Dans "Le Trésor des paradoxes (Éditions Belin, #2007) : " #@Claude_Shannon voulut élaborer une " machine gratuite ", sans finalité : on la met en marche en appuyant, comme sur tout dispositif électromécanique, sur une touche " on " ; mais les choses prennent alors une tournure surprenante, car cette mise sous tension déclenche un mécanisme provoquant aussitôt l’arrêt du gadget en mettant l’interrupteur sur " off ! " Ce type de comportement insolite caractérise les situations ubiquitaires où la communication réside paradoxalement dans l'absence de communication, l'utilité dans l'absence d'utilité

[[ Exemples : "La mode, c'est ce qui se démode" (Jean Cocteau); "Créer cette École (L’École Freudienne) afin de la dissoudre" (Jacques Lacan); "On se rend compte que l'on dort en se réveillant" (John Lennon); "Le bon fonctionnement de tout le système de l’épargne-logement suppose, paradoxalement, que certains ayants droit (les " bons frères ") renoncent précisément à faire valoir leur droit à un prêt au terme d’une période d’épargne" (Pierre Chaillol); "L'idéal révolutionnaire n’a pu que se troubler au moment de s’accomplir : la nécessité dont il se réclamait le condamnait à se perdre pour se réaliser, trahi et déformé moins par ses ennemis que par ceux-là mêmes qui ont voulu en assurer l’application" (Jean Starobinsky); "La virginité se perd en se prouvant" (Fernand Crommelynck). Un avatar géostratégique de cet automate paradoxal de Shannon consiste dans le concept de dissuasion nucléaire: les puissances nucléaires amassent des armes atomiques dans le but... d'interdire toute velléité d'emploi de ce type d'armes, en se neutralisant mutuellement: ça sert à ne pas servir ! ]]
[...]
Son œuvre
Pendant la Seconde Guerre mondiale, Shannon travaille pour les services secrets de l'armée, en cryptographie, chargé de localiser de manière automatique dans le code ennemi les parties signifiantes cachées au milieu du brouillage. Son travail est exposé dans un rapport secret (déclassifié dans les années #1980 seulement), qui donne naissance après-guerre à un article, A Mathematical Theory of Communications ( #1948 ), qui fut repris en #1949 sous forme de livre avec un ajout de Warren Weaver, son supérieur dans les services secrets. Cet ouvrage est centré autour de la problématique de la transmission du signal.
[...]
Pour décrire la communication entre machines, l'article de #1948 et le livre de #1949 commencent tous deux par un " schéma " qui connut dès lors une postérité étonnante en Sciences de l'information et de la communication, au point que Shannon s'en étonna et s'en dissocia. Le schéma modélise la communication entre machines en 5 éléments :
[ source --> émetteur --> message --> récepteur --> destinataire, dans un contexte de bruit. ]
Ce schéma est la traduction " civile " d'un schéma préalable, utilisé dans le contexte militaire:
[ source --> encodeur --> signal --> décodeur --> destinataire, dans un contexte de brouillage. ]

by James Veitch,
852 k abonnés
320 961 vues
8 déc. 2020 - 15 K likes
S01E03

Spam the spamer