[Débat] Apprendre la théorie avant la pratique: une bonne chose ?

Le , par koala01, Expert éminent sénior
Cette discussion issue de Apprendre le C & C++, un bon choix ?


Salut,

Si je pouvais te donner un conseil, ce serait d'apprendre en priorité les "base communes", les "principes généraux" que l'on retrouve dans strictement tous les langages: les principes de l'algorithmique et de la programmation structurée d'une part, les principes de la programmation orientée objet d'autre part(même si ces derniers ne s'appliquent pas à tous les langages).

Il ne faut, en effet, pas donner plus de pouvoir aux langages qu'ils n'en ont réellement: ce ne sont que des outils qui permettent d'indiquer à "quelque chose d'aussi bête qu'un ordinateur" ce que l'on attend d'eux.

Seulement, avant de vouloir essayer de faire comprendre à un ordinateur ce que l'on attend de lui, il faut... savoir exactement ce que l'on attend qu'il fasse et dans quel ordre.

Ce n'est qu'une fois que l'on sait clairement et précisément (ou du moins "de manière aussi précise que possible") ce que l'on attend de l'ordinateur qu'il faut faire intervenir un langage de programmation pour le lui indiquer, et le travail se limite alors souvent à un "long et fastidieux travail de dactylographie" (bon, d'accord, j'exagère un peu sur ce point )

Lorsque l'on respecte cet ordre d'apprentissage et de développement avant l'écriture du code, on se donne l'occasion de rendre sa vraie place aux langages de programmation, ils semblent directement beaucoup moins complexes, et l'on passe beaucoup moins longtemps à s'arracher les cheveux en se demandant "pourquoi il ne fait pas ce que je veux".

Ceci dit, je confirme ce qui a déjà été dit par ailleurs: C et C++ sont effectivement des langages fort proches, et s'il est possible que tu sois, à cause de la quantité de code existant, confronté à des situation dans lesquelles ton rencontrera peut être du code C dans du code C++, il est bon et préférable d'apprendre ces langages séparément.

A l'extrême limite, j'en arriverais volontiers à conseiller d'apprendre C++ avant C, histoire de ne pas prendre des "mauvaises habitudes" qui passent pourtant en C pour "des règles de bonnes pratiques" lors de l'apprentissage de C.

Je ne crois personnellement pas qu'il ne vaille pas la peine d'apprendre C, car c'est un langage qui est à l'heure actuelle encore largement utilisé, même si c'est peut être dans des secteurs "de niche".

Par contre, je suis catégorique sur le fait que la connaissance de C n'est nullement un prérequis à l'apprentissage de C++


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de susanoo susanoo - Membre du Club http://www.developpez.com
le 22/08/2010 à 0:38
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?
Avatar de Aleph69 Aleph69 - Membre expérimenté http://www.developpez.com
le 22/08/2010 à 3:35
Bonsoir,

</HS>

Citation Envoyé par Davidbrcz  Voir le message
Une matrice c'est un tableau de nombre avec des opérations dessus. Point.



Citation Envoyé par Flob90  Voir le message
Un ensemble de matrices et un ensemble d'application linéaires sont isomorphe en posant las bases adéquates, mais ce sont bien deux ensembles distincts d'entités mathématiques qui existent par eux-même sans lien immédiat (sans définir de bases impossible de passer de l'un à l'autre

En fait, si je comprends bien, tu distingues une application linéaire et sa matrice.
C'est effectivement comme cela qu'on l'enseigne et c'est très bien comme cela.
Sur ce point, je suis tout à fait d'accord avec toi.

Ceci dit, tu peux tout de même dire qu'une matrice est une application linéaire.
Soient un corps K, un K-espace vectoriel E de dimension finie n.
Pour deux vecteurs u et v de E, une matrice A de K^(nxn), un scalaire lambda de K, on a
A*(u+lambda*v) = A*u+lambda*A*v.
Autrement dit, A est une application linéaire de E dans Im(A).

Bien sûr, derrière tout cela, comme tu fais bien de le noter, se cache la notion d'isomorphisme.
Et comme tu le sais sûrement, on identifie entre eux les espaces qui sont isomorphes les uns aux autres.
En passant, la propriété d'isomorphisme entre deux espaces finis est indépendante du choix des bases.

Citation Envoyé par Flob90  Voir le message
donc dire "les matrices sont des applications linéaires" est, AMHA, un peu fort.

Non, c'est juste trop fort!

</HS>
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur http://www.developpez.com
le 22/08/2010 à 10:27
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.
Avatar de Aleph69 Aleph69 - Membre expérimenté http://www.developpez.com
le 22/08/2010 à 10:33
Totalement d'accord!
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur http://www.developpez.com
le 22/08/2010 à 10:33
Citation Envoyé par susanoo  Voir le message
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.
Avatar de koala01 koala01 - Expert éminent sénior http://www.developpez.com
le 22/08/2010 à 12:50
Citation Envoyé par JolyLoic  Voir le message
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
Avatar de kiluak kiluak - Membre régulier http://www.developpez.com
le 22/08/2010 à 19:50
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à
Avatar de HanLee HanLee - Membre éclairé http://www.developpez.com
le 22/08/2010 à 20:26
Citation Envoyé par Sehnsucht  Voir le message
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)
Avatar de koala01 koala01 - Expert éminent sénior http://www.developpez.com
le 23/08/2010 à 14:41
Citation Envoyé par HanLee  Voir le message
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é
Avatar de valAa valAa - Membre actif http://www.developpez.com
le 23/08/2010 à 18:28
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 ?
Avatar de Chessmaster1966 Chessmaster1966 - Membre régulier http://www.developpez.com
le 30/08/2010 à 20:16
Citation Envoyé par JolyLoic  Voir le message
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!!!!
Offres d'emploi IT
TECHNICIEN DE MAINTENANCE INFORMATIQUE SPECIALISE
Aquaboulevard-Forest Hill - Ile de France - Paris
Ingénieur d'Études et Développement Java J2EE, Paris
People Centric - Ile de France - Paris (75000)
Correspondant informatique polyvalent (H/F)
NUMEN - Ile de France - Paris (75018)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique C