Discussion :

[Cyrano]

Salut tout le monde,

Et je suis personnellement très coulant quant à l'acception du terme conception: dans bien des cas, le simple fait de se "poser cinq minutes", le temps de boire un café ou de fumer une cigarette (ou une pipe, comme Pierre ) en réfléchissant aux besoins que l'on peut rencontrer peut s'avérer suffisant (sous réserve des problèmes de communication que cela peut engendrer )

Je crois que cette phrase résume fort bien le problème global.

Personnellement, je ne programme ni en C ni en C++, je développe en PHP et je suis complètement autodidacte en la matière. Le premier programme que j'ai écrit, j'ai commencé par le concevoir avec une feuille de papier et un stylo, créant, sans le savoir à l'époque, un algorithme.
Ce que je veux illustrer ici, c'est que ce que nous savons sans forcément l'exprimer, c'est qu'un développement bien fait, c'est d'abord entre 50 et 70% d'analyse.

La programmation, ce n'est pas compliqué, c'est nous (humains) qui sommes compliqués. J'explique à des personnes non informaticiennes qu'elles font de la programmation au quotidien sans le savoir en leur citant un petit exemple bête quoique très parlant. Si je veux faire des frites, je vais me poser certaines questions. La toute première, c'est « Ai-je des patates ?» : pourquoi cette question ? Parce qu'elle n'a que deux réponses possibles, oui ou non. Si c'est non, va pour une boite de petits pois, sinon, question suivante. En fait, on part d'un problème complexe qu'on atomise en questions à réponses binaires.
La difficulté du programmeur, c'est de ralentir le rythme cérébral pour isoler toutes ces questions afin de les transformer en code quel que puisse être le langage.

Donc l'apprentissage de la programmation, ça doit passer d'abord par l'apprentissage de l'analyse. Après ces bases fondamentales on peut intégrer l'apprentissage des langages et des méthodologies : POO, Design patterns et autres éléments qui viendront enrichir les compétences du développeur. La toute première des bonnes pratiques, je crois que ça reste (et ça restera toujours) la logique.

[pseudocode]

Un simple exemple : C++ autorise explicitement le fait d'avoir 65 000 caractères sur une seule ligne de code (c'est un des "minimum" assurés dans une des appendice de la norme).

Pourtant, je serais surpris de croiser un seul développeur (tous langages confondus) qui soit prêt à accepter une telle situation.
Le problème, c'est que si tu apprends une limitation comme étant la règle générale, tu auras énormément de mal à "changer ton fusil d'épaule" lorsque quelqu'un viendra avec... la règle générale.

Hum... Je n'ai jamais dit que les limitations d'un langage étaient les seules règles a appliquer. J'ai parlé de "bonnes pratiques" : la longueur d'une ligne ou d'un source en fait partie... et je ne pense pas que la bonne pratique dans ce cas est d'aller aux limites absolues.

Or, lorsque l'on apprend la théorie "parce que cela colle avec ce que l'on veut apprendre du langage", on apprend généralement... la théorie "adaptée" au langage envisagé.

Aucun javaiste n'aurait l'idée d'envisager un héritage multiple, simplement, parce que... c'est interdit en java.

Et pourtant, il n'y a rien qui interdise l'héritage multiple dans la théorie OO

Bah, c'est plutot en accord avec mon raisonnement alors. Connaitre *seulement* la théorie OO ne t'aidera pas a comprendre pourquoi tu ne peux pas coder un héritage multiple en Java.

Tu sembles oublier que "le programme qui marche" n'est jamais que la toute dernière étape d'un processus beaucoup plus long, qui commence par l'analyse des besoins et qui continue... en se posant la question de savoir comment apporter une solution correcte et cohérente à ces besoins.

Cela signifierait-il pour toi que la "conception" fait partie de la théorie ? Auquel cas je comprends mieux ton raisonnement.

