Discussion :

[zintelix3d]

Alors pour en revenir au sujet je te citerais Lao-Tseu qui disait :
- Le sage paraît lent, mais il sait former des plans habiles.

Ne serait-ce pas une apologie de l'analyse avant toute action

J'ai la même avec une tortue et un lapin , sa fait enfantin, mais c'est grâce aux choses les plus simple dans la vie qu'on acquis de la sagesse.

[_Gabriel_]

bonjour,

Quelques années aprés le message initial, je vais m'essayer au post spontané !

Récrié ou encouragé, l'expérience décrite n'en pas moins une expérience vécue. J'en fait parti mais je pense avoir trouver quelques explications.

J'ai coutume à dire que les programmes "ca me parle". Certains me voient un peu comme une bête bizarre, d'autres disent de moi que je touche ma bille dans le sujet. En toute modestie, je me contente jsute de faire ce que j'aime faire et surtout de m'attacher à ce qu'il soit bien fait.

Alors spontané ou pas ? J'ai compris qu'avant tout, c'est une histoire de capacité. Analyse, logique, projection, extrapolation et mémoire visuelle. Capacité plus ou moins développée suivant les personnes.

Ce que décrit dooloop, c'est juste qu'il a moins besoin de comprendre, de réécrire le problème, de chercher les solutions possibles, d'en envisager les tenants et les aboutissants. Il comprends plus vite car il décompose le problème en sous problème, s'attaque à chaque sous problème, visualise plusieurs solutions, est capable de d'extrapoler le résultat de chaque solution et donc de choisir la moins pire plus rapidement. En fait, il y a peu d'essais et pas beaucoup d'erreurcar ce qui est écrit fonctionera de toutes façons puisque que le résultat était déjà prévisible. En clair, quand il prends le clavier en main, c'st déjà plié. le problème en cours est résoluu et dans sa tête il est passé au suivant. En fait je parle de dooloop, mais je c'est plus à mon expérience que je pensais.

La mémoire visuelle permet de se replacer dans un contexte passé et de "revoir" l'action.

Documenter ou ne pas documenter son code ? je suis d'accord, que sans aucun papier de référence, c'est voué à la catastrophe mais trop de paier de réference nuit à l'action. Ca fait plus bureaucratie que production. comme toute chose, l'essentiel reste la bonne mesure.

Finalement, j'ai eu la chance de rencontrer quelques bonnes personnes et d'améliorer l'utilisation de ces capacités. Parce que la compréhension d'un système plus rapidement est un atout, j'en ai profité pour approfondir les différentes méthodes d'analyse de présentation d'analyse pour renforcer la compréhension du système. Ce qui me permet de me représenter dans ma tête différentes solutions et leur résultat, je l'utilise pour affiner la solution pour la rendre plus simple pour les relecteurs. Parce que peut-être je passe moin de temps à concevoir une partie, je peux me permettre de passer un peu plus de temps à faire une note pertinente. Ni trop, ni trop peu finalement.

Bref, bref, je ne me mets pas en avant, je fais juste un constat sur moi même et je tente de le faire partagé à tout le monde. Je ne dis pas que je suis un génie.

Ce qu'il décrit comme spontané , je laisse libre cours à son expression dans mes travaux personnels de recherche. ca me permet d'exxplorer différentes voies sans trop y passer de temps.

Si je peux me permettre de donner un conseil à tous les doolop :
- Ouvrer grand les yeux et les oreilles quand vous êtes face à un ancien car vous pouvez trés rapidement acquérir la connaissance qu'il souhaite partager
- Conserver toujours des gardes fous parce qu'on reste avant tout des humains faillibles et donc en ce sens, là où vous gaganez en reflexion, vous pouvez le remettre à profit dans le teste, la preuve, la documentation
- finalement, restez humble.

[younid]

+1

Entièrement d'accord avec l'explication

[Flesk]

Etant plus jeune et sur d'autres forums consacrés à divers jeux, j'ai pu voir des sujets ayant le même genre d'intitulé.

Sans agression aucune, pour moi ce genre de titre de sujet semble être une fausse question, destinée à masquer une certaine envie de paraître "exceptionnel".

Le témoignage de _Gabriel_ (qui fait montre d'une volonté d'humilité bienvenue) renforce mon opinion en ce sens, dans la mesure où dans les premières lignes de son post (et de celui du créateur même de ce sujet !) on dénote que l'individualité intervient comme part importante de l'expérience de programmation spontanée, d'autant plus que cette dernière est présentée de façon particulière ! En effet remarquons tout de même qu'il n'est pas question de "programmer", mais de "programmer spontanément".

J'ai eu la curieuse impression en lisant les premières pages de ce sujet de revenir plus d'un siècle auparavant, à une époque où un vif débat eu lieu quant à la naissance des poèmes. Ces derniers étaient censés (et sont toujours censés dans l'esprit de beaucoup aujourd'hui) sortir tout droit de l'esprit du poète, sans qu'il ai besoin d'y réfléchir outre mesure. A cela s'opposa la vision d'un poète nommé Edgar Allan Poe qui présenta son poème du "corbeau" et qui y joignit un texte expliquant comment il l'avait créé.

Où veux-je en venir ? A ceci : à l'époque, l'image du poète faisait de lui une sorte de génie qui faisait jaillir en mots de la beauté par son esprit, par la question qui fut initiée ici on en arrive à créer des "génies" qui sortent des codes sans renseigner leur manière de faire ni comment finalement, l'utiliser ou faire pareil.

Attention je le redis, ceci n'est en rien une agression, car pour être tout à fait honnête, je me suis senti concerné par nombre de passages différents, des deux bords... Il y a peu j'ai travaillé sur un petit projet qui tout de même comportait la création d'un IA reposant entièrement sur un spectre musical. Je ne vous raconte pas la prise de tête pour ne serait-ce qu'optimiser un peu la bête, les idées ne m'ont pas manqué et j'en ai appliqué plus d'une, seulement... Hé bien ce fut une horreur pour ceux qui bossèrent avec moi quand je leur donnai le fruit de mon travail : pas commenté, peu documenté ! Même si mon code était clair (du moins à mon sens ^^), il me parait normal avec du recul de faire véritablement en sorte au moment même de la création de créer pour "plus que soi".

J'ai bondi en lisant parfois "pas besoin de commentaires", s'ils sont un minimum judicieux ils permettent beaucoup ! De même que la documentation.

