Discussion :

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

[white_tentacle]

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: il est d'autant moins marrant de se "casser la gueule" que l'on sait qu'un grand nombre de gens l'ont fait avant nous et qu'on a refusé de les écouter ...

Je réagis sur ce point, car je ne suis pas tout à fait d'accord. Je pense qu'on apprend beaucoup plus de ses erreurs que de ses réussites. Aussi, il faut, dans l'apprentissage, laisser l'occasion aux gens de se planter lamentablement et se casser la gueule. C'est le meilleur moment pour le faire.

Sinon, pour reprendre le débat, il y a un problème à l'approche définie par Koala, c'est que quelque soit la théorie qu'on enseigne, elle a besoin d'un langage pour être écrite et formalisée. Ce langage peut être n'importe lequel, mais on en a besoin d'un (même s'il n'est pas compilable). J'avoue qu'à ce jeu, je préfère un langage compilable/interprétable, ne serait-ce que pour éviter de charger l'esprit avec deux langages distincts.

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

[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é...

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

[koala01]

Sinon, pour reprendre le débat, il y a un problème à l'approche définie par Koala, c'est que quelque soit la théorie qu'on enseigne, elle a besoin d'un langage pour être écrite et formalisée. Ce langage peut être n'importe lequel, mais on en a besoin d'un (même s'il n'est pas compilable). J'avoue qu'à ce jeu, je préfère un langage compilable/interprétable, ne serait-ce que pour éviter de charger l'esprit avec deux langages distincts.

Je comprends ta réaction dans le sens où j'ai une réaction totalement identique par rapport au pseudo code: A tout prendre, autant directement écrire le code et non du "faux code"

C'est la raison pour laquelle mes algorithmes ne sont jamais écrits en pseudo code (ou du moins "aussi rarement que possible), et que je préfère, à tout prendre, utiliser le nassi-schneiderman pour formaliser et transmettre mes algorithmes (car le flow chart présente quelques lacunes )

D'aucuns estiment que cela fait trop "petits dessins" et que cela fait un peu trop travailler le coté "artistique" du cerveau, mais je ne suis pas de leur avis

Mais, autrement, toute personne de plus de trois ans dispose d'un langage tout à fait naturel pour exprimer la manière dont un algorithme s'exécute: son langage maternel

D'autant plus que, lorsqu'il s'agit de l'exrpimer, le plus facile est, très clairement, de le faire de manière orale, et non écrite

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

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

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

[koala01]

C'est, exactement ce que je voulais exprimer.

Je ne dis pas qu'il faut assimiler un annuaire téléphonique de théorie avant de se mettre à un langage particulier, je dis juste qu'il faut arriver à comprendre qu'une bonne partie de ce que l'on fait en programmation séquentielle se fait... dans la vie de tous les jours:

On manipule des boucles presque sans s'en rendre compte en quasi permanence, chaque fois que l'on exécute une action qui se décompose en... une répétition plus ou moins longue d'autres actions particulière (pour ouvrir une boite de conserve ou changer la roue d'une voiture).

On manipule des tests vrai/faux et des tests à choix multiplesà longueur d'années, chaque fois que l'on dois décider de faire quelque chose ou non.

Le comportement d'une pile, d'une file ou d'une liste sera finalement identique à celui que l'on observe avec une pile de livres (ou de caisse) ou dans la file aux caisses d'un grand magasin.

Une fois ces trois grands structures dynamiques comprises, il n'y en a pas vraiment encore énormément à apprendre, bien qu'il ne soit pas forcément évident d'en trouver des exemples dans la vie de tous les jours.

Tout ce qui manque à l'étudiant, c'est de comprendre que chaque élément doit... être "relié" à un (ou deux) autre(s)...

Les gens arrivent "naturellement" à envisager de faire en sorte qu'une fonction s'appelle elle-même... Reste à être conscient des problèmes que cela peut engendrer au niveau du processeur et... de savoir comment sortir de la boucle que cela crée.

La réponse ne tient pourtant qu'en une phrase : tester en priorité le cas de base, celui qui, justement, permettra de sortir de la récursivité et vers lequel doit tendre toute la logique de la fonction.

Beaucoup de programmeurs n'aiment pas devoir gérer les ruptures pour la simple et bonne raison que... on ne leur a pas appris les techniques qui leur permettront de les aborder "petit à petit", alors que cela n'a rien de bien compliqué.