Pour moi ce n'est pas le cas. L'analyse, la conception sont des disciplines tout comme le sont l'implémentation ou le test. Ces disciplines sont donc soumises la meme bivalence théorie/pratique.

Tu peux connaitre la théorie de l'analyse objet/systémique/sémantique/....
Tu peux connaitre la pratique de ces méthodes d'analyses

Mon avis étant que le choix le plus pragmatique est de ne pas s'embêter avec la théorie pure, et de ne pas foncer à l'aveugle non plus. C'est pour cela que, pour moi, les bonnes pratiques sont un cadre formel suffisant pour garantir l'accomplissement de tâches dans une discipline.

Par exemple, concevoir une BdD en respectant la 3NF est une bonne pratique. Dans la plupart des cas (par exemple un site php+mysql) , savoir le pourquoi du comment de la théorie relative a cette pratique ne servira pas à concevoir un meilleur programme.

Personnellement, je ne connais personne qui maitrise la "théorie" de toute la chaine des disciplines nécessaires à la réalisation d'un projet (depuis l'étude d'opportunité jusqu'au CRM). Ça n'empeche pas d'avoir des personnes qui mènent des projets à terme... heureusement.

[epsilon68]

Une chose à dire : C'est en forgeant qu'on devient forgeron.

Pour moi pratique et théorie vont ensemble, c'est une perte de temps à mon sens d'écrire sur un bout de papier une utilisation de patterns, de POO et autres concepts alors qu'on peut le coder directement.

Alors oui la théorie c'est bien, mais sans la pratique c'est pisser dans un violon.

entierement d'accord, j'ai appris en faisant des "methodes numeriques" en C,
c'etait super. le C++ est venu par apres et j'en ai vu les avantages.

[koala01]

entierement d'accord, j'ai appris en faisant des "methodes numeriques" en C,
c'etait super. le C++ est venu par apres et j'en ai vu les avantages.

Oui, mais, à coté de cela, tu as sans doutes (allez, disons plutôt peut-être ) perdu énormément de temps à chercher le moyen de faire certaines choses que les connaissances théoriques t'auraient clairement facilitées.

Le problème, lorsque l'on n'a même jamais entendu un terme que la théorie explique, c'est que... l'on ne sait même pas ce que l'on doit chercher, ce qui ne facilite pas vraiment la recherche d'une solution, et qui occasionne, de facto, une perte de temps considérable.

Si tu avais eu la théorie avant de te trouver dans une situation dans laquelle tu en as besoin "en extrême urgence" (la plupart des développements doivent être faits "pour hier" ), tu aurais sans doute gagné plusieurs heures en pouvant te consacrer "au noeud du problème" plutôt qu'à la recherche de "la notion manquante"

[epsilon68]

Oui, mais, à coté de cela, tu as sans doutes (allez, disons plutôt peut-être ) perdu énormément de temps à chercher le moyen de faire certaines choses que les connaissances théoriques t'auraient clairement facilitées.

la theorie dans les methodes numeriques, c'est un algo non?
bein l'implementer sert à voir pourquoi c'est lent, a le tester, le debugger etc

si tu parles de la theorie des languages, la theorie de la compilation, etc,
bein oui c'est bien, l'appliquer c'est super mieux.
Dans mes cours de compilation, combien de gens ont souffler en disant que ca servait à rien. On ne comprend pas non plus bien le LALR(1) mais bon on l'accepte. Quand tu prends Bison/Flex, la c'est cool et ca te permet de bien mieux suivre et comprendre les cours theoriques.

[koala01]

Ce que tu décris ressemble plus à de la conceptualisation que de la théorie, auquel cas je suis d'accord.

Le terme théorie est effectivement peut être mal choisi, mais je crois que le terme "conceptualisation" n'est pas plus adapté car... trop restrictif.

Une grosse part de ce que je plaide que les débutants apprenne tient, effectivement, de concepts, mais cela va néanmoins un peu plus loin dans le sens où il me semble intéressant qu'il connaissent aussi une ou plusieurs manière de représenter un algorithme:

Je ne parle pas du flow chart, qui n'est pas adapté à la programmation structurée, si ce n'est pour l'ASM, ni du pseudo code car je suis effectivement d'accord avec le fait que, si c'est pour écrire du "faux code", autant en écrire tout de suite du vrai

Mais je parle en revanche du nassi-schneiderman, malgré tout le mal que certains peuvent en penser ou du Jackson qui est particulièrement intéressant lorsqu'il s'agit de "déblayer le terrain" pour une gestion de ruptures, par exemple.

Le tout sans oublier la "règle de base" pour la récursivité : "toujours tester le cas de base"

Je peux t'assurer que la mise au point d'un algorithme cohérent avant de se lancer sur le clavier n'est jamais une perte de temps:

A partir du moment où tu utilise "la bonne méthode" (j'aime particulièrement le nassi-schneiderman, parce qu'il permet de représenter l'ensemble des concepts utilisés en programmation strucutrée séquentielle ) pour le représenter et que tu as déjà vérifié qu'il était correct (en "jouant" à te faire "aussi bête qu'un processeur"), je peux te garantir:

1. que la traduction en code source est automatique (j'ai même un projet en cours qui tend à permettre à l'ordinateur de générer du code source automatiquement sur base d'une logique introduite par l'utilisateur )
2. que la première compilation réussie (comprend: après avoir viré les inévitables fautes d'attention) permettra d'obtenir le résultat attendu.

Tu gagnera donc énormément de temps à l'étape qui t'en fait classiquement perdre le plus: le débuggage, et la phase de tests unitaires se transformera en "pure formalité" dans le sens où elle ne te servira plus qu'à vérifier que tous les aspects ont été pris en compte

Ca, c'est pour la partie "séquentielle" des différents langages.

Lorsque l'on aborde un langage OO, il me semble opportun d'y ajouter quelque concepts (composition Vs agrégation, héritage, polymorphisme, substituabilité, etc), quelques règles / principes ou loi (parmis lesquels Demeter et Liskov) et, si possible, une "méthode quelconque" permettant de représenter les relations entre les différents types d'objet (hein , quoi j'ai parlé d'UML )

Le fait est que, tôt ou tard, il seront confrontés au besoin de "garder une trace" de leurs algorithme ou des relations qui existent entre leurs classes, voire, même, qu'il devront pouvoir... communiquer sur le sujet avec d'autres personnes (soit parce que ces personnes leur transmettent justement des algorithme ou des diagrammes de classes, soit pour permettre aux gens de "savoir ce qui est fait")

Mais comme cet ensemble de "règles" (le mot est un peu fort, mais je n'en trouve pas d'autres ) ne pourra que les aider à assurer une qualité supplémentaire dans leurs développements futurs, autant les leur donner "le plus tôt possible"

Nous sommes bien d'accord sur le fait que cette prose ne vaut que pour ceux qui envisagent d'apprendre... un langage de programmation, indépendamment des autres disciplines envisageables, pour lesquels on trouve aussi une série de "choses" qu'il est intéressant de connaitre indépendamment de la technologie utilisée

la theorie dans les methodes numeriques, c'est un algo non?
bein l'implementer sert à voir pourquoi c'est lent, a le tester, le debugger etc

Mais, avant de l'implémenter, il faut... le créer (ou le copier)...

Je te renvoies à ma prose qui suit une réponse à white_tentacle il y a quelques messages: il ne faut pas donner plus de pouvoir au langage ou au compilateur qu'ils n'en ont réellement

si tu parles de la theorie des languages, la theorie de la compilation, etc,
bein oui c'est bien, l'appliquer c'est super mieux.

Dans mes cours de compilation, combien de gens ont souffler en disant que ca servait à rien. On ne comprend pas non plus bien le LALR(1) mais bon on l'accepte. Quand tu prends Bison/Flex, la c'est cool et ca te permet de bien mieux suivre et comprendre les cours theoriques.

La théorie des langages et de la compilation est, certes très intéressante (du moins pour ceux qu'elle intéresse), mais, effectivement, totalement inutile pour qui n'utilisera jamais bison et flex (ou outils similaires)

Il ne sera jamais mauvais d'expliquer les différentes étapes que suit un compilateur, mais cela rentre beaucoup plus dans le cadre de... l'apprentissage du langage et, quoi qu'il en soit, ca rentre souvent dans la catégorie de "la culture générale, pour mémoire"

Je le répète, je ne dit absolument pas qu'il faut assommer l'étudiant avec l'ensemble de la théorie se rapportant de près ou de loin (et surtout de loin, d'ailleurs ) aux langages de programmation: cela deviendrait rapidement barbant et n'aurait aucun intérêt.

Je l'ai déjà dit, il ne sert à rien d'arriver avec les algorithmes de tri à bulles, de tri par insertion, de A* et de dijkstra ou avec les différents DP existants et d'assommer l'étudiant avec...

Par contre, comme le but de l'apprentissage de ces pré requis est, justement, de lui "apprendre à réfléchir" et que la meilleure manière d'y arriver est, encore, de le "bombarder d'exercices", il est des plus intéressant de le mettre face à des situations qui le mèneront à... les découvrir par lui-même (juste avant de lui dire le nom de l'algorithme ou du DP )

Ce en faveur de quoi je plaide, c'est que l'on apprenne à l'étudiant à réfléchir à la logique qu'il veut transmettre à l'ordinateur grâce à n'importe quel langage.

Je plaide pour qu'il finisse par réfléchir de manière systématique à

je pars de tel point et je veux arriver à tel autre point :
1- De quelles (structures de) données ai-je besoin
2- Quelle logique me permettra d'obtenir le résultat escompté en limitant au mieux les risques d'erreur

A partir du moment où il a pris l'habitude de se poser la question et, surtout, d'y apporter une réponse "estimée correcte", l'apprentissage d'un langage se fait finalement beaucoup plus simplement et peut se limiter à:

• quelques règles de grammaire et de syntaxe
• quelques mots clé
• quelques particularité du langage
• quelques fonctions existantes dans le langage

[susanoo]

J'ai toujours pensé que l'algorithme est la base de tout.En effet, il faut d'abord avoir la solution au problème à résoudre avant de programmer.L'algorithme pourra ensuite être traduit dans le langage de choix du developpeur.
Selon moi, en théorie, on pourrait traduire un algorithme dans tous les langages de programmation existant. Le seul problème restera les limites d'un langage par rapport à un autre pour exprimer tel ou tel aspect de l'algorithme.
On doit donc rechercher un langage qui permette de faire tel ou tel chose en fonction des besoins de l'algorithme. Un peu comme ces mots anglais qui n'ont pas d'équvalent en français (traduction) mais qui une fois définit se comprennent tout de même -c'est juste qu'il n'existe pas de mots en français pour traduire le même concept-
De même, avant de comprendre un langage de programmation objet, il faut comprendre le concept objet.Une fois le concept maîtriser, on pourra utiliser n'importe quel langage OO pour l'implémentation.
Toute fois, il y'a des concepts qui s'expliquent difficilement, et qu'on comprend facilement après en avoir vu un exemple ie après un peu de pratique. Il faut noter dans ce cas qu'on apprend donc en regardant l'autre faire, mais justement celà ne constitue t'il pas la phase théorique, la phase pratique intervenant au moment où l'on s'y met soit même?

[JolyLoic]

J'ai toujours pensé que l'algorithme est la base de tout.

Je dirais une des bases de tout. Pour programmer, il y a pour moi au moins besoin d'avoir 4 bases :
- L'algorithmie,
- Le génie logiciel (organisation de code, la POO en est simplement un aspect),
- La syntaxe du langage utilisé,
- Une certaine connaissance du domaine du problème.

Il y a un grand nombre de lignes de code (au pif 80%) dans les programmes que je fais où les algorithmes sont triviaux, et ne méritent pas qu'on leur accorde la moindre attention spécifique. Et il y a même des développeurs (par exemple dans ce qui est lié à l'IHM) qui sont avant tout des assembleurs et qui ne voient jamais le moindre véritable algorithme de leur vie.

[koala01]

Je dirais une des bases de tout. Pour programmer, il y a pour moi au moins besoin d'avoir 4 bases :
- L'algorithmie,
- Le génie logiciel (organisation de code, la POO en est simplement un aspect),
- La syntaxe du langage utilisé,
- Une certaine connaissance du domaine du problème.

Je ne sais pas s'il était voulu de ta part de placer ces bases dans cet ordre particulier, mais de mon point de vue, ce sont effectivement les quatre bases nécessaires, et il faut les apprendre... dans cet ordre précis.

Quand elle est nécessaire (comprend: dés qu'il faut faire autre chose que de monter un mur avec les briques faites par d'autre), l'algorithmie sera absolument nécessaire avant de pouvoir passer à la deuxième étape qui est le génie logiciel.

De même, je trouve que la syntaxe du langage utilisé ne sera utile qu'une fois le génie logiciel plus ou moins maitrisé, car:

• Si on apprend à créer une classe sans savoir de quoi il retourne ni pourquoi le faire, cela ne sert finalement pas à grand chose.
• Ou, si on accorde trop d'importance à la syntaxe d'un langage particulier, on devra pour ainsi dire "tout reprendre à zero" si, d'aventure, on décide de se tourner vers un langage équivalent (en terme de possibilités et de concepts utilisés) mais présentant une syntaxe trop différente.

Il y a un grand nombre de lignes de code (au pif 80%) dans les programmes que je fais où les algorithmes sont triviaux, et ne méritent pas qu'on leur accorde la moindre attention spécifique.

C'est vrai lorsque l'on a déjà été mis en présence de suffisamment de cas pour se rendre compte que ces algorithmes sont triviaux, je ne dis absolument pas le contraire.

Par contre, si tu te remet dans le cadre d'un débutant qui est confronté à un problème pourtant trivial pour la première fois, le problème n'a pas l'air si trivial pour lui

Tu as donc deux solutions: soit, "un bon samaritain" lui donne l'algorithme "tout fait" en lui disant "cet algorithme s'appelle XXX, c'est lui que tu dois utiliser", soit le débutant doit réfléchir "de lui-même" à la logique à mettre en oeuvre, car, comment trouver, même sur internet, une information dont on ignore tout

Si on n'a pas déjà appris au débutant à réfléchir à la logique, à être attentifs à certains points particuliers, il ne sera sans doute pas en mesure de donner un résultat correct autrement que par... essais (et échecs) successifs, en ne sachant à la limite pas ce qu'il essaye d'une fois à l'autre.

Et il y a même des développeurs (par exemple dans ce qui est lié à l'IHM) qui sont avant tout des assembleurs et qui ne voient jamais le moindre véritable algorithme de leur vie.

Tout à fait...

Mais là, nous arrivons dans une situation réellement particulière

[kiluak]

Hello,

My two cents :
J'aime bien le post de JolyLoic que je trouve vraiment éclairé (sans vouloir lécher les bottes de qui que ce soit ) !

Par contre, j'ai peut être raté quelque chose, mais il me semble que quelque chose a été négligé le long de ce fil : le facteur "plaisir".
Je sais pas vous, mais quand j'ai commencé à bidouiller du basic sur une relique dont je me rappelle plus du nom, j'aurais pas aimé qu'on vienne m'embêter avec de la "théorie"! Je me rappelle encore le jour ou j'ai découvert à quoi servait le fameux mot clef "else", découvrir qu'on pouvait faire des boucles sans pour autant avoir une "théorie" qui va mettre un nom sur ce concept de boucle (il ne m'est pas venu à l'esprit d'appeler ça "boucle" par moi même).
Découvrir par soi même le fonctionnement de la bête, et à force de curiosité, arriver à faire un programme qui compte jusqu'à l'infini sans aucune intervention extérieure. Je ne pense pas que j'aurais pris autant de plaisir à voir tourner mes premiers programmes si j'avais auparavant lu des tas de trucs sur comment faire ci ou ça, je me serais senti moins "auteur/pionnier".

Surtout, je pense que partir de la théorie est trop restreignant pour nous permettre de nous "exprimer" librement lors de la phase d'apprentissage.
Faisons le parallèle avec le vélo. Quand j'ai commencé à en faire petit, j'en avais strictement rien à faire du "pourquoi ça marche", ce que je voulais c'était juste rouler! Ca ne m'a pas empêcher de me poser des questions plus tard!


Puisqu'il a été fait référence à l'axiomatique de Peano, j'aimerais faire un autre parallèle avec les mathématiques, ou le terme "théorie" prend toute son ampleur. (attention, grosse digression)

Ayant à la base un master en maths fondamentales, une chose a été récurrente pendant mon cursus, c'est l'approche "faisons de la théorie, et étudions ensuite des cas particuliers". Cette approche, je n'en avais pas eu conscience, jusqu'à ce que je lise le cours d'analyse fonctionnelle de John Conway (l'inventeur du jeu de la vie et de tout plein d'autres choses ), ou il dit dans son intro qu'il va adopter l'approche inverse... hé bien je dois dire que j'ai été bluffé du début à la fin : une approche simplifiée permet d'arriver beaucoup plus vite à la compréhension globale.

Un des exemples qui m'a marqué, si vous me suivez encore : dans 99% des cursus mathématiques, un jour on voit les espaces de Banach et leurs définitions et caractérisations qui ne font pas tellement plaisir à tout le monde. Et ensuite, on vous parle des espaces de Hilbert en vous présentant ça comme "des espaces de Banach dont la norme est donnée par un produit scalaire". Et là, on est perdus à jamais dans le néant. Et puis un beau jour, on se rend compte que les espaces de Hilbert, c'est ce qu'il y a de plus simple, c'est en fait ce qu'on manipulait depuis la seconde quand on fait des calculs de distances, ni plus, ni moins.

Tout ce "brouillard" apporté par la théorie vient du fait qu'on a mis des concepts sur certaines choses, mais qu'en fait, on aurait pu et du s'en passer lors de notre apprentissage. Ensuite, bien sur, on est content d'avoir ces concepts plus généraux, mais qui auraient pu être présentés dans le sens normal des choses.
Pour en finir avec cette digression (désolé pour le HS), dans n'importe quelle théorie existante, regardez le parcours de leurs géniaux inventeurs : ils sont partis du plus simple pour **ensuite** généraliser. Peut-être que c'est pour ça qu'ils étaient géniaux ? . Mais pourquoi généraliser ? A la base c'était pour résoudre des problèmes plus difficiles. Question : est-ce qu'un débutant à le besoin immédiat de résoudre des problèmes "difficiles" ? C'est contre nature, non ?

Laissons à chacun apprendre de la façon qui lui fait le plus plaisir (et si il a envie, qu'il commence par lire la fameuse thèse de Church si ça lui fait plaisir !). Bien évidemment, si il veut travailler avec d'autres personnes, il faudra bien qu'il s'informe un jour ou l'autre sur les "bonnes pratiques", et si un jour il bute sur un problème, il prendra aussi du plaisir à apprendre ce qui a déjà été fait, ce qui passera peut-être par une abstraction théorique quelconque (je pense notamment à la théorie de la complexité)

Je suppose que la plupart des gens sur ce forums sont des passionnées quelque part, et que sans le plaisir que nous prenons à dompter nos machines, nous ne serions pas là