Il est vrai que savoir coder et lire un code sans avoir besoin de choses à côté est un don précieux, mais il ne faut pas se leurrer, avoir ce simple don ne fait de personne un véritable bon programmeur (je ne me définis pas comme tel, mes programmes sont tellement concis parfois qu'on les croirait décapité, hors sans tête, pas évident de piger le truc...).

Qui pratique la programmation spontanée ?
Tous ceux qui ont levé la main, baissez la ! Vous avez sans doute un certain talent, mais il pourra un jour vous faire défaut, et la chute se fera alors sans filet... Sachez que dans la réalisation des oeuvres de ce qu'on appelle un génie, intervient seulement environ 10% de son talent, tout le reste est du travail ! Et ce travail peut être notamment un travail de discipline et d'ouverture aux autres...

Et je voudrais ajouter aussi, ceux qui ne savent lire du code comme ça ou ont du mal, ou qui ne peuvent coder sans "à-côtés", soyez heureux parce que finalement, vous êtes des humains entrant dans la grande communauté définie comme "normale" ! (quoique l'on constate parfois dans notre société que les gens écrivant du code informatique sont dans les limites de la normale, preuve s'il en fallait que l'inconnu suscite ou la peur, ou l'admiration, dans tous les cas une certaine fascination qui pousse à poser cette question récurrente relative aux grands hommes : folie ou génie ?)

Bref, il n'y a pas à se monter la tête avec de la programmation spontanée, c'est assurément quelque chose de bien trop personnel pour être bon dans ce monde de communication ! Entre un code "parfait" par un boss et un code bien renseigné par un type lambda, je choisi le deuxième pour peu que cela fonctionne ! Et croyez moi je suis très loin d'être le seul dans ce cas.

Finalement je rejoindrais _Gabriel_ sur ce point : une facilité de codage sans avoir besoin de tonnes de notes permettra d'améliorer les autres points qui restent indispensables...

(note personnelle : pour avoir vu les ravages que font les illusions d'être un génie (ne dites jamais à des enfants qu'ils sont surdoués !), je ne parle pas de génie vraiment mais de quelqu'un ayant des facilités. Ca fait un peu "politiquement correct", mais ça aide à conserver une bienfaitrice humilité dans bien des cas (et par ailleurs je dois bien avouer que je ne doute pas une seconde que nombre de personnes pourront me trouver tout sauf humble dans ce post tout sauf court)

ps : désolé de la longueur du message, ceux qui ont tout lu gagne ma reconnaissance éternelle ! Voyez, si je fait de l'informatique, je me sens souvent meilleur en écriture... Ecrivant d'un côté, je m'enflamme parfois sur les forums... Sans avoir besoin de notes à côté Eternel meilleur à l'explication orale qu'à l'explication papier... bref bref bref, stop là, pause café...

[ALkyD]

Salut à tous,
j'avoue faire parti de ce qu'on appelle les programmeurs spontanés. Je bosse depuis une dizaine d'année dans le Web de façon solitaire, c'est-à-dire que je fais toujours tout dans un site, de A à Z, du code PHP au design sous Photoshop. Ces "conditions" de travail m'ont sans doute fait initier à la programmation spontanée...
En tout cas, je me reconnais totalement dans le post initial de ce topic, j'ai toujours tendance à visualiser ce que je veux faire avant, avant de transposer tout ça à l'écran avec plus ou moins de facilité (ça dépend de la tâche à faire). Quand un bug survient, je sais presque immédiatement d'où ça vient, y'a jamais de panique sauf quand IE/FF fument de la bonne moquette et m'affichent n'importent quoi... Je n'utilise rarement, voire jamais la paperasse sauf quand il s'agit d'énumérer une liste de tâches à faire pour éviter que je les oublie.
Au niveau du code, je suis complètement passé à la programmation orientée objet (avec php 5), ce qui facilite grandement ma manière de coder (de façon spontanée, donc); L'OO permet de structurer de façon modulaire, on rajoute et on enlève des portions de code presque comme je le veux...
Le revert de la médaille dans tout ça, c'st que ca va être chaud le jour où je vais aller travailler dans une entreprise, avec une équipe

[laurentibus]

programmé en mode spontané ça a du bon .... mais attention au revers de la médaille :

c'est sur qu on ne perd pas beaucoup de temps avec la paperasse des débuts de projet mais en contre partie on perd beaucoup de temps quand on veux s y replonger .....

moi je pratique la prog spontanné dans les cas suivants :
- prog personnelle
- petit projet en nombre de ligne et de personnes
- cas extreme : attente de résultat rapide ou trop rapide ...

donc a l inverse je ne pratique pas la prog spontanné :
- gros projet
- obligation travail propre pour évolution future


voila des fois c'est coOl des fois c'est a éviter ....
++

[mumen]

Oh quel ancien fil ! Le bel endormi n'est pas éteint, je vous le dis. J'étais passé dessus voici des années et je le retrouve avec délectation. Si cela vous plait, goûtez ma prose sur ce sujet cru, si bien tenu comme le sont les sujets sur DVP, malgré les forces antagonistes en présence ! Je vous la propose en deux parties, ma prose : une pratique ici tout de suite, où je m'exprime du fond du de développeur et une théorique ensuite, m'appuyant sur une science dite humaine, la typologie des caractères, qui est discrètement devenue plutôt dure — objective est le mot consacré —, par la grâce de la neuropsychologie, sous l'appellation de styles cognitifs.


PROGRAMMEUR SPONTANÉ

Je me situe sans aucun doute dans la même catégorie que tous ceux qui disent ici être programmeurs spontanés. Je ne me reconnais pas complètement dans cette appellation, mais quand même, c’est pas mal. En fait, je n’ai pas de flash, le code que je tape, je n’en sais rien avant de le taper, il se met en place en cycles d’essai/erreur, je me sens plus interprète de quelque chose qu’acteur volontaire. Je sais globalement où je veux aller et ça va où ça doit, sinon, c’est que je me suis trompé d’objectif. Je découvre plus que je n’invente, c’est une posture passive, attentive.

J’ai de profondes difficultés avec l’abstraction, je le sais. Quand je dois réfléchir à une modélisation, à un algorithme, je ne le fais pas avant, je le fais pendant. Je code et je regarde ce que ça donne, ensuite je rectifie. Si je travaille pour le client, c’est la même chose, sauf que c’est lui qui me dit si j’ai bon. En fait, quelque part, c’est toujours lui qui me dit si j’ai bon. Je réécris toujours les algorithmes clés plusieurs fois, parfois sur des années, avec un objectif multiple : clarté dedans, clarté dehors, largeur de champ, ne pas y revenir, utiliser, oublier. Ce n’est pas de la perte de temps pour tous les esprits. Cela s’appelle aussi de la refactorisation, je l’ai appris récemment.

Il m’arrive parfois de modéliser sur le papier. C’est très rare. Si cela arrive, c’est qu’il s’agit de choses excessivement complexes pour moi. Je fais des petits dessins au crayon de bois et avec une gomme. Quand c’est fini, je n’ai généralement plus besoin de mon dessin pour faire ce que j’ai à faire. Je le garde dans un coin, parce que je trouve ça amusant, le résultat de toutes ces heures passées dans un métro, dans la rue ou bien à table, à penser à un truc qui est finalement devenu tellement évident, que ce bout de papier n'est plus que l’empreinte dérisoire d’un long et pénible travail de tâcheron. Pour moi, l’analyse est quelque chose de magique. Le fait d’avoir anticipé une chose qui s’avère exactement coller à la réalité quand elle est réalisée me laisse éperdu d’admiration. L’analyse, ce n’est pas mon art, mai alors pas mon art du tout. Je suis tellement mauvais à ce jeu-là que j’ai dû développer des outils extraordinaires, à la mesure de mon incurie, pour pouvoir assurer en clientèle. En fait, c’est pour développer des outils que je suis bon. Là mon cœur bat. Outilliste je suis, outilliste je reste.

Mon code est moche, mais il s’améliore tous les jours, c’est vital. Mon code n’est pas commenté du tout. Comme je réécris toujours tout, mes commentaires deviennent aussitôt faux. Ils ne sont pas fiables alors j’arrête avec ça. J’ai lu dans ce fil une affirmation qui a peut-être le pouvoir de changer quelque chose à ce fait, qui m’est apparue tellement évidente qu’elle s’est gravée en moi, développeur toujours en devenir : « On ne commente pas le code, mais l'algorithme ». Génial. En attendant, je m’y retrouve toujours dans mon code, mais j’ai dû batailler contre moi-même, pour être plus rigoureux. Je développe « en live » une bibliothèque depuis 18 ans. Par endroits, dans cette bibliothèque, on peut voir les séquelles d'avant ces évolutions que je me suis imposées avec le temps : ici du code indenté sur une seule espace ; là un code sans déclaration de variables ; ailleurs pas d’introducteur de type avec mes variables, etc.

Pour moi, la plus grande difficulté de ce métier de développeur réside dans le nommage des entités. J’ai choisi le style « Camel Case » et je suis toujours en quête du bon mot. Je peux passer pas mal de temps, simplement à renommer plusieurs fois un code difficile pour moi. En 25 ans de pratique, j’ai atteint une espèce de sagesse qui me tient lieu de méthodologie. À mes yeux, la plus belle invention récente de structuration du code, d’amélioration de la lisibilité et de mise en perspective des parties de la procédure, c’est le bloc d’instruction With/End With qui va de pair avec l’objet. Son emploi réfléchi indique naturellement quelles variables intermédiaires il faut créer pour que le code soit « à l’aise ». Elle aère le code, le rend lisible et lui donne une cohérence dans l’accès des entrées/sorties. Bien sûr elle ne rendra pas meilleure la lisibilité du cœur de l’algorithme, mais elle le sert sur un plateau. Pour l’algorithme proprement dit, les variables clairement nommées, l’évitement des ruses et autres raccourcis, la décomposition primitive des choses complexes par l’ajout de variables intermédiaires, l’utilisation judicieuse des contrôles de flux comme le précieux Select, tout ceci et d’autres choses sont à l’origine d’un code lisible.


TOUT N'EST PAS ROSE EN CE BAS MONDE

Bien sûr, la bonne structuration procédurale est un incontournable pour moi depuis fort longtemps. Mais je regrette toujours ce moralisme sous-jacent qui prône l’interdit des structures intraprocédurales que sont les Goto et autres Gosub, au point de les désimplémenter dans VB.NET : non mais ! de quoi je me mêle ? Je n'utilise pas .NET et je ne suis donc pas atteint par cette facette du moralisme agissant. Mais par contre, quand Microsoft à décidé en 2000 de désimplémenter la mémorisation de la bibliothèque de code dans ce qui est mon outil de travail, Access, m'empêchant de fonctionner comme je le fais naturellement et fondamentalement, elle m'a planté un couteau dans le dos. Je regrette beaucoup ces postures suffisantes, dont je retrouve quelque écho ici dans ce fil, qui ne tiennent pas compte de la réalité des autres, au nom d'une prétendue supériorité théorique de gens finalement trop sérieux pour de mauvaises raisons.


CE FIL DE DISCUSSION

Vous le voyez, pour certaines personnes qui se sont exprimées sur ce fil, je suis un développeur hérétique : j’ai moins de vingt ans (au moins d’âge mental), je ne suis pas professionnel, je ne travaille que sur des petits projets qui deviendront forcément des usines à gaz. Ce que veut soulever l’ironie de cette remarque, c’est qu’il y a une espèce de déni de réalité, croissant tout au long de ce fil, par des gens qui s’autoproclament les seuls professionnels en programmation. Quand bien même une bonne dizaine de personnes, au 200e message de ce fil, auraient exprimé clairement et paisiblement ce que j’exprime ici, à savoir qu’on peut très bien être professionnel sans utiliser l’analyse avant de programmer, ces quelques personnes sérieuses continuent de nier le fait que peut exister une façon différente de programmer. Je ne leur jette pas la pierre, je veux juste souligner à leur intention que le monde est plus vaste que ce que dit la théorie ingénierale.

Qu'il existe une façon d'être programmeur que l'on puisse caractériser de spontanée ou bien d'instantanée selon moi, opposée à une autre façon d'être qui pourrait être qualifiée de séquentielle ou encore de logique, ne fait pour moi aucun doute. Je m'en exprimerai lors de mon second texte sur ce fil. Je suis persuadé que la première façon d'être programmeur est rendue difficile parce qu'elle est rendue honteuse, voire invisibilisée, par le déni et le moralisme que je mentionne ici. Cette façon d'être, qui est loin d'être marginale, s'accompagne le plus souvent d'autodidactisme et se trouve souvent caractérisée par l’isolement, ce qui la rend d’autant plus facile à railler sans argumentation qu'on se sent soi même fort d'être membre d'un groupe cohérent et puissant.

La raison pour laquelle j'adore littéralement ce fil de discussion, c'est qu'un gars, Doloop est venu parler tout tranquillement, sans désir d'en découdre, d'une chose qui existe. La suite, c'est que tout d'un coup une « armée » s'est spontanément levée d'individus dont on n’entend jamais parler, qui se sont reconnus, qui se sont vus exister grâce à lui sans complexes. Le fait que « l'armée ennemie » se soit mobilisée pour enrayer une telle progression insupportable est parfaitement habituel. Mais comme elle n'a pas trouvé ses victimes rituelles, déjà prêtes au sacrifice sur l'autel de la rationalité triomphante , il ne lui restait plus qu'à les nier !

Comme Doloop et comme ceux qui ont parlé après lui, avec la même distance dépassionnée, je ne désire pas m'élever en combattant. J'existe en tant que personne plus sensible que raisonnable, c'est comme ça (regardez le nombre de fois que j'emploie ici le mot cœur, regardez combien de fois ces programmeurs spontanés emploie des mots décrivant les sens et comparez avec les gens sérieux), et c'est aussi comme ça que je suis programmeur professionnel.