Attirons l'attention de l'étudiant sur la nécessité de... déléguer les responsabilités, sur l'intérêt qu'il y a à créer une fonction qui ne fait pas grand chose mais qui le fait bien.

Quand je dis qu'il est préférable d'apprendre la théorie, c'est de cette théorie là que je parle, c'est de donner l'occasion d'apprendre à... réfléchir et à "ralentir le rythme" comme le dit si bien Cyrano.

Il ne faut pas *forcément* pratiquer dans un langage donné, simplement parce que nous mettons déjà en pratique, sans nous en rendre compte, l'énorme majorité des concepts que la "théorie de base" nous propose, dans la vie de tous les jours.

Si le récipiendaire décide d'apprendre un langage OO, il n'y a pas grand chose à rajouter, bien que nous partions sur des concepts plus abstraits, mais commençons par lui expliquer l'optique de la POO, ce qu'est un héritage, une composition et une aggrégation.

Attirons son attention sur le fait qu'un clique droit sur la souris provoquera l'ouverture d'un menu contextuel différent en fonction de l'endroit où elle se trouve pour lui permettre de comprendre ce qu'est le polymorphisme (même si ce n'en est pas forcément ).

Apprenons lui Demeter et LSP et, une fois qu'il aura assimilé tous ces concepts, il sera réellement armé pour programmer orienté objets..

Il ne faut pas forcément que l'étudiant connaisse la méthode agile ou l'UML sur le bout des doigts, ni qu'il soit capable de ressortir "de tête" l'ensemble des DP pour qu'il soit en mesure de programmer: il suffit qu'il... connaisse quelques principes de base.

Ce sont ces principes de base qui devraient, selon moi, être appris de manière totalement indépendante d'un langage quelconque et qui permettront, justement à celui qui étudie C++ de décider en connaissance de cause d'utiliser ou non l'héritage, de présenter un mutateur ou non ou d'utiliser ou non un pointeur pour un membre donné.

Encore une fois, c'est cette théorie de base que je conseille d'apprendre avant de passer à n'importe quel langage.

On peut, par la suite, le mettre dans une situation dans laquelle il présentera de lui-même un DP particulier, mais il ne sert à rien de l'assommer avec la représentation plus ou moins hésotérique de tous ceux qui existent: il y viendra "naturellement" lorsqu'il en aura besoin, simplement parce qu'ils découlent tous des principes de base que je conseille d'apprendre dés le début.

[white_tentacle]

En passant et sans vouloir relancer le débat, je réagis juste à ça :

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.

Personne n'a soutenu (en tout cas, pas moi) que c'était bien "parce que le compilateur le permet". On est simplement à un désaccord sur un niveau purement théorique, indépendant du langage cible.

Je ne pense pas qu'apprendre la théorie après la pratique te fasse réfléchir différemment de si tu l'avais apprise avant ou en même temps. Par contre, ça te fait réfléchir différemment de si tu ne la connais pas, c'est sûr .

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

En passant et sans vouloir relancer le débat, je réagis juste à ça :

On va juste veiller à rester dans le cadre du débat actuel, alors

Personne n'a soutenu (en tout cas, pas moi) que c'était bien "parce que le compilateur le permet". On est simplement à un désaccord sur un niveau purement théorique, indépendant du langage cible.

Et pourtant, la théorie générale est claire et sans équivoque: toutes les propriétés valides pour la classe mère ne le sont pas pour les classes dérivés, et donc, l'héritage n'est pas admissible

Je ne pense pas qu'apprendre la théorie après la pratique te fasse réfléchir différemment de si tu l'avais apprise avant ou en même temps. Par contre, ça te fait réfléchir différemment de si tu ne la connais pas, c'est sûr .

Je pense au contraire que tout le problème vient de ce que tu rencontre un principe théorique qui t'interdit quelque chose qui "semble acceptable" pour ton langage cible.

Tu as donc de bonnes raisons de croire, en toute bonne franchise, que la théorie de base n'est pas en adéquation avec les faits.

