Discussion :

[iubito]

disons que la solution peut venir en une seconde, d'un coup... après longue réflexions. Tu cherches, tu cherches... et d'un coup boum! tu saute du lit à 4h du mat' et poc!poc!poc! sur le clavier => compil' => "youpiiii! ça marche"

lol

mes moments favoris pour réfléchir trankilou (que ce soit à de la prog, ou imaginer une compo musicale) c dans les transports, dans le bain, ou dans le lit

Dans le même style, Beethoven s'est écrit dans sa tête une bonne partie de sa sonate Appassionnata, alors qu'il était en balade avec un ami. Il n'a pas ouvert la bouche de toute la promenade, et quand il est rentré chez lui il s'est jeté sur son piano et a joué ce qu'il avait imaginé !

[Invité]

Le coup du "flash", pourquoi pas, mais en général ça arrive après avoir tourné et retourné un point précis dans ta tête. De là à spontanément résoudre des problèmes complexes, à froid et sans élan :

Je ne veux pas casser l'ambiance, mais faudrait redevenir sérieux...

[mat.M]

Iubito tu y vas un peu fort et je partage l'avis de FLorian et Catbul.
On peut avoir des "flash" mais tout de même la musique et l'informatique ce sont des choses différentes.
La musique relève plus de l'artistique ( bien qu'il y ait un côté technique comme le solfège etc...) , un sens inné ( ? ) artistique , avoir l'oreille musicale comme tu le suggères.
Certes il faut un minimum de technique pour écrire des partitions, faire des accords.

Alors que l'informatique c'est basiquement TRES technique , encore une fois je me répète un programme informatique c'est semblable à un jeu de construction type Meccano où il faut assembler des modules avec d'autres ou bien un méchanisme d'horloge suisse.
Si tu ne conçois pas un mode d'emploi "minimal" tu vas être vite perdu .

Un programme informatique répond plus à un besoin fonctionnel ( sauf à la rigueur un jeu vidéo mais cela demeure basiquement technique aussi ) tandis qu'un morceau de musique c'est un mode d'expression....

[iubito]

dans les 2 cas c'est une construction, construction d'une symphonie ou construction d'un programme. Tout comme un architecte conçoit une maison, ou un menuisier un meuble.