A bientôt pour la suite !

[I_believe_in_code]

Je crois que tout le monde est d'accord depuis le début du fil pour dire que lorsqu'on programme tout seul dans son coin, on peut le faire de façon "spontanée".

[dragonno]

J'essaie toujours d'étudier un algorithme avant de programmer, et pour moi c'est la meilleure façon de faire, mais chacun a son avis.
Pourquoi ? Parce qu'on perd moins de temps dans son projet quand on a pris le temps utile pour l'étudier.
Dans mes débuts, je programmais sans étudier mon projet, pour m’apercevoir ensuite que je devais le refaire presque de zéro parce que le programme ne convenait pas ou parce qu'il n'était pas évolutif vers des ajouts que je voulais faire.
Ou alors parce que je ne pouvais pas reprendre facilement certaines parties de code.
Depuis, j'étudie bien mon projet, je le divise en sections, je le rend maintenable et évolutif et cela je ne pourrais pas le faire en programmant directement sans étude du projet.

[petdelascar]

Pour moi, le temps le plus important est le temps qui se trouve avant l'écriture du code. L'écriture du code consiste à mettre à plat sa pensée, c'est limite inutile...

[vidici]

je pense qu'il est souvent utile de commenter ses commentaires, quelques fois on ne les comprend plus (c'est une blaque ... quoique).
mais plutôt que les commentaires, je prèfère un code explicite avec des noms de variables et de fonctions très signifiants.
un code le plus objet possible avec des classes courtes très spécialisées qui s'appellent les unes les autres de manière la plus évidente possibles afin de pouvoir remonter facilement la chaine de fonctionnement de l'application même quand on perdu le plan du labyrinthe.
Enfin coder du plus simple au plus complexe, par étapes itératives.

Comme je n'ai le loisir de coder que deux mois par an et ce tous les neufs mois environs, J'ai souvent eu du mal à comprendre mon ancien Moi, maintenant je me soigne même si revenir à la programmation après de longues absences est toujours difficile mais pas totalement négatif. Comment dire .. on est plus frais dans la tête, lavé de certains aspects négatifs de la programmation et autres bloquages, on voit les choses sous un angle different .

[e-ric]

Je connais 2 genres de programmeurs :

1. ceux qui font de la "programmation spontanée" et qui rament pendant des jours dans un code merdique à creuver. Qui ne comprennent pas la moindre ligne du code qu'ils ont écrit le jour d'avant et dans lequel ils cherchent un bugs, bien évidemment.
Ce sont les mêmes qui bien sûr commencent directement à taper, sans la moindre reflexion préalable (ben oui, ils sont en quelque sorte le programme).
Finalement, ils abandonnent... (et demande à un mec de la catégorie 2 de les aider, et le mieux est de tout recommencer)

2. Ceux qui prennent leur temps de tout plannifer et de concevoir avant de commencer à implémenter, qui connaissent déjà le noms de toutes les fonctions (methodes) et leurs spécifications. Bref, quand ils commencent à taper, ils n'ont aucun doute sur le fonctionnement final. Ils codent de manière claire et commentent le plus possible. Si parfois, il y a une erreur, ils la trouvent facilement : c'est souvent une faute d'inattention quelquepart où la fonction ne correspond pas à la spécification....

Généralement, les gens de la catégorie 1 sont déjà au mileu de l'implémentation quand les gens de la catégorie 2 commencent...

Il n'y a que des amateurs pour penser que la methode de la catégorie 1 est la meilleure! Ou des génis incompris...

