Discussion :

[NoIdea]

Je pense que si on parle à quelqu'un qui n'a jamais vu une ligne de code , de langage de programmation, algorithme, POO, templates, ... il n'en retiendra que très peu et oubliera tout très rapidement.
Cependant, si on lui montre les possibilités offertes par le langage (pour un mathématicien la puissance de calcul, pour d'autres les jeux vidéos,...) il pourra avoir un attrait. Puis, il faut lui enseigner les clés pour le faire :

Au début il peu s'agir d'explication théorique comme "une boucle for consiste à... et est utilisée pour..." mais il faudra que rapidement les mettre en pratique sans quoi il oubliera tout et verra son objectif se perdre (et donc sa motivation).
En les mettant en pratique, il pourra vérifier la qualité de son raisonnement (un test véritable est toujours mieux qu'un test "dans la tête" et donne l'impression d'aboutissement). Plus tard, quand le sentiment d'aboutissement ne sera plus nécessaire, que son objectif ne lui paraitra pas inatteignable (ou du moins qu'il comprendra les mécanismes), il pourra faire de la théorie pure.
Si on lui explique ce qu'est un tri a bulle, il n'en comprendra pas vraiment l'intérêt car il n'en n'aura jamais eut besoin.

[koala01]

Alors pour dire que apprendre la théorie peut faciliter la tâche pour apprendre un lanuage, c'est non! Car la théorie dans ce cas n'est pas celle du langage mais de toute la programmation!
Mais pratiquer un langage peut nous éclaircir beaucoup de chose sur la théorie si pas tout! Car la théorie n'est pas aussi compréhensible qu'en pratiquant son propre avis sur elle!
J'ai réussi à comprendre la programmation créant des jeux sans comprendre ce que c'est un pixel, mais aujourdui ce n'est plus pareil, en tout cas je comprends ce que c'est un pixel et plus!

Il est vrai qu'il y a... théorie et théorie.

Je ne parle pas forcément de celle qui te permet de savoir comment fonctionne un pixel (ce qui est d'ailleurs aussi fort soumis à variation en fonction du matériel et du langage), mais bel et bien des "principes de base" de la programmation.

Je parle de connaitre et de pouvoir utiliser tous des termes comme variable, type, fonction, test (à choix multiple), boucle, type définis par l'utilisateur, pile, file, liste, ...

Je parle d'être capable de réfléchir à la logique qui permettra, pourquoi pas, de déterminer la position d'un "sprite" lorsqu'il doit être affiché, en fonction de différents paramètres qu'il te faut évaluer ou calculer.

Je te parle d'être capable de réfléchir à une logique qui... empêchera ton personnage de "tomber" en dehors de ton plateau de jeu.

Je te parle de cette approche qui te permettra de gérer "au mieux" les différents sons, animations ou objets mobiles, en fonction des besoins, de déterminer quand il est préférable de les charger en mémoire, et de déterminer quand il est intéressant de les "décharger".

Tout cela peut être appris et devrait être compris avant d'essayer d'écrire le code car, si tu ne réfléchis pas à ces différents aspects, tu te retrouves avec un bonhomme marche "dans le vide" ou qui n'avance que de manière sacadée, avec des sons entièrement décalés par rapport à l'événement qui est censé le produire, à des temps de chargements qui te laisse l'occasion de boire ton café, le digérer et aller le pisser avant que ton jeu ne se lance.

Je ne compte plus le nombre de fois où un débutant s'est plaint des piètres performances de son programme, alors qu'il y avait un manque flagrant de réflexion "a priori" quant à la logique à mettre en oeuvre.

Cela se voyait à la manière même dont son code était structuré, et j'imagine sans peine sa tête devant le raisonnement que l'on suivait pour lui proposer une solution.

Tous ces écueils peuvent cependant être évités, et le débutant peut facilement resté motivé par le résultat obtenu s'il prend simplement la peine de se poser cinq minutes pour réfléchir à la logique avant de se mettre à "vomir" des lignes de code.

Et cette réflexion ne peut avoir, en définitive, qu'une seule base saine: la théorie et les "grands principes de la programmation", éventuellement adaptés au langage qu'il utilise.

C'est encore pire avec les langages qui permettent une gestion manuelle de la mémoire:

Combien de fois ne voit on pas dans le programme d'un débutant qu'il essaye de déréférencer ou de manipuler l'adresse d'un pointeur sans avoir au préalable... alloué la mémoire, ou après... avoir explictement libéré celle-ci

Une petite minute de réflexion, le simple fait d'avoir couché la logique sur un bout de serviette en papier lui aurait permis de se rendre compte que cette réservation ou cette libération de mémoire intervenait à... un mauvais moment.

La conception, de manière générale, est effectivement une tâche abstraite mais une étape indispensable à l'obtention d'un résultat au minimum "potable", et il est finalement très facile de la rendre beaucoup plus concrète sans avoir besoin de passer par un langage particulier: il "suffit" d'inciter le concepteur à se prendre "rien qu'un instant" pour l'ordinateur qui recevra les instructions.

Comme je l'ai dit, ce jeu de rôle permet, outre d'éventuels moments de rigolade (si celui qui endosse le rôle ne se prend pas trop au sérieux ), de concrétiser la manière dont le code sera effectivement exécuté.

[koala01]

En ce qui concerne l'algorithmie, je suis en COGE et pour la plupart de mes camarades, ils n'avaient jamais écrit une seule ligne de code, et pourtant ils ont réussi à suivre et à comprendre les premiers cours qui concernaient les boucles, le calcul de complexité (temporelle).

Et je ne crois pas qu'une fois passé sur Caml cela a aidé, cela serait même plûtot l'inverse (l'interpréteur CamlLight est assez mauvais quand il s'agit d'indiquer une erreur AMA ...).

Sauf erreur, Caml est un langage... fonctionnel...

Il n'est donc pas forcément difficile à comprendre que la théorie applicable aux langages procéduraux ne soit pas forcément adaptée

Donc je pense aussi que la théorie est un bon préambule à la pratique, il permet de s'abstraire d'un support, d'éviter de s'attacher à des techniques du langage quand on conçoit un algorithme, d'apprendre rapidement à évaluer s'il va marcher (quand on vous impose de démontrer un algo, en général vous partez pas sur quelque chose qui marchera peut-etre ...)

Effectivement...

Pour ce qui est des autres théories liées à la programmation (OO, Typage, Métrique ....) je ne sais pas trop quoi penser. Pour l'OO je pense aussi que de ne partir d'aucun langage peut-etre une bonne idée. Pour les 2 autres que j'ai coté elles sont je crois assez abstraite en soit).

Pour l'OO, on peut parfaitement suivre un raisonnement similaire, et commencer par expliquer, simplement, les notions qui sont propres à ce paradigme, telles, finalement, que celle qui sont représentables en UML.

En regroupant une dizaine de potes près à "jouer le jeu", tu peux demander à chacun de jouer le rôle d'une classe particulière et voir si ce que tu as envisagé tient la route

Je pense que si on parle à quelqu'un qui n'a jamais vu une ligne de code , de langage de programmation, algorithme, POO, templates, ... il n'en retiendra que très peu et oubliera tout très rapidement.

Cela dépend énormément de beaucoup de paramètres, tels que l'intérêt que le prof peu susciter (on retient beaucoup plus facilement ce qui nous fait rire un bon coup ) ou l'intérêt de l'élève pour ce qu'on lui explique...

Mais il faut, aussi, suivre une "courbe d'apprentissage" consistante et cohérente.

Ne parlons pas de fonction ou de classe template, c'est trop "orienté C++", mais parlons plutôt de programmation générique.
Cependant, si on lui montre les possibilités offertes par le langage (pour un mathématicien la puissance de calcul, pour d'autres les jeux vidéos,...) il pourra avoir un attrait. Puis, il faut lui enseigner les clés pour le faire :

Au début il peu s'agir d'explication théorique comme "une boucle for consiste à... et est utilisée pour..." mais il faudra que rapidement les mettre en pratique sans quoi il oubliera tout et verra son objectif se perdre (et donc sa motivation).

Pas forcément: une fois que tu as vu la théroie (par exemple, les différentes boucles), présente lui un exercice, autant que possible en rapport avec ses propres intérêts, dans lequel il devra, effectivement, choisir celle qui convient le mieux.

Et fait lui jouer le rôle du processeur pour s'assurer que son algorithme est correct.

Comme il aura été mis "en situation réelle", et qu'il aura sans doute bien ri à la mise en situation, il retiendra très facilement dans quel cas choisir quel type de boucle

En les mettant en pratique, il pourra vérifier la qualité de son raisonnement (un test véritable est toujours mieux qu'un test "dans la tête" et donne l'impression d'aboutissement). Plus tard, quand le sentiment d'aboutissement ne sera plus nécessaire, que son objectif ne lui paraitra pas inatteignable (ou du moins qu'il comprendra les mécanismes), il pourra faire de la théorie pure.
Si on lui explique ce qu'est un tri a bulle, il n'en comprendra pas vraiment l'intérêt car il n'en n'aura jamais eut besoin.

Ce qui nous oppose semble principalement être... la manière dont on envisage la "mise en pratique" de ce qu'il apprend.

Il ne sert à rien de lui apprendre "brut de force" ce qu'est un tri à bulle, par contre, tu peux le mettre face à un défi qui l'amènera "naturellement" à présenter un algorithme qui, comme par hasard, s'apparentera à celui-ci.

Il n'y a pas besoin du support d'un langage pour y arriver: il suffit de donner "le bon problème à résoudre".

Une fois qu'il arrive avec son algorithme, qu'il tient la route et que tu l'as incité à le vérifier, tu peux lui dire "tu sais quoi cela s'appelle un tri à bulles" et, comme il l'aura imaginé "de lui-même", il retiendra très facilement non seulement que cela s'appelle un tri à bulles, mais, aussi, la logique de cet algorithme.

Mes cours d'algorithmie tenaient sur une petite quarantaine de pages, et j'ai eu au total près de 200 heures de cours exclusivement dessus (comprend: cours de programmation orientée objet exclu).

Sur ces 200 heures, il y en a peut être 20 qui ont été dédiées aux explications "théoriques" pures.

Le reste a été dédié à des des exercices dans lesquels on était confrontés à des problèmes à résoudre (et à leur vérification).

Chaque exercice nous mettait dans une situation dans laquelle nous réfléchissions nous même à l'algorithme que le prof voulait nous apprendre, et ce n'est qu'une fois que cet algorithme avait été démontré que le prof nous disait de quel type d'algorithme il s'agissait.

La "mise en pratique" peut prendre de nombreuses formes, mais la forme la plus intéressante est celle... qui ne fait appel à aucun langage de programmation.

Le premier algorithme que le prof nous ait demandé d'écrire, juste après nous avoir dit qu'il n'y aurait pas 10% de théorie pour plus de 90 % de pratique (déception, nous qui croyions que "principes de programmation" serait un cours exclusivement théorique ) a été... "Donnez moi les étapes à suivre pour changer une roue si vous crevez sur l'autoroute".

Cela n'avait rien à voir avec la programmation, c'était "simplement" pour nous faire comprendre qu'il faut, comme pour l'écriture d'une recette de cuisine, arriver à séparer clairement les différentes étapes et à les placer "dans l'ordre adéquat".

Je ne vais pas reprendre l'intégralité de son cours ici, mais, par la suite, il nous présentait de temps en temps un concept particulier, mais nous passions le gros de notre temps à... créer des algorithmes et à... les tester oralement.

[eyquem]

Mon post sur l’inexpérience n’était pas une intervention s’inscrivant dans le débat “apprendre un langage par la théorie sans pratique“ (je fais court).

Il était destiné à essayer de faire sentir à PowerM que les conditions mêmes qui le poussent à vouloir apprendre un langage de programmation font qu’il lui manque plein de notions nécessaires pour poser plus valablement sa propre problématique (mais c’est vrai pour tout le monde).

je me dis à l'usage qu'il est quand même parfois bon d'écouter les autres afin d'éviter ce qui peut l'être

Certes. Tu vois, nous sommes d’accord, puisqu’il y a le terme « à l'usage » ......

Et en même temps, c’est bien quand il faudrait écouter qu’on ne le fait pas , puisque si l’on doit écouter c’est parce qu’on n’a pas eu l’expérience permettant de comprendre qu’il le faudrait... avant qu’il soit trop tard.... et donc on n’écoute pas....



Enfin bref, je pourrais en dire plus, mais le sujet est susceptible de tellement de ramifications que je n’ai pas envie de m’y lancer.

[Invité]

Bonjour,

il "suffit" d'inciter le concepteur à se prendre "rien qu'un instant" pour l'ordinateur qui recevra les instructions.

J'aime bien expression, en effet c'est, avec d'autres termes, ce que j'expliquais à mon père il y a une trentaine d'années.

[Klaim]

Une légère parenthèse pour une réplique qui aurait du faire réagir du monde :

J'ai décidé d'acheter :
Je me lance ! : Une introduction à la programmation C++ - Francis Glassborow, Roberta Allen, dans un premier temps puis ensuite d'acheter :
La Bible C++ - Timothy Budd (Auteur), Cay Horstmann (Auteur).

Je ne connais pas le premier (les autres ici te conseilleront mieux que moi pour les livres en français) mais le second est une très mauvaise idée.

L'idéal est de lire en anglais :
- Accelerated C++ (qui est très souvent conseillé, faudrait que je le prenne tiens);
- Thinking in C++ (1&2) qui suppose que tu as déjà fait un peu de programmation avant, mais qui est excellent pour comprendre les bases du C++
- eventuellement, si tu te sens totalement débutant en programmation tout court et que tu as du temps pour lire : Programming - Principles and Practice Using C++ qui est un livre pour apprendre a programmer plus qu'un livre sur le C++ (il y a finalement peu de features du C++ utilisés mais c'est normal puisque c'est plus pour comprendre comment programmer)

Ce dernier bouquin rejoint l'avis de koala (et est écrit par Stroustrup qui est à l'origine du C++).

Fin de parenthèse.

[phryos]

Personnellement je pense qu'il vaut mieux apprendre par un langage simple pour comprendre et mettre en oeuvre les grands principes d'algorithmie (les tris, ecriture/lecture fichier, etc...) Une fois que c'est en place, passer sur des langages plus évolués.

J'ai commencé à 15 ans le développement de cette manière et ça a bien marché. Si j'avais eu à mettre en place un tri à bulle en C au lieu de pascal, je pense que cela m'aurait dégouté de faire du développement. Il est tellement facile de faire des erreurs en C et C++ que la compréhension et la mise en oeuvre des principes d'algo auraient été masqué...

[koala01]

Personnellement je pense qu'il vaut mieux apprendre par un langage simple pour comprendre et mettre en oeuvre les grands principes d'algorithmie (les tris, ecriture/lecture fichier, etc...) Une fois que c'est en place, passer sur des langages plus évolués.

J'ai commencé à 15 ans le développement de cette manière et ça a bien marché. Si j'avais eu à mettre en place un tri à bulle en C au lieu de pascal, je pense que cela m'aurait dégouté de faire du développement. Il est tellement facile de faire des erreurs en C et C++ que la compréhension et la mise en oeuvre des principes d'algo auraient été masqué...

Ce qu'il faut comprendre, c'est que pour une très grosse majorité d'algorithme (il n'y a, finalement, que ceux qui doivent être appliqués "à la lettre" comme les algorithmes de cryptographie ou de calcul de somme de contrôle qui font exception), si tu mets une personne face à une situation où un algorithme donné est nécessaire, il y a de fortes chances pour qu'elle... te fournisse à peu de chose près exactement l'algorithme attendu, "simplement" parce qu'il représente... la "moins mauvaise" solution pour répondre à un besoin donné, même si cette personne ignore qu'il s'agit d'un algorithme "tellement habituel" qu'on lui a même donné un nom et / ou qu'elle en ignore le nom.

Quand tu y réfléchis bien, la syntaxe et la grammaire de n'importe quel langage tient en... une cinquantaine de règles (maximum) et une centaine de mots clé (si on arrive à autant).

Pour écrire du code, c'est à peu près tout ce qu'il te faut, quel que soit le langage envisagé.

Tout le reste du langage a trait à ... la reproductivité des résultats.

Mais la base de la reproductivité des résultat reste... la logique qu'on suivi les développeur du langage et, au niveau du développeur, l'aglorithme dont il espère qu'il donnera un résultat correct et cohérent.

Si on avait commencé par t'expliquer ce que sont les boucles, les tests, les affectations, les variable, les types (primitif et ou définis par l'utilisateur) et que l'on t'avais incité à "jouer au processeur" pour vérifier si ta logique mène bien au résultat espéré, que l'on t'avais présenté (schéma à l'appui) les structures de base (piles, files, listes, arbres binaires) et que l'on t'avait habitué à jouer avec tout cela, tu aurais sans doute passé quelques heures de franche rigolade, et tu en serais sans doute arrivé à écrire un algorithme de tri à bulles sans même... savoir qu'il s'agissait de cela.

Car, au final, le nom "tri à bulles" n'est, comme tout nom, qu'un terme conventionnel permettant à ceux qui le connaisse de savoir de quoi l'on parle, rien de plus

Il aurait alors suffit, pour t'apprendre les bases de C (de C++ ou de n'importe quel autre langage) de te dire

• La syntaxe de la déclaration d'une variable, c'est : type <constance> nom de variable < = valeur >
• la signature d'une fonction, c'est type de retour <constance> nom de la fonction(<liste d'arguments>)
• toute instruction se termine par un point virgule
• un bloc d'instruction (en ce, y compris le corps des fonction) se place entre accolade
• pour créer une "boucle" pour on utilise for(< <type> nom de la variable = valeur de départ >; <test de la valeur de fin>; <pas d'incrémentation>)
• pour créer une boucle "tant que", on utilise while(test de réentrance)
• Pour créer une boucle "jusque", on utilise do{<instructions>} while (test de sortie);
• Pour créer un test "vrai faux", on utilise if (condition){<instructions>}else{<instructions>}
• ...

parce que l'écriture du code se résume, en définitive, à un long et fastidieux travail de traduction et de dactylographie, qui, à la limite, pourrais être simplement entrepris par quelqu'un à qui on a juste donné les "règles de traduction".

Je suis, évidemment, d'accord avec le fait qu'il ne s'agit effectivement que des "bases de départ", et qu'il y a encore beaucoup à apprendre sur n'importe quel langage une fois que l'on a passé ce cap, mais, si tu as déjà "appris à réfléchir" à la logique à mettre en oeuvre, tu t'évite quantité de problèmes et le reste sera beaucoup plus facile à comprendre

[driz764]

Encore étudiant aujourd'hui, je prends maintenant (rentré en master en septembre) un peu plus conscience de l'intérêt de la théorie.
Le principal problème de la théorie ne serait-il pas l'impatience dont on peut faire part qu'on veut découvrir la programmation? Clairement, à mes débuts la seule chose qui m'intéressait était de voir le résultat de mon algo. J'ai débuté avec un module qui devait s'appeler initiation à la programmation impérative, où en salle on faisait de l'algo sur papier avec exécution sur papier, et en TP on le traduisait en Pascal (du français à l'anglais d'ailleurs grosso modo). C'était plutôt dans cette deuxième phase que j'éprouvais du plaisir à apprendre. Aujourd'hui je me détache clairement plus du langage dans mes projets personnels, je commence à apprécier la théorie.
Je suis donc plutôt d'avis qu'il est compliqué de commencer par de la théorie pure, mais commencer par un langage "simple" et proche de l'algo permet je pense de ne pas trop s'éloigner de la théorie.

En tout cas le débat est intéressant

[pseudocode]

Apprendre la théorie avant la pratique: une bonne chose ?

Dans l'ordre, je trouve qu'apprendre les bonnes pratiques est plus important que d'apprendre la théorie.

Il sera toujours temps, si on trouve cela intéressant, d'apprendre la théorie pour comprendre la raison d'être de ces bonnes pratiques. Alors qu'a l'inverse, connaitre la théorie ne vous empêche pas de faire des erreurs de débutant.

[white_tentacle]

En passant, on peut faire un parallèle intéressant avec d'autres disciplines :

- en musique, certains pensent qu'il faut d'abord apprendre le solfège (la théorie), ensuite un instrument. D'autres préfèrent commencer par un instrument puis apprendre le solfège plus tard, enfin d'autres feront tout en même temps.

- en sport, certains préfèreront la pratique de katas à l'affrontement en match/pratique réelle. Là encore, il y a le même débat.

Il est clair que la méthode qui vise à faire bouffer toute la théorie avant de passer à la pratique est très bonne pour former des gens très compétents, mais qu'elle en rebutera largement plus d'un. Je crois que comme toujours dans l'enseignement, il n'y a pas de règle absolue, si ce n'est de s'adapter à son public .

[HanLee]

Si on avait commencé par t'expliquer ce que sont les boucles, les tests, les affectations, les variable, les types (primitif et ou définis par l'utilisateur) et que l'on t'avais incité à "jouer au processeur" pour vérifier si ta logique mène bien au résultat espéré, que l'on t'avais présenté (schéma à l'appui) les structures de base (piles, files, listes, arbres binaires) et que l'on t'avait habitué à jouer avec tout cela, tu aurais sans doute passé quelques heures de franche rigolade, et tu en serais sans doute arrivé à écrire un algorithme de tri à bulles sans même... savoir qu'il s'agissait de cela.

Globalement, tu restes quand même dans un schéma très "impératif" quand tu conseilles d'apprendre la théorie , ce qui n'aide pas pour l'ouverture d'esprit.

Jouer au processeur c'est très bien pour la pensée impérative, mais lorsqu'il s'agit de problèmes plus abstraits, dont la décomposition en étapes trop fines complexifie la compréhension du problème, ben ça marche plus très bien.

Exemple : tu as parlé il y a quelques posts des tours de Hanoï. "La" bonne manière de résoudre simplement le problème, c'est de raisonner par récurrence (ou récursivité... une approche plutôt "mathématique").
Si l'on devait débugger en jouant au processeur avec toute la profondeur de pile... Je pense que tu en ressortirais fou .

[Sehnsucht]

Exemple : tu as parlé il y a quelques posts des tours de Hanoï. "La" bonne manière de résoudre simplement le problème, c'est de raisonner par récurrence (ou récursivité... une approche plutôt "mathématique").
Si l'on devait débugger en jouant au processeur avec toute la profondeur de pile... Je pense que tu en ressortirais fou .

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

[koala01]

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

Exactement... Si l'algorithme fonctionne pour trois plateaux, il fonctionnera pour 6, 10 ou 64 (au delà, et même pour 64, attend toi à passer des années à attendre que ca finisse )

Mais 2^3-1 ne fait jamais que 7 mouvements, ce qui n'est pas encore *si* compliqué à gérer "à mano"

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

Globalement, tu restes quand même dans un schéma très "impératif" quand tu conseilles d'apprendre la théorie , ce qui n'aide pas pour l'ouverture d'esprit.

Je ne suis pas si impératif que cela, vu que je parle au conditionnel

Je ne fait que présenter un certain nombre de conditions dont il est vrai que j'ai tendance à croire qu'elles iront d'elles-même dans une situation "idéale"

Le problème est que le débutant, surtout s'il apprend de manière autodidacte, a souvent une idée de ce qu'est un processeur et de son mode de fonctionnement qui est très loin de la réalité.

Quand j'écris, en exagérant à peine qu'il ne comprend que le 0 et le 1 et qu'il est, à la base, capable exclusivement de trois choses: lire le contenu d'une adresse mémoire, copier le contenu d'une adresse mémoire et changer une valeur dans une adresse mémoire, on me prend à la limite pour un fou, car on ne peut pas imaginer que la petite centaine d'instructions qu'il utilise n'est capable que de faire cela.

Pourtant, à l'usage, on se rend compte que la réalité est quand même fort proche de ce que j'écris

Lorsque j'insiste sur le fait que le compilateur ne se posera jamais de question et qu'il se contentera d'exécuter les instructions dans l'ordre dans lequel elles arrivent, sans s'inquiéter de savoir s'il est effectivement cohérent de les exécuter dans cet ordre particulier et non dans un autre, c'est un fait dont il faut être conscient, qui met en évidence la nécessité de lui fournir une logique "à toutes épreuves".

A partir du moment où l'on a pu convaincre le débutant de ces deux aspects purement réaliste, on lui a déjà à la limite donné tout ce qu'il faut pour lui permettre de jouer à se faire "aussi bête qu'un ordinateur", et on l'aura déjà mis dans une situation où tout le reste lui semblera "naturel".

[yorukaze]

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.

[koala01]

Dans l'ordre, je trouve qu'apprendre les bonnes pratiques est plus important que d'apprendre la théorie.

Encore une fois, je trouve important de faire la distinction entre les bonnes pratiques "d'ordre générale" et celles qui sont propres à un langage en particulier.

Les bonnes pratiques d'ordre générale trouvent souvent une justification dans la "théorie de base", et cette dernière peut donc aider à... comprendre ces bonnes pratiques.

Pour ce qui est des bonnes pratiques propres à un langage, elles sont, justement... propres au langage visé, et ce qui peut être considéré comme "allant de soi" dans X sera à la limite considéré comme... particulièrement dangereux ou carrément refusé dans Y ou Z.

Pensez à ce que l'on fait en C qui est refusé en C++, à ce qui est "fréquent" en C++ et refusé en java, ce ne sont pas les exemples qui manquent

Il sera toujours temps, si on trouve cela intéressant, d'apprendre la théorie pour comprendre la raison d'être de ces bonnes pratiques. Alors qu'a l'inverse, connaitre la théorie ne vous empêche pas de faire des erreurs de débutant.

Ma théorie est que, justement, lorsque l'on connait la raison d'être de quelque chose, on a beaucoup plus facile à retenir ce quelque chose et on est d'autant plus enclin à accepter de le faire.

Regarde simplement la manière dont tu régira face à l'ordre d'un supérieur s'il te dit simplement "c'est comme cela et pas autrement" par rapport au même ordre pour lequel il aura pris soin de t'expliquer les raisons de l'ordre

Pour le premier, tu pestera sur ton supérieur et tu le fera "avec des pieds de plombs", alors que pour le second tu le fera bien plus volontiers si... tu as compris et que tu adhère aux raisons qu'il t'a donné.

Les bonnes pratiques suivent exactement le même cheminement

En passant, on peut faire un parallèle intéressant avec d'autres disciplines :

- en musique, certains pensent qu'il faut d'abord apprendre le solfège (la théorie), ensuite un instrument. D'autres préfèrent commencer par un instrument puis apprendre le solfège plus tard, enfin d'autres feront tout en même temps.

- en sport, certains préfèreront la pratique de katas à l'affrontement en match/pratique réelle. Là encore, il y a le même débat.

Il est clair que la méthode qui vise à faire bouffer toute la théorie avant de passer à la pratique est très bonne pour former des gens très compétents, mais qu'elle en rebutera largement plus d'un. Je crois que comme toujours dans l'enseignement, il n'y a pas de règle absolue, si ce n'est de s'adapter à son public .

Comprenons nous (le titre de la discussion est peut être mal choisi, en sommes) : je ne dis absolument pas qu'il faut avoir fini d'ingurgiter toute la théorie avant de passer à la pratique avec un langage particulier.

Je dis que :
1- il est tout à fait possible de se passer d'un langage particulier pour "pratiquer" si les conditions sont réunies

2- Je n'ai rien contre le fait que l'on apprenne, en parallèle, un langage quelconque, pour autant que l'on n'essaye pas d'apprendre de la théorie (qui risque d'être biaisée par les restrictions et les permissivités du langage étudié) pendant cet apprentissage.

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

Je suis tout à fait d'accord, mais on peut trouver différentes manières de forger:

Si tu demande, pendant la partie théorique, de résoudre un problème concret à l'étudiant, puis que tu l'incite à vérifier oralement que son algorithme est correct et cohérent, c'est aussi une manière de forger... qui ne passe pas forcément par... la connaissance d'un langage quelconque

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.

Le "bout de papier" sera souvent la base de la conception et des méthodes de communication... Autant faire prendre directement les bonnes habitudes à l'étudiant pour qu'il commence par... réfléchir à ce qui doit être fait avant de se lancer sur le clavier et de commencer à "vomir" des lignes de code, en n'ayant, bien souvent, qu'un idée beaucoup trop approximative de l'ensemble.

Là où je te rejoins, c'est qu'il ne sert à rien d'arriver avec le diagramme de classe d'un pattern quelconque et de dire "ca, c'est le pattern XXX".

Par contre, ce qui est des plus intéressants, c'est de mettre l'étudiant face à un cas où le dit pattern est, décidément, la moins mauvaise solution.

Il y a nonante chances sur cent (si pas plus) que le diagramme de classes qu'il mettra au point ressemblera furieusement à celui... du pattern que tu voulais lui montrer.

Tu pourra alors attirer l'attention sur les quelques classes qui participent au pattern et lui dire "tu vois ca, c'est le pattern XXX" et, comme il l'aura cherché "de lui-même", il ne l'oubliera plus.

Il est d'ailleurs intéressant de constater que les DP ne sont pas sortis "comme cela" du cerveau malade d'un théoricien un peu fou : ils sont issus d'une étude approfondie des problèmes les plus fréquemment rencontrés et des solutions qui y étaient apportées.

Une fois évacués tous les points de variations propres aux spécificités des projets étudiés, on s'est rendu compte que... les problèmes étaient souvent équivalents et que les solutions étaient, elles aussi, équivalentes, parce que c'étaient... les solutions les moins mauvaise pour obtenir le résultat escompté.

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

Je suis tout à fait d'accord là dessus, mais, encore une fois, j'ai peut être une vision un peu plus générale de ce que pourrait être la pratique.

Et, pour moi, elle peut parfaitement ne pas passer par... un langage de programmation particulier.

[pseudocode]

Encore une fois, je trouve important de faire la distinction entre les bonnes pratiques "d'ordre générale" et celles qui sont propres à un langage en particulier.

Les bonnes pratiques d'ordre générale trouvent souvent une justification dans la "théorie de base", et cette dernière peut donc aider à... comprendre ces bonnes pratiques.

Pour ce qui est des bonnes pratiques propres à un langage, elles sont, justement... propres au langage visé, et ce qui peut être considéré comme "allant de soi" dans X sera à la limite considéré comme... particulièrement dangereux ou carrément refusé dans Y ou Z.

Pensez à ce que l'on fait en C qui est refusé en C++, à ce qui est "fréquent" en C++ et refusé en java, ce ne sont pas les exemples qui manquent

Justement. Apprendre la théorie "généraliste" Objet ou Procédurale ou XYZ ne te permettra pas de décider que est la meilleure façon d'écrire ton code. Il suffit de voir les pages de commentaires sur la discussion "héritage/LSP".

Les bonnes pratiques sont propre au langage, et donc englobent à la fois la théorie générale (qui sous-tend l'existence du langage) et les cas particuliers (liés aux limitations du langage).

Certes, connaitre les bonnes pratiques ne permet pas de différencier les 2. Mais, comme je l'ai dis, tu peux dans un deuxième temps t'intéresser à la théorie et comprendre ce qui est un principe fondamental et ce qui est une limitation.

Exemple, c'est une bonne pratique en C#/Java de ne pas concaténer des chaines de texte avec des opérateur "+". C'est aussi une bonne pratique de mettre les variables d'états en "private".

Pour faire un programme qui marche, peut importe de savoir si tout cela découle d'un paradigme OO ou d'une limitation du langage.

[koala01]

Justement. Apprendre la théorie "généraliste" Objet ou Procédurale ou XYZ ne te permettra pas de décider que est la meilleure façon d'écrire ton code.

Hé bien, si, justement...

Car si l'on peut admettre qu'un langage place des restrictions supplémentaires par rapport à la règle générale, on ne peut admettre comme valable quelque chose qui serait autorisé pour une raison ou une autre par le langage mais que la théorie généale réprouve

Il suffit de voir les pages de commentaires sur la discussion "héritage/LSP".

La discussion dont tu parles (pour ceux que ca intéresse, elle se trouve ==> ici <==) est justement l'exemple flagrant de ma thèse:

Ceux qui apprennent la théorie en même temps qu'un langage auront tendance à accepter une certaine souplesse au sujet du respect de la théorie parce que "le langage le permet" (quelle que soit la raison pour laquelle le langage permet quelque chose que la théorie pure réprouve )... Quand le langage permet d'aborder le principe théorique.

Si tu apprend la théorie "générale" sans passer par un langage particulier, un principe comme LSP est très clair:

1. Tu dois pouvoir effectivement dire, d'un point de vue sémantique, que l'objet du type dérivé EST-UN objet "particulier" du type de base.
2. Toute propriété (fonction publique) valide et vérifiée du type de base DOIT ETRE valide et vérifiée pour le type dérivé (modulo les adaptations éventuelles du comportement pour qu'il soit cohérent avec le type réel).

Du coup, lorsque tu arrive en C++ et que tu essaye de faire passer une fonction virtuelle qui est publique dans la classe de base vers une accessibilité moindre dans la classe dérivée, parce que "le compilateur le permet", cela te choque au plus haut point, simplement, parce que c'est en contradiction avec l'un des deux points que je viens de citer.

Je suis le premier à dire que, parfois, la pratique s'éloigne très fort de la théorie, et mon parcours professionnel m'a très largement donné l'occasion de m'en rendre compte.

A tel point que, pour certaines choses, j'en viens à estimer que la théorie doit plus servir de "fil d'ariane" auquel te raccrocher quand la pratique est sur le point de te faire perdre les pédales.

Le problème, c'est qu'un ordinateur ne connait pas les nuances, et qu'il ne considérera jamais que 1.0001 est strictement égal à 1 si tu ne lui dit pas qu'il peut ne pas s'inquiéter des décimales.

Il n'y a donc qu'une seule attitude qui puisse être considérée comme saine si la pratique autorise quelque chose que la théorie réprouve: refuser la pratique.

Les bonnes pratiques sont propre au langage, et donc englobent à la fois la théorie générale (qui sous-tend l'existence du langage) et les cas particuliers (liés aux limitations du langage).

Nous sommes bien d'accord sur le fait qu'il est parfaitement inutile de vouloir appliquer les principe de l'orienté objet avec un langage qui ne supporte pas le paradigme

Mais il faut comprendre que ce n'est pas parce qu'un langage donné autorise quelque une pratique quelconque que la pratique est d'office acceptable.

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.

Certes, connaitre les bonnes pratiques ne permet pas de différencier les 2. Mais, comme je l'ai dis, tu peux dans un deuxième temps t'intéresser à la théorie et comprendre ce qui est un principe fondamental et ce qui est une limitation.

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.

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

Pour faire un programme qui marche, peu importe de savoir si tout cela découle d'un paradigme OO ou d'une limitation du langage.

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.

Tant que tu es en phase de conception, tu ne peux pas faire autrement que... d'appliquer la théorie, éventuellement adaptée en fonction des restrictions du langage envisagé.

Mais cela sous entend que... tu sois convaincu des bienfaits que l'on peut avoir à passer par la case "conception" avant de se jeter sur le clavier.

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 )