Discussion :

[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à

[HanLee]

Personnellement, je ne suis pas exactement d'accord sur ce point, on peut très bien la résoudre par récurrence sans même savoir ce qu'est la récursivité avec un exemple simple d'une tour de 3 étages en se rendant compte après essais (erreurs), observation, logique (et l'appui d'un pédagogue pour les non-autodidactes) que finalement on fait toujours la même chose:

1. Prendre le plus petit plateau excepté celui qu'on a déplacé en dernier et le déplacer à un emplacement valide
2. Reprendre au point 1

Ben j'ai bien parlé de récurrence non ? (d'un point de vue pratique, c'est un peu la même chose que la récursivité, et on a pas besoin de connaître la définition du mot pour l'utiliser)

[koala01]

Ben j'ai bien parlé de récurrence non ? (d'un point de vue pratique, c'est un peu la même chose que la récursivité, et on a pas besoin de connaître la définition du mot pour l'utiliser)

Tout à fait d'accord, mais, si la récurisvité (en terme de programmation) a si mauvaise réputation, c'est principalement parce que les gens ont du mal à concevoir une manière cohérente d'en sortir.

Il y a, bien sur, les restrictions "purement matérielles" qui sont susceptibles de venir "foutre le bordel", mais elles seront d'autant plus vite atteintes si, à la base, le développeur ne trouve pas le moyen d'en sortir de manière plus ou moins cohérente ou élégante.

C'est un phénomène que l'on rencontre également lorsqu'il s'agit de gérer des ruptures: si beaucoup de développeurs aiment autant "laisser ce genre de travail à un autre", c'est parce qu'ils ne dispose simplement pas d'une approche leur permettant d'y réfléchir de manière sereine.

Or, dans ces deux cas, il "suffit" de donner une "théorie" finalement toute bête ( ex: testez le cas de base pour la récurivité, le reste de la logique tendant vers ce cas de base) pour que la conception d'un algorithme permettant de résoudre un problème ne semble pas plus difficile que la simple utilisation d'une boucle ou d'un test

C'est ce genre de théorie que je considère comme important d'expliquer au débutant avant de s'attaquer à un langage donné

[valAa]

Très intéressant ce débat.
Je réagis après avoir lu les 7 pages d'un coup, de manière un peu générale.

Si la position de koala01 me paraît séduisante et bien argumentée, je n'arrive pas à y adhérer totalement, de par mon vécu probablement.

La théorie telle qu'on la définit ici, est en effet nécessaire pour bien coder.
Sa maitrise et son apprentissage nécessitent par contre un effort d'abstraction considérable (penser "comme un processeur", pour un être humain, c'est une abstraction. Je ne suis pas un processeur), voire gigantesque.

J'arrive à concevoir ça dans le cadre d'un enseignement traditionnel, avec un (bon, tant qu'à faire) professeur. Le professeur est alors là pour aider l'étudiant à faire cette abstraction, en matérialisant le concept - c'est à dire en l'humanisant - par l'humour, par des exemples, en répondant à ses questions, etc.
Et encore. L'instit' qui n'a pas besoin de bonbons, crayons ou autre objet matériel pour apprendre une addition à ses gamins existe-t-il ?

Lorsqu'on apprend dans les bouquins, le problème se pose différemment. Un bouquin n'a de réponses qu'aux questions que l'auteur a posé. Pour répondre aux autres, l'étudiant se retrouve seul face à sa capacité d'abstraction.
Lorsque celle-ci est dépassée (ce qui arrive vite quand on débute), à qui poser ses questions alors qu'on est seul entre son bouquin et son processeur ? À son processeur. Comment les poser ? En utilisant un langage de programmation.

Est-il nécessaire de préciser que mon apprentissage de l'informatique s'est fait dans les bouquins ?

[Chessmaster1966]

Je vais tenter de donner mon avis sur la question initiale, bien que je n'ai que survolé les autres posts sur le sujet.

J'ai l'impression qu'il y a eu un glissement sur la question. Au début, c'était :
Lors de l'apprentissage, faut-il commencer par la théorie ou par la pratique ?
Mais beaucoup de post que j'ai pu lire étaient plus orientés :
Lorsqu'on est confronté à un nouveau problème, faut-il commencer par une phase de réflexion ou par sa réalisation ?

Je pense que ces questions appellent des réponses différentes. Et pour la première, je dirais : Commencer par la pratique, sans hésiter.

Pourquoi ? Principalement pour deux raison :
Déjà, la théorie, c'est un peu le mythe de Sisyphe, on croit aborder la théorie, on pousse sa pierre, pour finalement se rendre compte en arrivant en haut qu'on ne faisait que mettre en pratique une autre théorie sous-jacente, et on recommence. Appliquer en C++, la théorie sur les langages informatiques nous entraîne vers l'informatique formelle d'un côté, vers l'électronique numérique de l'autre. Faire de la théorie sur l'électronique numérique nous entraînera vers la physique du solide, la physique statistique... Commencer par la théorie me semble impossible à mettre en œuvre pour cette raison théorique.

Et surtout, parce que la théorie est bien plus abstraite et complexe, et que si on n'a pas déjà une certaine compréhension intuitive des concepts manipulés auxquels se raccrocher, le risque d'être submergé est très grand. Je vais prendre quelques exemples :

On a tous commencé les math par apprendre à compter, puis par apprendre à faire des opérations. L'algèbre de Peano vient bien après (et pour beaucoup, elle ne vient même jamais). Et je ne pense pas qu'il soit possible de voir où l'on va avec l'algèbre de Peano si on n'a pas en tête que quelque part, ça sert à définir ce qu'est 3 et ce que signifie 2 + 3.

Quand on étudie une langue vivante, on commence toujours (sauf si on fait de la linguistique, mais c'est une contexte différent) par apprendre plus ou moins par cœur quelques textes basique où l'on apprend à dire bonjour (une sorte de Hello world! ), on étend autour de ces exemples simples, puis seulement après, quand on a un minimum de vocabulaire, on commence à nous parler de la structure grammaticale de la langue en question, et de ses règles de conjugaison, déclinaisons...

Un exemple plus proche de l'informatique : Dans mon école d'ingénieur, à mon époque, on avait un cours de génie logiciel en première année. J'avais déjà fait de la programmation avant, je m'étais déjà cassé les dents sur un programme de plus de 100 lignes, j'ai trouvé ce cours intéressant, il posait les bons concepts. J'en ai discuté avec pas mal d'amis qui n'avaient pas cette expérience préalable, l'avis était unanime : Le cours était simplement pour eux imbattable, incompréhensible et inutile. A tel point qu'ils ont réussi à le faire supprimer de l'enseignement. Il était pour moi simplement mal placé.

Il y a une image que j'aime beaucoup dans le dernier Stroustrup, qui prend à contre pied une idée pré-construite, qui est de dire qu'il faut apprendre à marcher avant d'apprendre à courir. Il fait remarquer que quand on regarde un bébé, il commence par savoir courir (en tombant régulièrement, bien entendu, mais ce n'est pas grave), avant d'apprendre la maîtrise fine et subtile des ses mouvements nécessaire pour marcher.

Je pense qu'en C++, c'est un peu pareil, il faut commencer par des programmes simples, des aspects bassement techniques qui passent par la syntaxe ou la manière de compiler son code. Une fois ces bases apprises, il faut laisser le temps de jouer un peu avec ces programmes simple, en faire des un peu plus complexes, laisser l'étudiant écrire du code spaghetti, lui demander de faire une modification dans son code, le laisser en baver un peu.

Comme ça, quand on lui présentera enfin des outils qui lui permettent d'organiser le code, le principe open-closed, il saura quels sont les enjeux derrière, et il aura la motivation et les prérequis nécessaires pour passer aux aspects plus théoriques.

Pour prendre un ultime exemple, les règles du C++ pour séparer son code en plusieurs fichiers sont, il faut bien l'avouer, tordues, mal faites, antédiluviennes. Pourtant, j'ai vécu leur découverte comme une vraie libération, car j'avais du bosser avec du relativement gros code mono-fichier auparavant. Et à cette époque, je savais déjà (approximativement) la différence entre déclaration et définition, et les notions de classe, fonctions, variables. Du coup, avec la motivation et le bagage nécessaire, je n'ai pas eu de problèmes pour les apprendre, et comprendre ce qui les motivait.

Attention, quand je plaide pour la pratique en premier, je ne plaide pas du tout pour la pratique uniquement ! La théorie est nécessaire à un moment ou à un autre, et la pratique seule ne peut pas permettre de prétendre à une maîtrise suffisante du sujet. Simplement, pour moi, elle vient en second, chronologiquement parlant.

C'est ce que je voulais dire au sujet de la pratique pour apprendre le C++ ou tout autre langage. Il faut écrire et écrire (sans algo) pour mieux être confronté aux problèmes et effectivement on peut perdre beaucoup de temps et de patience mais c'est très formateur et je confirme ce que je dis il suffit de prendre des livres cur le C++ pour s'appercevoir qu'il n'est jamais question d'algorithmique. Cela vient bien plus tard !!!

Donc je ne peux que être entièrement d'accord avec ce que tu as dis!!!!