Cela me semble très théorique, t'as sans doute jamais travaillé sur un projet de merde où il faut rendre les copies la veille... Passer des heures à concevoir n'est pas forcément un gage de réussite, j'ai déjà vu des "super" projets où tout était conçu sur plusieurs mois et qu'on laissé quelques semaines pour coder, bon courage... Après c'est aux développeurs de maintenance de panser les plaies...

[ClaudeBg]

Salut
-----

Pour ma part, je pense que travailler sans fil conducteur est une hérésie. Mon expérience concernant les débutants, par exemple, me montre que ceux qui tentent l'aventure sont les premiers à crier au secours et à afficher du code totalement déstructuré.

Maintenant faut-il dessiner un ordinogramme ou écrire un pseudo-code systématiquement? Ma réponse est mitigée:

Déjà si on est débutant, c'est clairement "oui, il faut le faire".

Si on est expérimenté, on peut arriver à s'en passer selon les cas, mais cette "impasse" n'est souvent qu'une apparence et non une véritable lacune.

En effet, si je prends mon propre cas, quand je commence un projet, j'utilise souvent un papier pour y griffonner les réflexions, la façon de distribuer les bits d'une trame, d'organiser mes données en mémoire, et autres "stratégies". Rien de formel, juste une base de réflexion.

Ensuite, il m'arrive de commencer à coder, sans ordinogramme apparent.

MAIS ça ne veut pas dire qu'en fait il n'y a pas un fil conducteur, c'est juste que, selon la taille et la complexité du projet, selon la cible et le langage, il m'arrive souvent de "voir" dans ma tête l'organisation de mon code, de façon "claire". L'ordinogramme, le fil conducteur, la structure, existent donc en réalité, ils ne sont simplement pas forcément transcrits. Il m'arrive même dans ces cas-là de commencer mon code par les commentaires, sorte de pseudo-code directeur.

Je suis certain que beaucoup de programmeurs ayant quelques années d'expérience arrivent ainsi à "visualiser" la route de ce qu'ils doivent écrire, et même si rien n'est formalisé par écrit, ils ne travaillent pas sans repères mais au contraire les ont "mentalisés".

Maintenant, il est clair également que si on travaille à plusieurs sur un même projet, qu'on est bien contraint de formaliser par écrit la route à suivre, si on ne veut pas que chacun parte de son propre côté. Je travaille actuellement sur un projet à base de plugins: j'écris la base, puis les docs, et ensuite on continue en groupe à partir des documents écrits, en sachant explicitement où on va et comment on y va.

A+
Claude

[Invité]

Crévindiou ! C’est-y donc qu’l’est point crevé, l’bestiau, qu’y bouge encore ? Plus de 16 ans qu’il a le p’tiot !... Et plus de 110.000 affichages !

Bon, moi, je ne l’ai connu qu’en 2008, il avait déjà quatre ans. Il s’est assoupi 5 ans de 2008 à 2013 puis s’est à nouveau endormi pendant 7 ans. Il faut une bonne raison pour le réveiller.

La raison, c’est que j’ai publié dernièrement un blog dont l’un de mes billets répond à la question de Doloop :

Ce type de programmation porte-t-elle un autre nom ?

C’est l’été 2018 et adepte de ce type de programmation, la question de Doloop me taraude le cerveau alors que j’aborde le sujet dans mon blog.

Quand je suis dans ces dispositions, je cours. Ce matin là, je décide donc d’aller courir avec la ferme intention de lui trouver un autre nom, moins polémique. Je n’ai pas fait 300 mètres que l’idée s’invite dans mon esprit, tel un flash aurait dit Doloop. L’idée, c’est le parallèle devenu évident entre le calcul mental et ce type de programmation. Je termine mon footing en cherchant la faille, en me persuadant que c’est bien là, la locution idéale, que je cherche. Et puis, c'est une façon élégante de clore cette discussion. Je vous livre le fruit de ma réflexion sur le sujet…

---

Billet : La programmation mentale

Ce blog est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS faisant office de SOMMAIRE agrège ces billets via des liens hypertextes.

■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■

• Le calcul mental
• Programmer mentalement
• Utiliser sa mémoire procédurale plutôt que sa mémoire immédiate
• Sophrologie et apprentissage procédural
• Programmation spontanée
• Flash
• Apprendre / Comprendre

La programmation mentale procède de la même manière que le calcul mental.

■ Le calcul mental

Source : Les astuces en calcul mental pour mieux calculer (Superprof Magazine)

Si certains ont des facilités, cela ne veut pas dire qu’il s’agisse de capacités innées. C’est une aptitude qui se travaille.

Certains scientifiques ont pu déterminer que le calcul mental active des zones du cerveau liées à l’attention spatiale. La représentation des nombres serait ainsi comparable à la représentation spatiale. Quand on compte, qu’on additionne ou qu’on soustraie, c’est comme si on faisait mentalement un déplacement vers la droite ou la gauche pour trouver un résultat. Une donnée importante quand on a des difficultés en calcul.

D’autres chercheurs se sont intéressés à Rüdiger Gamm, un génie du calcul mental, pour comprendre comment il parvenait à calculer de tête si facilement et résoudre des opérations incroyablement complexes.

Il apparaît dans ce cas que le génie du calcul, active des zones temporales préfrontales du cerveau, généralement impliquées dans la mémoire à long terme. Il dispose ainsi d’une multitude d’informations enregistrées qui lui permettent de battre des records de rapidité dans ses calculs.

Ce qu’il faut retenir, c’est que notre mémoire est notre meilleure alliée pour devenir bon en calcul !

Quoi qu’il arrive, la pratique du calcul mental doit être récurrente, régulière, environ 10 minutes par jours suffisent : notre cerveau doit acquérir des automatismes et pour cela, rien ne vaut de rabâcher encore et encore les mêmes formules, les mêmes calculs jusqu’à ce que cela devienne évident et naturel, comme le fait de faire du vélo ou simplement de respirer.

Le calcul mental s’exerce aussi bien à l’oral qu’à l’écrit et cette pratique doit s’appuyer sur des supports et des outils divers comme un cahier, un fichier de mathématiques, une ardoise, des cartes, des dés, un logiciel, etc.

Les outils basiques pour booster notre capacité en calcul mental :

• Les tables d’addition et de multiplication,
• Les connaissances des compléments du nombre 10,
• Connaissance des carrés jusqu’à 15² (=225) ainsi que des puissances de 2. Petite astuce concernant les puissances de 2, ce sont les mêmes que les tailles de stockage des disques durs ou des cartes mémoires (8 go, 16 go, 32 go, 64 go, 128 go…). Facile, non ?
• Technique de multiplication par des puissances de 10 avec des exposants négatifs (il faut déplacer la virgule vers la gauche) et des exposants positifs (déplacer la virgule vers la droite),
• Utilisation de la propriété « Diviser par un nombre = multiplier par son inverse », par exemple, diviser par 0.25, c’est multiplier 4),
• Apprendre les identités remarquables : (a+b) ² = a²+2ab+b², (a-b) ² = a²-2ab+b², (a+b) (a-b) = a²-b²,
• Apprendre les règles de la factorisation,
• Connaître des ordres de grandeur comme pour ϖ (3.14159), nombre d’or (1.618), racine de 2 (1,41).

Penser pratique !

Chacun doit trouver la méthode la plus efficace pour lui, un peu comme lorsqu’on apprend une langue et qu’on pense à des repères mnémotechniques que seul nous pouvons comprendre. L’important est que cela fonctionne pour nous et notre cerveau.

Exemple : en cas de panne avec la table de multiplication par 9. Il suffit de visualiser ses dix doigts levés, de baisser mentalement celui qui correspond au chiffre que l’on souhaite multiplier par 9, puis de compter le nombre doigts levés à gauche et à droite du doigt baissé. Soit 4 x 9 : on baisse le quatrième doigt, il est alors facile de compter mentalement 3 doigts à gauche et 6 à droite, donc 4 x 9 = 36.

On se rend compte que pour progresser en mathématiques et notamment en calcul mental, la question de la mémorisation est très importante : on doit apprendre par cœur les principes de base des mathématiques, connaître ses tables d’addition et de multiplication. Répétez sans cesse, encore et encore. Si on ne les pratique pas, on oublie !