Il y a du technique, et il y a de la création (de l'artistique).

Le musicien a sa clé de sol et son solfège,
Le menuisier a ses outils et ses bouts d'bois,
L'architecte a son crayon et son papier,
Le programmeur a son clavier et ses langages.

(manque plus que les rimes et un pied dans le 3e vers et ça fait un alexandrin.... je crois )
hem...bon... tout ça pour dire qu'un esprit créatif c'est très bon pour un programmeur

Pour le musicien c'est se jouer la mélodie dans sa tête, le menuisier et l'architecte c'est se représenter l'ouvrage dès le début, et pour le programmeur ça va être faire tourner un algo, ou voir le déroulement entier de son application écran par écran...

voilà quoi...

[epeios]

Cela fait des années que je pratique la programmation spontanée et cela me convient parfaitement.
Pour pratiquer ce genre de programmation, il faut disposer des outils adéquats, c'est-à-dire à la fois du bon langage et des bonnes bibliothèques. Pour ma part, j'utilise C++ comme langage et pour ce qui est des bibliothèques, comme je n'en ai trouvée aucune qui me convenait, je les ai conçus moi-même. Grâce à ces outils, écrire un programme consiste simplement à écrire les différents algorithmes mis en oeuvre directement dans mon éditeur, sans passer par l'étape papier. Dés lors, les commentaires deviennent superflus, puisque la correspondance entre lignes de codes et algorithmes mis en oeuvre est directe, et donc n'a pas à être précisé par un commentaire. Si, malgré cela, des commentaires sont nécessaires, c'est que l'algorithme en lui-même pose problème, et non pas son implémentation.
Les seuls cas ou je recours à des commentaires (ou du moins le devrais), c'est pour du code rendu incompréhensible suite à une optimisation, ou du code dépendant du système utilisé, comme pour la programmation des sockets, ou encore du multitâche, entre autres.
Bien sûr, il arrive parfois que j'ai du mal à comprendre mon propre code, mais cela ne me pousse pas pour autant à remettre en question ma manière de programmer (notamment en ce qui concerne l'absence de commentaires). Pour moi, cela signifie simplement que l'algorithme implémenté n'est pas bon, et ce qui me paraît alors obscure dans mon code me met généralement sur la piste d'un nouvel algorithme qui clarifie le code incriminé.
Mais cela m'arrive rarement de ne plus comprendre mon propre code, car, au moment même ou je l'écris, je le sens s'il risque de me poser ce genre de problème. Même si je le laisse à ce moment là en place, et même s'il est entièrement satisfaisant par ailleurs, ça ne cessera pas de me turlupiner jusqu'à ce que je trouve (cela prend des semaines parfois) et mets en place un autre algorithme qui me satisfasse.
Encore une fois, cette manière de procéder n'est possible qu'avec les outils adéquats mais également une grande discipline. A titre d'exemple, il n'y a pour ainsi dire pas de boucles 'for' dans mes sources, et je déporte tout groupe d'instructions pour lesquelles cela a un sens dans une fonction dédiée ce qui me contraint, et ce n'est pas toujours évident, à trouver des noms de fonctions explicites, et n'est-ce pas là, après tout, l'équivalent des commentaires qui devrait accompagner ces instructions si je les avais laissées dans la fonction appelante ? Cela facilite la lecture des fonctions que j'écris, puisque qu'elles ne comportent chacune que relativement peu d'instructions.
Puisqu'une comparaison a été faite entre musique et informatique, étant moi-même musicien et compositeur durant mes loisirs, je me permet d'en toucher quelques mots. Bien plus que les aspects purement techniques des programmes que j'écris, c'est la cohérence, l'harmonie, la beauté serais-je tenté de dire qui s'en dégagent du fait des algorithmes utilisés et de leurs enchaînements qui m'apportent le plus de satisfaction. Ce que je ressens en écrivant un logiciel dont je suis satisfait est comparable à ce que je ressens lorsque je compose une oeuvre musicale et constitue la principale motivation du fait que je m'adonne à ces deux activités. Et, comme vous pourrez le constater en vérifiant la date à laquelle il a été posté, ce message a été écris la veille du nouvel an, et je ne suis donc pas (encore) sous l'influence de substances plus ou moins licites, comme pourraient peut-être le penser certaines personnes à la lecture de ce dernier paragraphe (ou de ceux qui précèdent) ...

[iubito]

Et, comme vous pourrez le constater en vérifiant la date à laquelle il a été posté, ce message a été écris la veille du nouvel an, et je ne suis donc pas (encore) sous l'influence de substances plus ou moins licites, comme pourraient peut-être le penser certaines personnes à la lecture de ce dernier paragraphe (ou de ceux qui précèdent) ...

moi aussi !

non je tenais juste à préciser moi aussi c'est important

[sequentaire]

Je pense qu'il faut éviter d'être sectaire, et considérer la programmation spontanée - j'en fais sans savoir que cela s'appelle comme ça - est un des outils du programmeur.

Il m'arrive souvent de programmer en considérant que ce que j'écris est si clair que il n'y a pas besoin de mettre de commentaires. Mais je m'aperçois que, s'il s'écoule un grand moment entre deux séquences de travail, j'ai du mal à retrouver pourquoi j'avais écrit telle ou telle chose. L'algo reste clair, mais je ne me souviens plus à quoi il sert. Aussi, de plus en plus, je m'astreins à commenter le pourquoi, à expliquer le cadre, à donner les justifications de mes choix ; un peu le niveau guide, quoi.

Egalement, je crois que ce mode de programmation fonctionne mal lors des travaux en groupes. Certes le programme spontanée est clair, mais il ne l'est qu'après avoir été écrit ; hors, en programmation en groupe, il faut que ce soit clair avant.

Que l'on ait un flash d'une seconde ou de 15 mn, dans sa baignoire ou au bureau n'est pas le problème, le problème est qu'il faut être capable de l'expliquer à ses petits copains, que tout le monde ait compris la même chose, et que ce qui sera écrit corresponde réellement à ce qui a été expliqué et convenu. Le cas typique est une personne qui écrit l'algo, une autre qui écrit le test. Cela c'est difficile à faire sans outils périphériques tel UML, une méthodologie, et autre.

[iubito]

Pour ce qui est du terme jusqu'à ce matin je ne savais pas vraiment que ça existait.