Or ce n'est pas le cas: ce que tu observe dans ton langage cible n'est, au mieux, que quelque chose de particulier voulu par le langage (ex: l'interdiction de l'héritage multiple dans certains langages), au pire (comme c'est le cas pour ce fameux débat que tu ne veux pas relancer) qu'un "problème" du au fait que le compilateur n'est simplement pas armé pour s'assurer du respect d'un principe donné.

Si, dés le départ, et surtout avant de vouloir écrire une classe dans laquelle tu restreint l'accessibilité d'une méthode publique, on t'avais dit "attention, toute propriété valide dans la classe de base doit l'être dans la classe dérivée", tu n'aurais sans doute jamais imaginer oser un jour restreindre l'accessibilité d'une méthode dans une classe dérivée, ne serait-ce que parce que tu aurais suivi le raisonnement que je présente dans le fil en question.

Mais, comme tu as sans doutes appris LSP "sur le tard" car on t'as sans doute dit "attention, lorsque tu envisage tel héritage, tu es en contradiction avec lui", et que, d'un autre coté, tu en viens à remarquer qu'il n'y a aucun mécanisme permettant à C++ de garantir qu'il est respecté, tu en viens "naturellement" à t'interroger sur la validité du principe.

Si tu avais eu la chance d'utiliser un langage qui soit capable de garantir le respect de LSP (en existe-t-il seulement ) et qu'il t'avais mis en garde contre le fait que la restriction d'accessibilité d'une méthode dans une classe dérivée déroge à ce principe, tu aurais eu une réaction toute différente, basée sur une réflexion proche de

Ben oui, effectivement, une des propriétés valides pour la classe de base n'est plus valide pour la classe dérivée, je ne peux donc pas envisager l'héritage sous cette forme, ou je dois prendre une décision en ce qui concerne l'accessibilité de ma méthode"

(Tu remarqueras que c'est ma thèse dans le débat dont on parle )

Je quitte ici la réponse à ton intervention, pour passer à quelque chose que je tiens à placer dans cette discussion

Il ne faut pas oublier qu'un langage de programmation, quel qu'il soit, n'est, à l'instar des langues "humaines" qu'une série de conventions qui permettent aux parties en présence de se comprendre et de dialoguer.

Les parties en présence sont, en programmation:

L'homme, d'un coté, avec tous ses doutes et toutes ses certitudes, qui connait plusieurs (dizaines de) milliers de mots, qui accepte une multitude de nuances entre le blanc et le noir, entre le vrai et le faux et

L'ordinateur de l'autre coté, qui ne connait que le 1 et le 0,qui se contente d'appliquer les décisions, "d'appliquer les ordres" en "brave petit soldat" sans s'inquiéter de savoir s'il est opportun, à un moment donné, d'effectuer une action donnée ou s'il ne serait pas préférable de l'effectuer "à un autre moment".

Le compilateur ou l'interpréteur n'agissant que... comme l'interprète qui "traduit le message" pour les différentes parties.

Ce n'est pas parce que l'on change de langage (ou de langue) qu'il faut... changer le message.

Il faut, effectivement, adapter le message pour qu'il suive les conventions en cours et qu'il évite de heurter les sensibilités, mais le fond du message reste, fondamentalement, identique.

Dans le cadre d'un langage de programmation, le fond du message, c'est... la logique qui doit être mise en oeuvre, quel que soit le langage qui servira pour la traduction.

La théorie au sujet de laquelle je plaide pour un apprentissage avant d'apprendre un langage particulier n'a, au final, qu'un seul but : permettre au développeur (débutant) de pouvoir énoncer clairement la logique qu'il demande à l'ordinateur de mettre en oeuvre.

A ce sujet, je n'ai pas choisi les deux premières lignes de ma signature par hasard...(vous aurez sans doute compris le clin d'oeil de la première )

La première nous rappelle qu'il n'est pas utile de multiplier par six puis de diviser par 3 si, tout ce que l'on veut, c'est multiplier par deux.

La deuxième touche au noeud du problème de la programmation: pour énoncer clairement le message que l'on souhaite transmettre à l'ordinateur, il faut, avant tout, correctement le concevoir (tient donc: concevoir et conception ont une racine commune, non )

La "mise au point" du message que l'on veut transmettre doit se baser sur... une théorie sans faille, et doit se faire bien avant de s'adresser "à l'interprète" si on souhaite obtenir au final... quelque chose qui fait ce que l'on attend de lui exactement quand on l'en attend.