Plus on entraîne son cerveau à se souvenir, plus des automatismes apparaissent et plus notre capacité en calcul mental augmente. Pour progresser, il faut s’entrainer, mettre en place diverses stratégies pour que les choses deviennent naturelles.

Cela demande, bien sûr, du temps, de l’investissement personnel mais le résultat en vaut franchement la chandelle puisque l’on conserve ces réflexes toute notre vie par la suite.

La première chose à garder en tête est que le calcul mental n’est pas inné.

• L’on pourrait résumer en deux mots l’idée du progrès en calcul mental : astuces et répétition. Effectivement, sans avoir jamais entendu ou constaté par soi-même qu’un nombre divisible par 9 l’est parce que la somme des chiffres qui le compose est un multiple de 9, sans connaître l’astuce pour multiplier tous les nombres entiers par 11, il est parfois difficile de calculer plus rapidement.
  
  
• Ceux qui calculent ne sont pas nécessairement des génies, ils ont juste conscience de ces astuces, les ont utilisés plusieurs fois jusqu’à ce qu’elles deviennent presque naturelles. Car comme toute chose, il ne suffit pas d’avoir simplement déjà eu connaissance de ces astuces pour progresser, il faut les utiliser. La répétition permet d’intérioriser chacun des processus et cela n’est pas simplement vrai que pour le calcul mental.

Cette gymnastique de l’esprit prend réellement corps à mesure que l’on fait des opérations. Le cerveau va développer avec la répétition, des raccourcis logiques qui permettent de calculer bien plus rapidement.
 
■ Programmer mentalement

Mentaliser sa programmation, c’est s’affranchir des contraintes, des carcans, des méthodes rigides, des algorithmes modélisés, des normes, des documentations, etc. C’est se simplifier la vie, épurer sa démarche, être autonome, prendre des raccourcis pour être efficace.

La programmation mentale n'implique pas "arrache", "bidouille", "manque de qualité", "affinité avec certains problèmes spécifiques", "intuition", "aucune analyse", etc… comme l’affirment ceux qui condamnent le concept sans même le comprendre. Bien au contraire, cela signifie que dans sa tête, il faut être en quelque sorte "câblé", que le programmeur maîtrise son sujet, qu'il se soit interrogé, qu'il ait installé puis personnalisé sur son petit disque dur (sa mémoire procédurale) diverses méthodes de développement et de travail lui permettant d'avancer sans se tenir à son trotteur.

Reste à exprimer le non-dit, à identifier quels acquis ont participé à un formatage cérébral libérateur des contraintes conventionnelles. Mais la programmation mentale est difficilement verbalisable car elle concerne l’acquisition d’automatismes, la mise en place de stratégies pour que les choses deviennent naturelles. Il appartient à chacun de trouver la méthode la plus efficace pour penser pratique, un peu comme lorsqu’on pense à des repères mnémotechniques que seul nous pouvons comprendre.

Les développeurs arcboutés sur leurs conditionnements universitaires attribuent à cette démarche tous les maux qu’ils rencontrent dans leur environnement. Cela ne fait que révéler leur incapacité à entreprendre une démarche personnelle. La qualité de la programmation mentale est exceptionnelle car elle est inspirée par une réflexion murie.

L'important, c'est de témoigner que l'on peut développer autrement. Ceux que cela dérange ne sont pas obligés de changer leur façon de travailler.

■ Utiliser sa mémoire procédurale plutôt que sa mémoire immédiate

Il s’agit de substituer au développement jouissif exploitant la mémoire immédiate, la maitrise d’un développement sur le court, le moyen et le long terme.

La passion du codage pour le codage doit satisfaire les addicts au jeu. Cela doit correspondre à un mode de raisonnement par conditions qui participe à une programmation jubilatoire exploitant la mémoire immédiate. Ce faisant, c’est la personnalité du programmeur qui structure la programmation et non le raisonnement sur la base des actions. La maintenance du programme consiste alors à comprendre la démarche alambiquée du programmeur plutôt que d’en comprendre les fonctionnalités.

Quand on a assimilé le raisonnement par traitements (LCP), le codage est là où il doit être, comme il doit être et rien de plus. L’intérêt du codage est moins dans le fond que dans la forme, à savoir l’adoption de règles d’écriture.

Ne pas exploiter sa mémoire immédiate mais sa mémoire procédurale oblige à s’organiser, à structurer sa pensée (LCP), à s’inventer une codification, une normalisation, une charte graphique (indentations, minuscules/MAJUSCULES, etc.), à se créer des automatismes simplificateurs, à construire cette mémoire procédurale pour être en mesure de programmer facilement, rapidement, sainement, et de toujours être capable de se relire, de comprendre ce que l’on programme. Ainsi, l’algorithme se concrétise mentalement en même temps que la prise de connaissance et l’exploration de la fonctionnalité à programmer. La démarche algorithmique structurée dans la mémoire procédurale s’adapte instinctivement à la spécificité de la fonctionnalité.

La mémoire procédurale est également très sollicitée chez les sportifs de haut niveau comme chez les artistes : elle permet d’acquérir des procédures gestuelles parfaites et atteindre l’excellence dans une discipline sportive ou un domaine musical… ou dans le développement informatique.

La mémoire procédurale fait partie des types de mémoire qui résistent le mieux aux années qui passent. Elle occupe ainsi une place majeure de notre mémoire à long terme. Les souvenirs qui y sont stockés sont en réalité une association de savoir-faire : des automatismes que nous avons enregistrés à force de répétition.

La mémoire procédurale est considérée comme une “mémoire implicite”, c’est-à-dire inconsciente. Il existe une phase explicite d’apprentissage en début d’acquisition, puis la procédure s’automatise et sa mise en œuvre finit par ne plus demander d’effort mental particulier. Nous appliquons, comme par réflexe, la méthode gestuelle que nous avons acquise lors de notre apprentissage.
 
■ Sophrologie et apprentissage procédural

Je l’ai évoqué à plusieurs reprises dans des discussions sans faire le rapprochement avec la mémoire procédurale, avec ce que j’appelle dorénavant la programmation mentale.

Comme pour le calcul mental :

• la pratique de la programmation mentale doit être récurrente, régulière.
  
  
• Plus on entraîne son cerveau à se souvenir, plus des automatismes apparaissent, plus des raccourci logiques se créent et plus notre capacité en programmation mentale augmente. Pour progresser, il faut s’entrainer, mettre en place diverses stratégies pour que les choses deviennent naturelles.
  
  
• Les progrès en programmation mentale reposent sur les astuces et la répétition. La répétition permet d’intérioriser chacun des processus.

La sophrologie participe à ce que l’on appelle l’apprentissage procédural.

Discussion : Qui pratique la programmation spontanée ?

IFA2377 :

Je ne vais pas reprendre tout ce qui s'est dit dans cet esprit depuis plus de quatre ans. Je rappelle simplement quelques-uns de ses premiers arguments pour identifier sa façon de fonctionner que j'assimile à la "sophrologie".

Le Docteur Alfonso CAYCEDO, psychiatre d’origine colombienne, ne formalisa le concept qu’à partir de 1960. Sa « RELAXATION DYNAMIQUE » comme il l’appelle alors, synthétise et occidentalise les pratiques du Yoga, du Bouddhisme et du Zen. Leurs effets sur la conscience humaine devant lui permettre de traiter ses patients.

Intuitivement mais consciemment, je pratique la sophrologie depuis toujours. C'est en quelque sorte un mode de vie. Beaucoup de personnes la pratiquent sans le savoir. Pour ma part, j'ai toujours eu conscience de fournir l'effort mental qui consiste à se sophroniser. Les principaux domaines pour lesquels j'ai ou j'ai eu recours à la sophrologie sont les études, le sport de haut niveau, mon métier de développeur, la conduite automobile, etc.