Pour le travail en groupe, quand je vois ce qu'on a fait à l'IUT. 14 semaines sur un projet... les premières étapes de Merise ont été utiles (surtout celle pour dire les données et les tables!), certains modèle on les a juste fait pour faire plaisir à un des jury (l'otr' n'y comprenais rien ).

Au boulot, bon j'arrive sur un programme déjà existant qu'il faut améliorer. Il manque parfois de commentaire, mais quand y'a une base de données hyper complexe et une multitudes d'écrans... beaucoup de chose n'étaient pas prévues au départ (quand le collègue a commencé y'a 5 ans).

Comme schéma on a un enchaînement des écrans, et un MCD géant (en police taille 6 ) où il manque des tables

Après c'est des petits commentaires dans le code.
Quand j'ai une idée sur un détail, parfois je vais l'écrire en français avant l'algo, mais j'vais pas m'amuser l'écrire en UML ou Merise ailleurs.

Une méthode que j'avais trouvé assez sympa c'était la SADT, mais je suis tellement bordellique et illisible sur du papier, que j'préfère écrire en français un 'tit commentaire avant mon algo

[Admin]

J'ai l'impression d'etre dans la quatrième dimension !

Que vous puissiez avoir des "flashs" pourquoi pas, mais plus dans le contexte que florian à dicter, celui d'une longue réflection puis la solution apparait d'un coup, mais maintenant avoir juste le problème et le résoudre dans le seconde, désolé je peux pas y croire, ou alors c'est des problème de syntaxe....

Maintenant cela peut dépendre de l'application, quand j'etait plus jeune, je codais à l'arrache des petites applications, mais des que tu abordes des applications compliqués je vois mal comment tu peux faire.

essaye de me trouver l'algorithme le plus rapide pour le retournement d'une matrice par la méthode de Gauss en moins de 3 heures....

[Catbull]

essaye de me trouver l'algorithme le plus rapide pour le retournement d'une matrice par la méthode de Gauss en moins de 3 heures....

3H pour résoudre çà? Au vue de nez il leur faut 10800 fois moins de temps. Par contre ce qui risque d'être long c'est la venue du flash...

[iubito]

faut demander à Kodak pour le flash

eh bon les maths, et particulièrement les matrices, et moi ça fait 4 donc...

[sequentaire]

Les expériences de iubito sont très courantes. C'est typiquement dans ce contexte que la programmation spontanée est excellente.

La seule chose qui reste est effectivement l'effort personnel, spontané.

Pour le reste...

Et puis, au bout d'un certain temps dans ce ..., on recherche autre chose, même si on vit des expériences tout à fait passionnantes, amusantes, et hyper-formatrices. Dans ces ambiances le spontané se développe à toute allure, et c'est un moindre mal. On voit tout de suite quel spontané va dans le bon sens, et quel autre va dans le mauvais. Mon premier geste spontané, par exemple, avait été d'utiliser les variables globales... C'était si pratique !

Je pense que le coté positif de la méthode est la notion d'effort personnel, hors de tous outils, dans sa tête. Dans sa baignoire, quoi. C'est un outil ; l'ignorer est dommage.

[- Robby -]

La programmation spontanée ...
Pour moi, ca ne représente pas grand chose !
Waiii ... on a tous nos petits coups d'génie,
Wai ... la baignoire ... faut pas s'en priver, ca peut donner
des pti coups d'pouce, parfois ... ca arrive,
mais a part ca, ce sujet répond, pour moi, pil poil,
a celui qui se trouve 5 sujets plus bas ... et sic !

[iubito]

mais a part ca, ce sujet répond, pour moi, pil poil,
a celui qui se trouve 5 sujets plus bas ... et sic !

Le sujet en kestion est bidouilleur vs pro... là chui pas d'accord.
Mozart et Beethoven étaient-ils des bidouilleurs ? je pense pas.

Je me souviens plus des arguments exacte s avancés dans ce sujet là, et on ne vas pas refaire ce débat ici, mais ça me paraîtrait étonnant qu'un bidouilleur fasse des fonctions bien codées en PHP, des classes Java tip top, ou encore des sites respectueux des normes CSS.
La bidouille c'est du petit bricolage, rafistolage, la rustine pour cacher le bug...

[- Robby -]