Je n'ai mis un mot sur ce que je pratiquais, qu'à l'occasion de la naissance de mon ainé, en 1977. Un médecin, le docteur Davrou, proposait alors à un groupe de femmes enceintes de les préparer à l'accouchement par la sophrologie. Le docteur Davrou enseignait déjà les pratiques de la sophrologie aux cancéreux en phase terminale. Il s'impliquait également dans le sport, notamment dans l'entraînement de l'équipe nationale de volley-ball.

Petite digression à propos de la sophrologie et du sport :

Disciple du Docteur Alfonso CAYCEDO depuis 1963, le docteur Raymond ABREZOL est l’un des premiers Sophrologues à avoir adapté les techniques sophrologiques au sport (dès 1966).

Manuel AGUILA (SOPHROLOGIE ET SPORT) décrit l’entraînement sophrologique comme une stimulation de l’imagination par le biais de phases de visualisation : « L’athlète découvre cet état particulier où il peut corriger les épreuves qui le nécessitent et programmer ses futures performances. Lors d’une compétition, son cerveau met tout en œuvre pour reproduire ce qui a été précédemment enregistré. Au-delà de l’apprentissage technique conscient survient l’art. L’atteinte de ce niveau de réalisation, dans le cadre sportif, passe par ce que l’on nomme "le lâcher prise".

En associant les pratiques sophrologiques à son entraînement, on intervient sur sa capacité de concentration et d’attention, son énergie et sa puissance physique, sa capacité de récupération après l’effort, sa motivation et sa combativité, d’éventuelles inhibitions, la confiance en soi et en ses potentiels, l’image que l’on a de soi-même, l’intégration de son schéma corporel, la sensibilité interne de son propre organisme (apprentissage des mouvements – cénesthésie, synesthésie, somesthésie), la fluidité de ses mouvements, la mémorisation de ses séquences sportives, la gestion de son seuil de douleur, sa capacité à gérer le stress, etc. ».

Concrètement, la sophronisation de l’athlète peut être vue comme un travail mental d’auto-programmation, de maîtrise de soi dans l’espace et dans le temps, chaque paramètre (effort, récupération, concentration, motivation, etc.) s’intégrant dans l’approche globale d’un ou plusieurs objectifs. Les athlètes se sophronisent tous plus ou moins consciemment et à des degrés divers. Au début du siècle dernier, lorsque le lanceur de poids Raoul PAOLI, en pleine concentration, demande à un athlète venu l’encourager, de le laisser tranquille parce qu’il est en train de devenir champion olympique, n’était-il pas en phase de visualisation pour utiliser le langage d’aujourd’hui. C’est sans doute sur les sautoirs, notamment celui de la hauteur, que les athlètes extériorisent le plus leur processus de sophronisation en mimant le saut qu’ils visualisent mentalement.

Je me suis permis cette parenthèse sportive pour mieux concrétiser l'effort mental que représente la pratique de la sophrologie et assimiler son principe dans une démarche de développement.

■ Programmation spontanée

Il est fait ici référence à une discussion ouverte par Doloop le 28/12/2003 et qui s’est prolongée jusqu'au 22/07/2008, soit pendant 4 ans ½.

Dans son texte initial, il se demandait si ce qu’il appelle la programmation spontanée portait un autre nom. Le thème de la discussion étant très proche de mes préoccupations, il était intéressant de prendre connaissance des arguments échangés puis d’apporter mon point de vue.

Discussion : Qui pratique la programmation spontanée ?

Doloop :

Salut à tous,

Je souhaiterais savoir si beaucoup de personnes programment de manière spontanée comme moi.
J'ai déjà posé des questions à des personnes du domaine et ce n'était pas le cas pour eux. Cependant sur ce forum et d'autres, il y a des posts qui me semblent confirmer que oui.

L'auteur d'un livre dans les années 80, annonçait qu'il n'y aurait que 10 % des programmeurs qui peuvent se passer de dessiner un algorithme pour faire un programme.

Faisait-il allusion à la programmation spontanée, ou ce type de programmation porte-t-elle un autre nom ?
Double définition : Qui se fait de façon naturelle, sans arrière-pensée / Que l'on fait de soi-même, sans sollicitation extérieure.

L'algorithme, on l'invente directement dans le programme au fur et à mesure des besoins qui se font ressentir au moment de se focaliser sur des points précis.

Devant le clavier, on sait immédiatement ce que l'on a faire, il suffit de transposer ce que l'on voit mentalement sur l'écran.

(Avec l'expérience, par concentration les solutions sur les points délicats des programmes, apparaissent dans la tête sous forme de flash.)

Attention cela ne veut pas dire que l'on ne fasse pas de bugs, si bug il y a, il n'est pas de structure, le programme est destiné à fonctionner sans modifier l'algorithme pensé initialement.

Face à un bug, aucune panique par rapport à nos débuts, on sait qu'on va le trouver, ça remplace un jeu de déduction sans plus.

Il n'est même pas nécessaire de rajouter le moindre commentaire pour comprendre ses propres programmes ou ceux des autres.

A la lecture des lignes d'instruction, on les simule dans sa tête. (Inutile de paraphraser ce que l'on est en train de lire)

Je suis persuadé que tout le monde peut y arriver à force de pratiquer.

Cela fait penser aux dessinateurs comme Cabu et Plantu qui peuvent commencer leurs dessins par n'importe quel bout et parvenir au même résultat à la fin.

(En ce qui concerne le dessin, ça doit être moins sûr. On doit avoir le truc en série ou on ne l'a pas)

Je rajoute une information qui me concerne et qui a peut-être son importance, c'est que je n'ai pas la mémoire qui retient facilement les récitations, en contrepartie j'utilise la mémoire dite procédurale.

La mémoire procédurale est peut être la mémoire la plus sollicitée pour programmer ?
Une personne sur un autre forum avait dit qu'il devenait en quelque sorte le programme (un peu comme Rambo devient la guerre).

Ce qui prouve bien que ce cas n'est pas une exception.

Qu'en est-il de vous et de ceux que vous connaissez ?

Merci pour vos réponses, et joyeuses fêtes à tous.

@+

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Sans reprendre tout ce qui s’est dit en plus de quatre ans, je comprends tout-à-fait ce que veut dire Doloop quand il dit :

• Devant le clavier, on sait immédiatement ce que l'on a à faire, il suffit de transposer sur l'écran ce que l'on voit mentalement.
  
  
• L'algorithme, on l'invente directement dans le programme au fur et à mesure des besoins qui se font ressentir au moment de se focaliser sur des points précis.
  
  
• Le programme que l'on a conçu, il est en nous, en le parcourant c'est un peu comme si l'on se promenait dans sa tête.
  
  
• Une personne sur un autre forum disait qu'il devenait en quelque sorte le programme.
  
  
• Il m'est déjà arrivé de continuer à débugger un programme l'ordinateur éteint, on l'allume et c'est bien ça.
  
  
• Avec l'expérience, par concentration, les solutions sur les points délicats des programmes, apparaissent dans la tête sous forme de flash.
  
  
• La programmation spontanée se vit, mais ne s'explique pas fondamentalement, elle fait partie de nous.
  
  
• La programmation spontanée, c'est avant tout du travail mental assisté par de la méthode.
  
  
• Je n'ai jamais prétendu que la programmation spontanée était facile surtout au début, cela demande beaucoup d'effort mental à cause de tout ce qu'il y a à apprendre, ensuite c'est l’expérience qui fait le reste.
  
  
• Un programme qui emploie des noms de variables, de sous-programmes et de fonctions significatifs pour moi contient plus d'informations que nécessaire, c'est comme pour le Port-Salut, c'est marqué dessus.
  
• Qu'est ce que l'on peut apprendre lorsque l'on est obligé de tout faire !
  
  
• J'ai remarqué que conduire une voiture pour moi, nécessitait plus d'effort d'attention cérébrale, que de passer une journée entière à programmer et à débugger.
  
  
• À chaque programme réalisé, l'autosatisfaction est quasi inexistante, on est content que le programme soit terminé, on n'est pas déçu mais sans plus, on pense davantage au prochain qu'à celui qui vient d'être fait.
  
  
• La seule envie finale, c'est de surpasser le programme, pour que ce ne soit plus le programme qui nous dépasse.

Doloop disait :

- Je rajoute une information qui me concerne et qui a peut-être son importance, c'est que je n'ai pas la mémoire qui retient facilement les récitations, en contrepartie j'utilise la mémoire dite procédurale.

- La mémoire procédurale est peut être la mémoire la plus sollicitée pour programmer ?

ErwanVDF lui répondait :

- Je pense que la plupart des gens ne comprennent même pas ce que tu entends par là.

■ Flash

Le flash évoqué par Doloop correspond en quelque sorte à un alignement des planètes ou au jackpot d’une machine à sous. Pendant que l’esprit réfléchit à un problème, plusieurs zones du cerveau « tournent » en arrière plan, notamment les zones impliquées dans la mémoire à long terme. À un moment donné, un détail de la réflexion en cours réveille les processus en tâche de fond, une réaction en chaine se déclenche et apporte la solution aussi soudaine qu’évidente. Le flash devient l'aboutissement conscient, contrôlé, maîtrisé de la solution.

La perte de la mémoire immédiate : De façon schématique, le processus de mémorisation peut se décrire en 4 phases : L’apprentissage : analyse immédiate de l'information sensorielle ; La mémoire immédiate : persistance au niveau cérébral de la trace sensorielle. L'ensemble des informations ainsi conservées constitue l'empan de la mémoire (quantité d'informations pouvant être stockées par la mémoire à court terme). Le stockage mnésique : regroupement des données et leur codage. Ce stockage dépasse l'empan. Il est basé sur l'élaboration de processus associatifs et comporte une phase de consolidation dans le temps qui évite la perte d'information. Le rappel mnésique : réutilisation des informations stockées. Si le sujet les raconte ou les revit mentalement, c'est l'évocation. S'il les retrouve lors d'une nouvelle confrontation, c'est la reconnaissance. On distingue plusieurs sortes de troubles de la mémoire (amnésies) : L'amnésie antérograde (syndrome de Korsakoff) : le patient ne fixe plus les souvenirs et oublie tous les événements au fur et à mesure qu'ils se présentent. C'est une amnésie des faits récents alors que le souvenir des faits anciens est conservé. L'ictus amnésique : perte de mémoire isolée, antérograde, chez un sujet âgé de 50 à 70 ans, sans cause déclenchante apparente, sans signes prémonitoires, durant quelques heures et ne laissant comme séquelle qu'une amnésie lacunaire pour cette période. Le malade est incapable de se souvenir de ce qu'il vient de faire : il pose les mêmes questions et répète sans arrêt les mêmes choses. En revanche, il connaît son âge et son identité. Les capacités intellectuelles sont conservées. C'est en général un incident bénin et sans cause. L'amnésie globale concerne les faits récents et anciens et se voit dans les démences.   La mémoire procédurale La mémoire procédurale est une forme de mémoire non déclarative. La mémoire procédurale est une mémoire à long terme implicite qui permet la motricité automatique. Elle concerne l’apprentissage et le stockage des savoir-faire comme jouer du piano, faire du vélo, planter un clou, marcher, etc. En pratiquant ces activités, la mémoire améliore nos performances jusqu’à créer des automatismes. C’est une mémoire que l’on active alors de façon quasi inconsciente. Cette mémoire n’est donc pas verbalisable puisqu’elle ne concerne que des mouvements. Elle fonctionne grâce à différentes zones du cerveau, comme le cervelet ou le striatum. Ces zones sont toutes reliées entre elles par des synapses fonctionnant avec des neurotransmetteurs. Cette association permet l’apprentissage progressif de procédures. Celles-ci sont d’abord traitées par la mémoire déclarative et de travail puis sont intégrées dans la mémoire procédurale grâce à la répétition. Mémoire à long terme La mémoire à long terme est essentielle pour pouvoir progresser. Il n’existe pas “un” centre de la mémoire dans le cerveau, mais bien plusieurs réseaux neuronaux distincts interagissant entre eux. Ils sont observables notamment par IRM au cours de tâches de mémorisation. Un élément à mémoriser est constitué des diverses informations sensorielles, temporelles ou encore émotionnelles. Elles ne sont pas conservées au même endroit. Le cerveau conserve le souvenir de la synchronisation de ces différentes informations. Un souvenir n’est pas un enregistrement forcément valide de la situation réelle et peut varier au cours du temps. Lorsque l’on se souvient, la tâche de reconstruction du cerveau peut être plus ou moins fidèle selon la date du souvenir, et est influencée par le présent. Les mémoires s’appuient les unes sur les autres. Par exemple, la mémoire épisodique utilise la face interne des lobes temporaux et plus spécifiquement les réseaux neuronaux de l’hippocampe. La mémoire sémantique, quant à elle, utilise davantage de réseaux dans les parties intérieures des lobes temporaux. Enfin, la mémoire procédurale utilise des réseaux neuronaux sous-corticaux et le cervelet, qui joue un rôle très important dans le contrôle moteur. Selon Charles Scott Sherrington, « la mémoire se forme au sein de réseaux de neurones qui, après avoir été activés de manière intense ou répétée, gardent une trace de cette activation en renforçant leurs contacts ». Le fonctionnement de la mémoire à long terme dont fait partie la mémoire procédurale se fait en trois grandes étapes : L’encodage est la capacité à transformer l’information entrante et les stimuli. Il peut être intentionnel ou non. C’est l’apprentissage et l’entrée de l’information, la mise en mémoire de celle-ci, venant de nos différents sens, que ça soit la vue, l’ouïe, l’odorat, le toucher ou encore le goût. De la qualité de cette phase dépendra la qualité des phases suivantes, que ça soit dans la durée des souvenirs ou bien de leur fiabilité, leur exactitude. Plus l’attention portée à la phase de l’apprentissage est importante, plus celui-ci sera de qualité. Afin de faciliter l’encodage, on peut aussi utiliser des stratégies, par exemple sémantique (placer un mot dans une catégorie telle que l’animal, ou encore associer des attributs à un mot…). On appelle les informations transformées traces mnésiques. Le stockage ou conservation : lors de cette phase, les informations sont maintenues en mémoire et consolidées. Cette phase peut durer de quelques secondes à plusieurs années, elle peut aussi avoir lieu lors du sommeil, c’est pourquoi celui-ci est essentiel dans le processus de mémorisation. Le cerveau va répéter, sans que l’on s’en rende compte, les informations enregistrées lors de l’encodage et va ainsi les ancrer plus profondément dans la mémoire. Ces traces mnésiques vont, dans cette étape, passer de la mémoire à court terme à la mémoire à long terme. Rappel ou récupération ou restitution : lors de cette phase, les souvenirs et les informations sont récupérés, cette phase se fait de façon consciente ou inconsciente. L’information présente dans la mémoire à long terme revient dans la mémoire à court terme afin d’être accessible. Cette information peut alors être utilisée, on dit qu’elle est extraite de la mémoire. L’information est donc appliquée, c’est comme cela qu’on se rappelle comment faire du vélo, comment faire du piano… Cette phase de rappel permet de retourner une information déjà apprise et mémorisée. Cette récupération peut être consciente ou non. Apprentissage procédural La mémoire procédurale est une mémoire qui implique l’apprentissage d’un processus cognitif, permettant la réalisation inconsciente d’une procédure motrice. Ce processus n’est possible que par la répétition, qui va permettre une amélioration de la précision spatiale et temporelle et une diminution de l’attention nécessaire à sa résolution. La résolution de n’importe quelle activité donnée implique un apprentissage, qui repose sur la mémoire procédurale. Son but est d’économiser les ressources cognitives et de permettre la réalisation simultanée d’autres tâches. La mémoire procédurale est permise grâce aux propriétés malléables des circuits neuronaux dans différentes zones du cerveau. Pour les biologistes, la trace mnésique repose sur la neuro-plasticité qui permet des modifications à long terme des neurones au niveau de leur biochimie et de leurs aptitudes à faire des synapses. L'avènement de nouvelles techniques d’imagerie cérébrales, comme l’IRM fonctionnelle, permet d’examiner sur une longue période les corrélats neurobiologiques et l’apprentissage. L’étude de l’apprentissage de mouvements des doigts suggère que l’acquisition et l'utilisation d’une nouvelle tâche motrice se fait par une réorganisation significative de certaines zones (par exemple des lobes temporaux) se produisant en plusieurs étapes. La mémoire procédurale est caractérisée par une grande résistance aux pathologies, c’est pourquoi son acquisition est de la plus grande importance, mais celle-ci est relativement longue (de quelques semaines à plusieurs mois voir plus). D’après l’étude et les résultats de Francis Eustache et Hélène Beaunieux, on démontre bien 3 phases essentielles dans l’acquisition de la mémoire procédurale. Pour la première fois, ils démontrent aussi l’implication de la mémoire sémantique et des fonctions exécutives lors de la 1ère phase d’apprentissage. D’après le modèle ACT-R (Adaptive Control of Thoughts) de John Robert Anderson (1999), les trois phases d’apprentissages sont les suivantes : cognitive, associative et autonomie. La pratique peut déclencher des processus neuronaux évoluant plusieurs heures après la phase d’attention. Chaque expérience, même courte, peut entraîner des effets à long terme. L’apprentissage procédural se déroule de la manière suivante : phase précoce d'amélioration rapide, avec une forte progression dans l’apprentissage (établissement d’un plan optimal d'exécution), qui demande de nombreuses ressources et s’appuie sur la mémoire déclarative ; phase tardive lente, de nouvelles acquisitions se mettent en place, l’apprentissage devient plus long, démarrage de la procéduralisation ; phase de consolidation (permise si aucune activité n’est réalisée), lors du sommeil par exemple ; L'automatisation de l’activité s’organise, et permet d’utiliser de faibles ressources attentionnelles ; étape de maintien, où l'habileté peut être exécutée après une longue période de non utilisation ; en cas de non répétitions sur une très longue durée, oubli progressif de l’apprentissage.

■ Apprendre / Comprendre

On apprend une recette avec l’objectif de la reproduire mais comprendre une recette, c’est bien davantage, c’est se donner les moyens de la réinventer, c’est réfléchir par soi-même, c’est ne rien faire sans comprendre pourquoi on doit le faire.

Apprendre, c’est hériter d’une maison, c’est stocker des connaissances.

Comprendre, c’est construire sa maison, c’est façonner du lien, du sens, c’est s’approprier des savoirs.

Pour mentaliser LCP, il faut avoir exploré la démarche dans tous ses recoins, il faut avoir compris le cheminement algorithmique dans chaque situation : contrôle, mise-à-jour, édition, interactif. Il faut savoir corréler la démarche avec le langage pratiqué. Cela demande du temps et la volonté d’ancrer la logique hiérarchique par traitements au plus profond de soi. L’effort mental est intense et continu, jusqu’à ce que l’organigramme s’impose de lui-même, devienne évident et naturel, ne soit plus nécessaire sur le papier.

APPRENDRE	COMPRENDRE
Stocker des connaissances Fait appel à la mémoire De l’ordre de la technique (du comment) Mécanique Logique Pas de qualificatif dérivé Gain de temps Transfert parfois aléatoire Plus facile à enseigner	Créer des liens entre des informations Fait appel à l’intelligence De l’ordre de la démarche ; du pourquoi au pour quoi (une suite d’étapes ordonnées) Deux qualificatifs : (in) compréhensible La démarche se construit et prend du temps Transfert facilité dans le réseau conceptuel Difficile d’aider à comprendre

[Invité]

Bon, moi, je ne l’ai connu qu’en 2008, il avait déjà quatre ans. Il s’est assoupi 5 ans de 2008 à 2013 puis s’est à nouveau endormi pendant 7 ans. Il faut une bonne raison pour le réveiller.
...

Merci pour le déterrage, j'ai 3 questions :

1. en quoi la programmation informatique mettrait-elle en jeu les mêmes processus mentaux que le calcul mental et la mémorisation ?

2. as-tu des exemples concrets (en conditions réelles) de projets informatiques qui valideraient tes théories ?

3. penses-tu que l'article "Les astuces en calcul mental pour mieux calculer" (Superprof Magazine) est une source de confiance étant donné que parmi les quelques commentaires qui le suivent, 3 indiquent des erreurs dans les calculs présentés ?

[Mat.M]

Apprendre, c’est hériter d’une maison, c’est stocker des connaissances.
Comprendre, c’est construire sa maison, c’est façonner du lien, du sens, c’est s’approprier des savoirs.

je rajouterais un 3ième point : " satisfaire aux injonctions du développement personnel c'est devenir un crétin fini" ..
ne m'en voulez pas mais tout ce que vous nous avez écrit ça ressemble à de la Programmation Neuro Linguistique bref un truc qui prend bien les gens pour les idiots

[Jacques54]

Pour ma part, j'ai déjà tenter la programmation spontanée mais rien de bien concluant. Pour moi si l'on veut vraiment avancer efficacement sur un projet il faut poser ses idées pour y voir plus clair. Mais ce n'est que mon avis

[oooopppp]

Salut,
perso. je prog. en spontané, sur de gros projets en dev. web car je prog. seul mais
j'essaie de me tenir à cette rigueur :
1 commentaire / 1 ligne de code / 2 sauts de ligne
des nommages clairs et explicites des variables et des fonctions en SnakeCase, mais sans majuscules, genre ma_fonction_qui_va_bien()
ou ma_variable_explicite. (EN ENGLISH)
Finalement je passe beaucoup de temps sur le nommage, l'indentation et la lisibilité,
jusque là pas trop de soucis pour relire le code et retrouver la logique.

Par contre, je viens de me former sur Java et là je vois tout l’intérêt d'une doc. précise et de longs commentaires,
en plus il y a un outil de rédaction de documentation (bon, ça liste les objets et leur propriétés/méthodes, mais c'est déjà pas mal)

[ConcombreMagique]

ça fait 7 ans que je travaille pour de tres grosse boites sur de tres gros projets (jusqua 20 dev sur le meme projets), on est ce qu'on apelle des "ingénieurs d'études".

On ne fait que de la programmation spontannée, on ne dessine pas d'algo et on écris pas de pseudo code.

L'architecture : table dans la BDD, format du XML qui transite dans les flux est definit par les architecte, puis nous les devellopeurs on nous fournit des specification qui disent l'utilisateur peut faire ci, ça et on choisis les technologie et on code, mais personne, et je dis bien personne, ne dessine d'algo (sauf peut etre celui qui sort d'ecole et qui n'arrive pas a maintenir dans sa tete une double boucle for)

Apres ça viens peut etre de ma branche, je travaille sur des SI, c'est a dire un site web en general en java qui permet de gerer toute une branche d'une entreprise, ou encore ces dernier temps sur des appli android.

La je fais des script python dans le cloud qui traitent des document sur S3 via des appel de micro-service.

Du coup je trouve tres etrange les réponse de la page 1, dans quelle branche travailler vous?

ça doit pas etre la meme chose sur de la reconaissance d'image ou encore de l'analyse financière.

et de longs commentaires,

Chez nous les commentaire sont interdis, si tu as besoin de commentaire soit tu ne sais pas lire le code :

ex :

// insere en bdd l'user
UserDao.insert(user)

ou encore ton code est trop complexe et tu devrais faire une methode privé

// extrait les intervention T4 de JDD
[40 lignes de codes]

ici il faut faire une methode qui s'apelle 'extractT4InterventionFromJDD(Jdd jdd)' et si il y a des chose speciale a dire sur cette methode ça sera dans sa javadoc

[Bousk]

tres grosse boites sur de tres gros projets (jusqua 20 dev sur le meme projets)

Énormes projets de 20 personnes, merci de me faire rire de bon matin