Bein oui, justement .... suis d'accord avec toi !
La programmation spontanée ca aide pour de petits problèmes
ponctuels ... le "flash" sur un point précis, ca arrive a tous ca !
Le coup d'génie sur une problématique précise quoi !
mais a part ca, en ce qui concerne les structures plus complexes,
si on pousse le "spontané" ... ca devient vite du brol !
En fait, un beau programme, ce serait peut etre un ensemble de flash
organisés, hi !
Penses tu que Mozart n'avait nul besoin de structurer sa pensée
pour en "sortir" de la musique ... entre émotions et musique ...
il y a peut etre la partition, non ?

[epeios]

Et si l'un des secrets de la programmation spontanée résidait simplement dans le fait de découper un problème complexe en de multiples problèmes plus petits donc plus simples à résoudre ? Pour moi, un gros projet n'est qu'un ensemble de petits projets, que je mène à terme l'un après l'autre, comme s'il s'agissait de projets totalement indépendants les uns des autres.

[- Robby -]

Oui, mais alors je dirai, non pas de la "programmation" spontanée,
mais du "structuralisme" spontané .... La faculté intuitive de structurer
un problème complexe en ses composantes élémentaires.
Alors, ... je dis oui a l'idée de la "spontanéité" !
Mais ce que je viens de dire,heu ...
ca ne s'appelle pas simplement : "faculté de savoir programmer" ?
C'est pas "ca", simplement "savoir" programmer ???

[sequentaire]

Et si l'un des secrets de la programmation spontanée résidait simplement dans le fait de découper un problème complexe en de multiples problèmes plus petits donc plus simples à résoudre ? Pour moi, un gros projet n'est qu'un ensemble de petits projets, que je mène à terme l'un après l'autre, comme s'il s'agissait de projets totalement indépendants les uns des autres.

Je ne le pense pas. Un gros projet n'est pas que l'empilement de modules indépendants. Il y a tout un travail de suivi, de coordination, d'organisation. C'est là dessus que, à mon avis, la programmation spontanée est faible.

S'il suffisait que le niveau gros dise au niveau petit ce qu'il devait faire, on pourrait encore imaginer que le chef de projet donne ses directives à un programmeur, et que celui-ci se mette en état de programmation spontanée pour arriver au résultat.

Mais souvent, il y a le chemin inverse : que le programmeur dise au chef de projet ce que le projet doit faire. C'est peut être paradoxal, mais c'est une situation parfaitement courante. Et ce programmeur doit être capable de le dire avant d'avoir écrit le code, sinon cela devient totalement ingérable : le chef de projet aurait meilleur compte à changer de programmeur.

Bref, dans un gros projet, chacun doit se coordonner avec les autres. Comment le faire en programmation spontannée ?

[mat.M]

Et si l'un des secrets de la programmation spontanée résidait simplement dans le fait de découper un problème complexe en de multiples problèmes plus petits donc plus simples à résoudre ? Pour moi, un gros projet n'est qu'un ensemble de petits projets, que je mène à terme l'un après l'autre, comme s'il s'agissait de projets totalement indépendants les uns des autres.

C'est le but de l'analyse , mon cher Watson pardon epeios .
Et c'est ce que j'ai voulu montrer avec mon exemple précédent de construction de voiture ou assemblage de meccano.
Analyse= décomposition d'un problème complexe en petits problèmes plus simples à résoudre.
Bref le contraire de la synthèse..

Est-ce que ce n'est pas la le but du génie humain ?

[nyal]

Bonjour,

Il n'y a pas de programmatiion spontane. C'est quoi ce delire . Cependant, une personne peut avoir des faciliter dans un domaine de l'informatique pour resoudre un probleme. Et selon la personne, ca peut varier de la "seconde" a plusieurs jours. Je suis tout a fait d'accord. D'ailleurs cela se verifie tres souvent.

Mais pour des problemes bien complexe comme l'IA. Ou peu de chose existe. Meme si la personne a d'enorme facilite. Il lui faudra du temps avant d'avoir un "flash". Car le genie ca se travaille .

Sinon, je ne comprend pas bien l'histoire des commentaires dans le code. On ne commente pas le code mais l'algorithme. Et ca me semble tout a fait indispensable si l'algorithme est complexe. Ca evite des heures de lecture et reflexion a la personne lisant le programme.

Enfin, pour ceux qui ont des facilites, il ne faut pas faire l'erreur de ne pas commenter et discuter avec ses collegues. Car 2 points de vue en vaut mieux qu'un seul .